17站長網 › 首頁 ›網站› 服務器 › 查看內容

tomcat進程cpu占用過高的問題排查記錄

2022-10-18 09:09| 查看: 1684 |來源: 互聯網

本文主要記錄一次tomcat進程，因TCP連接過多導致CPU占用過高的問題排查記錄。問題描述 linux系統下，一個tomcat web服務的cpu占用率非常高，top顯示結果超 ...

本文主要記錄一次tomcat進程，因TCP連接過多導致CPU占用過高的問題排查記錄。

問題描述

linux系統下，一個tomcat web服務的cpu占用率非常高，top顯示結果超過200%。請求無法響應。反復重啟依然同一個現象。

問題排查

1、獲取進程信息

通過jdk提供的jps命令可以快速查出jvm進程，

jps pid

2、查看jstack信息

jstack pid

發現存在大量log4j線程block，處于waiting lock狀態

org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) @bci=12, line=201 (Compiled frame)

搜索相關信息，發現log4j 1.x版本存在死鎖問題。

發現問題，于是調整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數據統計來自于/proc/stat，這個份數據并非實時的，而是取決于OS對其更新的頻率，一般為1S。所以你看到的數據統計會和jstack出來的信息不一致也就是這個原因～但這份信息對持續LOAD由少數幾個線程導致的問題排查還是非常給力的，因為這些固定少數幾個線程會持續消耗CPU的資源，即使存在時間差，反正也都是這幾個線程所導致。

除了這個腳本，簡單點兒的方法則是，查出進程id后，通過如下命令查看該進程中每個線程的資源使用情況

top -H -p pid

從這里獲取pid（線程id），轉換為16進制，然后去stack信息中查找對象的線程信息。

通過上述方法，查出tomcat進程對應的線程cpu占用率累積之和約80%，遠小于top給出的200%+

說明并不存在長期占用cpu的線程，應該是屬于有許多短暫性的cpu密集計算。進而懷疑是不是jvm內存不足，頻繁gc導致。

jstat -gc pid

發現jvm內存使用并未出現異常，gc次數明顯暴漲

查完內存，由于本身是一個網絡程序，進一步排查網絡連接。

4、問題定位

查詢tomcat對應端口的tcp鏈接，發現存在大量EASTABLISH的鏈接，還有部分其它狀態的連接，總計400+。

netstat -anp | grep port

進一步查看這些連接的來源，發現是該tomcat服務的應用端，存在大量后臺線程，在頻繁輪詢該服務，導致該服務tomcat 連接數被打滿，無法繼續接收請求。

netstat狀態說明：

LISTEN：偵聽來自遠方的TCP端口的連接請求
SYN-SENT：再發送連接請求后等待匹配的連接請求（如果有大量這樣的狀態包，檢查是否中招了）
SYN-RECEIVED：再收到和發送一個連接請求后等待對方對連接請求的確認（如有大量此狀態，估計被flood***了）
ESTABLISHED：代表一個打開的連接
FIN-WAIT-1：等待遠程TCP連接中斷請求，或先前的連接中斷請求的確認
FIN-WAIT-2：從遠程TCP等待連接中斷請求
CLOSE-WAIT：等待從本地用戶發來的連接中斷請求
CLOSING：等待遠程TCP對連接中斷的確認
LAST-ACK：等待原來的發向遠程TCP的連接中斷請求的確認（不是什么好東西，此項出現，檢查是否被***）
TIME-WAIT：等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認
CLOSED：沒有任何連接狀態

5、根源分析

直接觸發原因是客戶端輪詢，請求異常，繼續輪序；客戶端不斷有新的后臺線程加入輪詢隊伍，最終導致服務端tomcat連接被打滿。

以上tomcat進程cpu占用過高的問題排查記錄就是小編為大家收集整理的全部內容了，希望對大家有所幫助。如果您喜歡這篇文章，可以收藏或分享給您的小伙伴們吧！歡迎持續關注我們的后續更新。

本文最后更新于 2022-10-18 09:09，某些文章具有時效性，若有錯誤或已失效，請在網站留言或聯系站長：17tui@17tui.com

·END·

站長網微信號：w17tui，關注站長、創業、關注互聯網人 - 互聯網創業者營銷服務中心

免責聲明：本站部分文章和圖片均來自用戶投稿和網絡收集，旨在傳播知識，文章和圖片版權歸原作者及原出處所有，僅供學習與參考，請勿用于商業用途，如果損害了您的權利，請聯系我們及時修正或刪除。謝謝！

下一篇：Linux tr命令是如何使用的上一篇：Linux which命令是如何使用的

17站長網微信二維碼

始終以前瞻性的眼光聚焦站長、創業、互聯網等領域，為您提供最新最全的互聯網資訊，幫助站長轉型升級，為互聯網創業者提供更加優質的創業信息和品牌營銷服務，與站長一起進步！讓互聯網創業者不再孤獨！

掃一掃，關注站長網微信

亚洲国产精品人久久,亚洲va国产日韩欧美精品色婷婷,久久久久88色偷偷,免费人成黄页在线观看国际

tomcat進程cpu占用過高的問題排查記錄

大家都在看

相關分類

熱門排行

最近更新