某Python进程出现线程卡住情况的排查记录

现象:

需要排查的进程同时运行多个线程,其中一个线程的日志停留在数日前,而其他线程可以正常运行,日志正常打印

排查:

观察线程信息:

可以使用top -H -p {进程id}命令获得该进程线程信息。

排查当天15:09线程信息:
出问题服务器:
某Python进程出现线程卡住情况的排查记录_第1张图片
正常服务器(为了方便对比):
这里写图片描述
16:36线程信息:
出问题服务器:
某Python进程出现线程卡住情况的排查记录_第2张图片
正常服务器:
这里写图片描述
经过一番努力观察,发现出问题服务器3914这个线程的TIME+列的值保持不变,而通过正常服务器的信息对比得知,如果正常运行这个值应该是会变的。

TOP TIME+ Total CPU time the task has used since it started – man top

导致线程cpu时间不再增加的可能的原因就是在等待io,说明3914这个线程某个io卡住了

观察线程进程占用文件情况

lsof 命令可以查看当前系统文件被打开情况,lsof -p {进程id} 可以看到

出问题服务器:
某Python进程出现线程卡住情况的排查记录_第3张图片

正常服务器1:
某Python进程出现线程卡住情况的排查记录_第4张图片

正常服务器2 :
某Python进程出现线程卡住情况的排查记录_第5张图片

对比正常的两台服务器,可以发现有问题的进程lsof出来的结果还是很不一样的,其中一个TCP连接十分可疑, 继续用lsof -i 命令追踪得知这tcp请求来之问题线程代码里的对邮件接口的请求,那么问题原因就很清楚了:一次对邮件借口的请求无限卡住了,导致线程无法继续往下跑

反思:

实际排查的时候并没如上面步骤那么明了,一开始没怎么看代码只往文件io方面排查,所以根本没留意到那个异常的tcp连接,之后某次看代码才发现还有网络io才注意到。

你可能感兴趣的:(总结)