uwsgi重启问题定位

     

      最近几天经常发现访问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 去看哪个目录占用的比较大。这样来排查占用空间比较大的文件。

 

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