眾所周知,Linux系統CPU占用100%這個異常現象還是經常遇到的,因此分析其導致異常原因是解決問題的根本。今天浩道跟大家分享硬核干貨,工作中當你服務器CPU達到100%時,該如何排查異常故障呢?并且除了分享分析方法之外,還給大家分享排查所使用的一個Shell腳本,可以說非常高效便利!
昨天下午突然收到運維郵件報警,顯示數據平臺服務器cpu利用率達到了98.94%,而且最近一段時間一直持續在70%以上,看起來像是硬件資源到瓶頸需要擴容了,但仔細思考就會發現咱們的業務系統并不是一個高并發或者CPU密集型的應用,這個利用率有點太夸張,硬件瓶頸應該不會這么快就到了,一定是哪里的業務代碼邏輯有問題。
2、排查思路
2.1定位高負載進程pid
首先登錄到服務器使用top命令確認服務器的具體情況,根據具體情況再進行分析判斷。
通過觀察load average,以及負載評判標準(8核),可以確認服務器存在負載較高的情況;
觀察各個進程資源使用情況,可以看出進程id為682的進程,有著較高的CPU占比
2.2定位具體的異常業務
這里咱們可以使用 pwdx 命令根據 pid 找到業務進程路徑,進而定位到負責人和項目:
可得出結論:該進程對應的就是數據平臺的web服務。
2.3定位異常線程及具體代碼行
傳統的方案一般是4步:
1、top oder by with P:1040 // 首先按進程負載排序找到 maxLoad(pid)
2、top -Hp 進程PID:1073 // 找到相關負載 線程PID
3、printf “0x%x ”線程PID:0x431 // 將線程PID轉換為 16進制,為后面查找 jstack 日志做準備
4、jstack 進程PID | vim +/十六進制線程PID - // 例如:jstack 1040|vim +/0x431 -
但是對于線上問題定位來說,分秒必爭,上面的 4 步還是太繁瑣耗時了,之前介紹過淘寶的oldratlee 同學就將上面的流程封裝為了一個工具:show-busy-java-threads.sh,可以很方便的定位線上的這類問題:
可得出結論:是系統中一個時間工具類方法的執行cpu占比較高,定位到具體方法后,查看代碼邏輯是否存在性能問題。
※如果線上問題比較緊急,可以省略 2.1、2.2 直接執行 2.3,這里從多角度剖析只是為了給大家呈現一個完整的分析思路。
3、根因分析
經過前面的分析與排查,最終定位到一個時間工具類的問題,造成了服務器負載以及cpu使用率的過高。
異常方法邏輯:是把時間戳轉成對應的具體的日期時間格式;
上層調用:計算當天凌晨至當前時間所有秒數,轉化成對應的格式放入到set中返回結果;
邏輯層:對應的是數據平臺實時報表的查詢邏輯,實時報表會按照固定的時間間隔來,并且在一次查詢中有多次(n次)方法調用。
那么可以得到結論,如果現在時間是當天上午10點,一次查詢的計算次數就是 10*60*60*n次=36,000*n次計算,而且隨著時間增長,越接近午夜單次查詢次數會線性增加。由于實時查詢、實時報警等模塊大量的查詢請求都需要多次調用該方法,導致了大量CPU資源的占用與浪費。
4、解決方案
定位到問題之后,首先考慮是要減少計算次數,優化異常方法。排查后發現,在邏輯層使用時,并沒有使用該方法返回的set集合中的內容,而是簡單的用set的size數值。確認邏輯后,通過新方法簡化計算(當前秒數-當天凌晨的秒數),替換調用的方法,解決計算過多的問題。上線后觀察服務器負載和cpu使用率,對比異常時間段下降了30倍,恢復至正常狀態,至此該問題得已解決。
5、總結
在編碼的過程中,除了要實現業務的邏輯,也要注重代碼性能的優化。一個業務需求,能實現,和能實現的更高效、更優雅其實是兩種截然不同的工程師能力和境界的體現,而后者也是工程師的核心競爭力。
在代碼編寫完成之后,多做 review,多思考是不是可以用更好的方式來實現。
線上問題不放過任何一個小細節!細節是魔鬼,技術的同學需要有刨根問題的求知欲和追求卓越的精神,只有這樣,才能不斷的成長和提升。
附上show-busy-java-threads.sh腳本:
#!/bin/bash # @Function # Find out the highest cpu consumed threads of java, and print the stack of these threads. # # @Usage # $ ./show-busy-java-threads.sh # # @author Jerry Lee readonly PROG=`basename $0` readonly -a COMMAND_LINE=("$0" "$@") usage() { cat </dev/null; then [ -z "$JAVA_HOME" ] && { redEcho "Error: jstack not found on PATH!" exit 1 } ! [ -f "$JAVA_HOME/bin/jstack" ] && { redEcho "Error: jstack not found on PATH and $JAVA_HOME/bin/jstack file does NOT exists!" exit 1 } ! [ -x "$JAVA_HOME/bin/jstack" ] && { redEcho "Error: jstack not found on PATH and $JAVA_HOME/bin/jstack is NOT executalbe!" exit 1 } export PATH="$JAVA_HOME/bin:$PATH" fi readonly uuid=`date +%s`_${RANDOM}_$$ cleanupWhenExit() { rm /tmp/${uuid}_* &> /dev/null } trap "cleanupWhenExit" EXIT printStackOfThreads() { local line local count=1 while IFS=" " read -a line ; do local pid=${line[0]} local threadId=${line[1]} local threadId0x="0x`printf %x ${threadId}`" local user=${line[2]} local pcpu=${line[4]} local jstackFile=/tmp/${uuid}_${pid} [ ! -f "${jstackFile}" ] && { { if [ "${user}" == "${USER}" ]; then jstack ${pid} > ${jstackFile} else if [ $UID == 0 ]; then sudo -u ${user} jstack ${pid} > ${jstackFile} else redEcho "[$((count++))] Fail to jstack Busy(${pcpu}%) thread(${threadId}/${threadId0x}) stack of java process(${pid}) under user(${user})." redEcho "User of java process($user) is not current user($USER), need sudo to run again:" yellowEcho " sudo ${COMMAND_LINE[@]}" echo continue fi fi } || { redEcho "[$((count++))] Fail to jstack Busy(${pcpu}%) thread(${threadId}/${threadId0x}) stack of java process(${pid}) under user(${user})." echo rm ${jstackFile} continue } } blueEcho "[$((count++))] Busy(${pcpu}%) thread(${threadId}/${threadId0x}) stack of java process(${pid}) under user(${user}):" sed "/nid=${threadId0x} /,/^$/p" -n ${jstackFile} done } ps -Leo pid,lwp,user,comm,pcpu --no-headers | { [ -z "${pid}" ] && awk '$4=="java"{print $0}' || awk -v "pid=${pid}" '$1==pid,$4=="java"{print $0}' } | sort -k5 -r -n | head --lines "${count}" | printStackOfThreads
文章來源:https://my.oschina.net/leejun2005/blog/1602482
審核編輯:劉清
-
Linux系統
+關注
關注
4文章
593瀏覽量
27397 -
PID控制
+關注
關注
10文章
460瀏覽量
40095 -
Shell
+關注
關注
1文章
365瀏覽量
23375
原文標題:分享一個可排查定位Linux系統CPU 100%的shell腳本
文章出處:【微信號:浩道linux,微信公眾號:浩道linux】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論