最近定位一個服務問題時發現telnet某個端口,沒法連接。無奈之下只能一步步排查。安全
端口是否存在socket
ss -l|grep LISTEN|grep 9999
若是端口存在那麼能夠觀察該端口上的recv-q send-q 若是是發生死鎖通常狀況下這兩個隊列只會增長(固然當服務處理過慢時也會致使包堆積)ide
Recv-Q Send-Q Local Address:Port Peer Address:Port 0 1024 *:5200 *:*
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 -dcode
root 1903 1901 1 11:09 ? 00:02:25 ./client -f ../conf/client.ini -dserver
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 1903it
#0 0x00007f105892105e in __lll_lock_wait_private () from /lib64/libc.so.6class
#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,而該方法中會枷鎖。