最近几天经常发现访问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 去看哪个目录占用的比较大。这样来排查占用空间比较大的文件。
五、磁盘满只是导致该问题的一个方面。其实对于这种组件较多系统,容易产生单点故障的问题。对于系统的资源整体监控是解决该问题的一个办法。另外对于日志的生成,需要自动定时的清理 。当然具体使用的怎么清理格式我们后续会继续讨论。