uwsgi重启问题定位

本文介绍了在遇到webserver响应异常时,如何通过分析nginx的access.log和uwsgi的日志来定位问题。当发现uwsgi子进程频繁重启,通过检查uwsgi配置的http_timeout,结合业务理解或系统工具如strace,定位到问题可能是由于外部组件响应慢或磁盘空间满导致。解决方法包括监控系统资源和定期清理日志。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

     

      最近几天经常发现访问webserver (scancenter)有异常,有时慢有时快。

 

定位思路:后台架构使用nginx 作为反向代理,uWsgi做为web服务器,项目使用django框架。基本上的请求流程是: client--->nginx---->uwsgi----->django

 

 

一、先看nginx的access.log 

      一般在/usr/local/nginx/log/目录下。当然如果还找不到就locate access.log一下就能找到了。

     没有太大异常,只是发现一些请求时间比较长。达到300秒。具体的日志含义可以在nginx.conf看到。

 

         

      

二、再查看uwsgi的log

 

           

 

       发现很多子进程在不停的重启。

       常理判断300秒是有问题的。查看uwsgi的

        配置。发现uwsgi 配置的超时时间是300.一个请求300s肯定是有问题的。因为等待时间超过了配置的300s。所以导致了重启。
      

        

 

三、uwsgi配置中http_timeout表示设置内部http的socket超时时间,如果超过这个时间没有响应就会重启该子进程

 

       这时候主要依据对业务的熟悉程度,熟悉的话 可以知道/api/communicat/command 这个是要和其他组件交互的,所以直接去看那台组件是否正常运行。

       如果不熟悉的话其实也有办法。

 

      (1)、cd /proc/xxx/fd 查看对应的日志

      (2)、使用strace -p uwsgi_pid 来观察这个进程到底在干啥勒。我们使用第二种来观察一下,

        

 

      当然你要strace 的是uwsgi的子进程,如果太多的话,可以配置只启用一个uwsgi进程,这样就可以容易定位了。

      我们看到它在recvfrom 一个文件描述符,打开cd /proc/uwsgi_pid/fd && ls -lt 看到对应的描述符aaa。

 

      继续使用 lsof -p uwsgi_pid | grep aaa,可以看到它是在请求这台机器,并且一直在等待它。如下图:

 

              

 

 

四、接下来就清楚了。登录这个阻塞请求的机器,看看是否有异常。 df -h 或者是free -m 。我经常发现的问题是磁盘100%了。一般情况下是/var/log/目录中有大的文件导致的。

 

       当然不熟悉的话,可以先看df 下,看看哪个分区是满的。然后一层一层去执行 du -sm * | sort -n 去看哪个目录占用的比较大。这样来排查占用空间比较大的文件。

 

五、磁盘满只是导致该问题的一个方面。其实对于这种组件较多系统,容易产生单点故障的问题。对于系统的资源整体监控是解决该问题的一个办法。另外对于日志的生成,需要自动定时的清理          。当然具体使用的怎么清理格式我们后续会继续讨论。

 

 

         

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值