本文主要記錄一次tomcat進程，因TCP連接過多導致CPU占用過高的問題排查記錄。
問題描述
linux系統(tǒng)下，一個tomcat web服務的cpu占用率非常高，top顯示結果超過200%。請求無法響應。反復重啟依然同一個現(xiàn)象。
問題排查
1、獲取進程信息
通過jdk提供的jps命令可以快速查出jvm進程，
2、查看jstack信息
發(fā)現(xiàn)存在大量log4j線程block，處于waiting lock狀態(tài)
org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) @bci=12, line=201 (Compiled frame)
搜索相關信息，發(fā)現(xiàn)log4j 1.x版本存在死鎖問題。
發(fā)現(xiàn)問題，于是調(diào)整log4j配置，僅打開error級別日志，重啟tomcat。此時stack中block線程消失，但進程cpu占用率依然高漲。
3、進一步排查
分析每個線程的cpu占用量，此處需要引入一個大神貢獻的腳本，計算java進程中，每個線程的cpu使用量。
#!/bin/bash
typeset top=${1:-10}
typeset pid=${2:-$(pgrep -u $USER java)}
typeset tmp_file=/tmp/java_${pid}_$$.trace
$JAVA_HOME/bin/jstack $pid > $tmp_file
ps H -eo user,pid,ppid,tid,time,%cpu --sort=%cpu --no-headers\
| tail -$top\
| awk -v "pid=$pid" '$2==pid{print $4"\t"$6}'\
| while read line;
do
typeset nid=$(echo "$line"|awk '{printf("0x%x",$1)}')
typeset cpu=$(echo "$line"|awk '{print $2}')
awk -v "cpu=$cpu" '/nid='"$nid"'/,/^$/{print $0"\t"(isF++?"":"cpu="cpu"%");}' $tmp_file
done
rm -f $tmp_file
腳本適用范圍
因為ps中的%CPU數(shù)據(jù)統(tǒng)計來自于/proc/stat，這個份數(shù)據(jù)并非實時的，而是取決于OS對其更新的頻率，一般為1S。所以你看到的數(shù)據(jù)統(tǒng)計會和jstack出來的信息不一致也就是這個原因～但這份信息對持續(xù)LOAD由少數(shù)幾個線程導致的問題排查還是非常給力的，因為這些固定少數(shù)幾個線程會持續(xù)消耗CPU的資源，即使存在時間差，反正也都是這幾個線程所導致。
除了這個腳本，簡單點兒的方法則是，查出進程id后，通過如下命令查看該進程中每個線程的資源使用情況
從這里獲取pid（線程id），轉換為16進制，然后去stack信息中查找對象的線程信息。
通過上述方法，查出tomcat進程對應的線程cpu占用率累積之和約80%，遠小于top給出的200%+
說明并不存在長期占用cpu的線程，應該是屬于有許多短暫性的cpu密集計算。進而懷疑是不是jvm內(nèi)存不足，頻繁gc導致。
發(fā)現(xiàn)jvm內(nèi)存使用并未出現(xiàn)異常，gc次數(shù)明顯暴漲
查完內(nèi)存，由于本身是一個網(wǎng)絡程序，進一步排查網(wǎng)絡連接。
4、問題定位
查詢tomcat對應端口的tcp鏈接，發(fā)現(xiàn)存在大量EASTABLISH的鏈接，還有部分其它狀態(tài)的連接，總計400+。
進一步查看這些連接的來源，發(fā)現(xiàn)是該tomcat服務的應用端，存在大量后臺線程，在頻繁輪詢該服務，導致該服務tomcat 連接數(shù)被打滿，無法繼續(xù)接收請求。
netstat狀態(tài)說明：
- LISTEN：偵聽來自遠方的TCP端口的連接請求
- SYN-SENT：再發(fā)送連接請求后等待匹配的連接請求（如果有大量這樣的狀態(tài)包，檢查是否中招了）
- SYN-RECEIVED：再收到和發(fā)送一個連接請求后等待對方對連接請求的確認（如有大量此狀態(tài)，估計被flood***了）
- ESTABLISHED：代表一個打開的連接
- FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
- FIN-WAIT-2：從遠程TCP等待連接中斷請求
- CLOSE-WAIT：等待從本地用戶發(fā)來的連接中斷請求
- CLOSING：等待遠程TCP對連接中斷的確認
- LAST-ACK：等待原來的發(fā)向遠程TCP的連接中斷請求的確認（不是什么好東西，此項出現(xiàn)，檢查是否被***）
- TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
- CLOSED：沒有任何連接狀態(tài)
5、根源分析
直接觸發(fā)原因是客戶端輪詢，請求異常，繼續(xù)輪序；客戶端不斷有新的后臺線程加入輪詢隊伍，最終導致服務端tomcat連接被打滿。
到此這篇關于記一次tomcat進程cpu占用過高的問題排查記錄的文章就介紹到這了,更多相關tomcat進程cpu占用過高內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
