最近遇到进程卡死的情况,但是自己调试的过程中并不一定能复现,都是需要运行一段时间某些条件下才会触发,对于这种运行着不能破坏现场的情况,我们可以使用gdb -p和strace -p来跟踪。
1. ps auxf 查看我们的进程执行到了哪一步:
可以看到执行到了docker exec -i 178.20.1.229_0115034556 ls然后就卡死了
2. strace 查看执行这个操作死在哪个系统回调:
这里可以看到死在了系统回调read这里,描述符19的具体意义我们可以进入/proc/pid/fd再查看一下:
19代表的是pipe,我们这里是死在了读pipe上面。
/************************************************************************************************************/
分割线,后面再次出现这个问题
我们先用ps auxf查看进程号和进程执行到了哪一步,可以看到进程号是27678,卡在docker exec
继续用strace -p 27678跟踪,发现卡在read,文件描述符是14
cd /proc/27678/,在这里我们可以查看进程状态
查看进程的内核堆栈的调试信息,wchan表示导致进程睡眠或者等待的函数
现在我们查看一下进程打开的文件描述符14代表什么,pipe文件
我们已经可以确定main创建子进程执行shell命令docker exec -i mongo_docker_master ls,同时通过pipe和子进程通信,结果卡在了read pipe上。
其实在这里我们也可以使用lsof来定位,可以看到进程27678打开的FD 14是pipe,这里u代表可读可写,r代表可读
也可以直接查看进程27678打开的,可以看到14是pipe
另附:
查找性能问题:
ps -eLo pid,lwp,pcpu |grep pid
pstack pid