最近定位一个服务问题时发现 telnet 某个端口, 无法链接. 无奈之下只能一步步排查.
端口是否存在
ss -l|grep LISTEN|grep 9999
如果端口存在那么可以观察该端口上的 recv-q send-q 如果是发生死锁一般情况下这两个队列只会增加 (当然当服务处理过慢时也会导致包堆积)
- Recv-Q Send-Q Local Address:Port Peer Address:Port
- 0 1024 *:5200 *:*
另外可以通过一下命令统计各类 socket 状态的数据
- ss |awk 'BEGIN{arr[""]=0}{arr[$1]++}END{for(i in arr) print i,arr[i]}'
- LAST-ACK 1305
- ESTAB 341643
- State 1
- FIN-WAIT-1 7553
- CLOSING 3
- FIN-WAIT-2 908
- CLOSE-WAIT 60067
如果你的服务是多个进程那么, 如果只是一个进程死锁, 那么很容易就可以看出来该进程的 CPU 消耗时间应该小于其他进程, 当然这个取决于进程的运行时间. 下面的进程中, id=1903 的进程就是疑似死锁问题.
- root 1901 1 0 11:09 ? 00:00:00 ./client -f ../conf/client.INI -d
- root 1902 1901 15 11:09 ? 00:31:55 ./client -f ../conf/client.INI -d
- root 1903 1901 1 11:09 ? 00:02:25 ./client -f ../conf/client.INI -d
- root 1904 1901 15 11:09 ? 00:31:19 ./client -f ../conf/client.INI -d
- root 1905 1901 15 11:09 ? 00:31:17 ./client -f ../conf/client.INI -d
定位哪里死锁
经过一步步盘查之后, 怀疑进程死锁, ok. 最好的定位方法就是 attach 到进程, 然后 bt 一下既可以看到进程 hang 在哪里...
- $gdb attach 1903
- #0 0x00007f105892105e in __lll_lock_wait_private () from /lib64/libc.so.6
- #1 0x00007f10588c6cad in _L_lock_2164 () from /lib64/libc.so.6
- #2 0x00007f10588c6a67 in __tz_convert () from /lib64/libc.so.6
- #3 0x00007f105890da5d in __vsyslog_chk () from /lib64/libc.so.6
- #4 0x00007f105889948e in __libc_message () from /lib64/libc.so.6
- #5 0x00007f105889ee66 in malloc_printerr () from /lib64/libc.so.6
- #6 0x00007f10588c6909 in tzset_internal () from /lib64/libc.so.6
- #7 0x00007f10588c6a89 in __tz_convert () from /lib64/libc.so.6
- #8 0x00000000004c0917 in shift_fd (lvl=1, fmt=0x55e308 "[%s][%d][%s]: [server] recv SIGSEGV.pid:%d!\n") at ../src/log_xx.cpp:95
- #9 write_log (lvl=1, fmt=0x55e308 "[%s][%d][%s]: [server] recv SIGSEGV.pid:%d!\n") at ../src/log_xx.cpp:138
上面这个问题导致是因为进程抛出了 SEGV 信号之后, 在处理信号的方法中使用了非线程安全的 localtime, 而该方法中会枷锁.
来源: http://www.bubuko.com/infodetail-3205473.html