一、問題背景
工作中當你服務器CPU達到100%時，該如何排查異常故障呢？
突然收到運維郵件報警，顯示數(shù)據(jù)平臺服務器cpu利用率達到了98.94%，而且最近一段時間一直持續(xù)在70%以上，看起來像是硬件資源到瓶頸需要擴容了，但仔細思考就會發(fā)現(xiàn)咱們的業(yè)務系統(tǒng)并不是一個高并發(fā)或者CPU密集型的應用，這個利用率有點太夸張，硬件瓶頸應該不會這么快就到了，一定是哪里的業(yè)務代碼邏輯有問題。
二、排查思路
2.1 定位高負載進程 pid
首先登錄到服務器使用top命令確認服務器的具體情況，根據(jù)具體情況再進行分析
通過觀察load average，以及負載評判標準（8核），可以確認服務器存在負載較高的情況；
觀察各個進程資源使用情況，可以看出進程id為682的進程，有著較高的CPU占比。
2.2 定位具體的異常業(yè)務
這里咱們可以使用 pwdx 命令根據(jù) pid 找到業(yè)務進程路徑，進而定位到負責人和項目：
可得出結論：該進程對應的就是數(shù)據(jù)平臺的web服務。
2.3 定位異常線程及具體代碼行
傳統(tǒng)的方案一般是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 步還是太繁瑣耗時了！
將上面的流程封裝為了一個工具：show-busy-java-threads.sh，可以很方便的定位線上的這類問題：
可得出結論：是系統(tǒng)中一個時間工具類方法的執(zhí)行cpu占比較高，定位到具體方法后，查看代碼邏輯是否存在性能問題。
如果線上問題比較緊急，可以省略 2.1、2.2 直接執(zhí)行 2.3，這里從多角度剖析只是為了給大家呈現(xiàn)一個完整的分析思路。
$ wget --no-check-certificate https://raw.githubusercontent.com/superhj1987/awesome-scripts/master/java/bin/show-busy-java-threads
$ chmod +x show-busy-java-threads
$ ./show-busy-java-threads
cat 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 <<EOF
Usage: ${PROG} [OPTION]...
Find out the highest cpu consumed threads of java, and print the stack of these threads.
Example: ${PROG} -c 10
Options:
-p, --pid find out the highest cpu consumed threads from the specifed java process,
default from all java process.
-c, --count set the thread count to show, default is 5
-h, --help display this help and exit
EOF
exit $1
}
readonly ARGS=`getopt -n "$PROG" -a -o c:p:h -l count:,pid:,help -- "$@"`
[ $? -ne 0 ] && usage 1
eval set -- "${ARGS}"
while true; do
case "$1" in
-c|--count)
count="$2"
shift 2
;;
-p|--pid)
pid="$2"
shift 2
;;
-h|--help)
usage
;;
--)
shift
break
;;
esac
done
count=${count:-5}
redEcho() {
[ -c /dev/stdout ] && {
# if stdout is console, turn on color output.
echo -ne "\033[1;31m"
echo -n "$@"
echo -e "\033[0m"
} || echo "$@"
}
yellowEcho() {
[ -c /dev/stdout ] && {
# if stdout is console, turn on color output.
echo -ne "\033[1;33m"
echo -n "$@"
echo -e "\033[0m"
} || echo "$@"
}
blueEcho() {
[ -c /dev/stdout ] && {
# if stdout is console, turn on color output.
echo -ne "\033[1;36m"
echo -n "$@"
echo -e "\033[0m"
} || echo "$@"
}
# Check the existence of jstack command!
if ! which jstack &> /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
# 從 所有的 Java進程中找出最消耗CPU的線程（缺省5個），打印出其線程棧
show-busy-java-threads.sh
show-busy-java-threads.sh -c <要顯示的線程棧數(shù)>
show-busy-java-threads.sh -c <要顯示的線程棧數(shù)> -p <指定的Java Process>
# 如果Java進程的用戶 與 執(zhí)行腳本的當前用戶 不同，則jstack不了這個Java進程。
# 為了能切換到Java進程的用戶，需要加sudo來執(zhí)行，即可以解決：
sudo show-busy-java-threads.sh
三、根因分析
經(jīng)過前面的分析與排查，最終定位到一個時間工具類的問題，造成了服務器負載以及cpu使用率的過高。
異常方法邏輯：是把時間戳轉成對應的具體的日期時間格式；
上層調用：計算當天凌晨至當前時間所有秒數(shù)，轉化成對應的格式放入到set中返回結果；
邏輯層：對應的是數(shù)據(jù)平臺實時報表的查詢邏輯，實時報表會按照固定的時間間隔來，并且在一次查詢中有多次（n次）方法調用。
那么可以得到結論，如果現(xiàn)在時間是當天上午10點，一次查詢的計算次數(shù)就是 106060n次=36,000n次計算，而且隨著時間增長，越接近午夜單次查詢次數(shù)會線性增加。由于實時查詢、實時報警等模塊大量的查詢請求都需要多次調用該方法，導致了大量CPU資源的占用與浪費。
四、解決方案
定位到問題之后，首先考慮是要減少計算次數(shù)，優(yōu)化異常方法。排查后發(fā)現(xiàn)，在邏輯層使用時，并沒有使用該方法返回的set集合中的內容，而是簡單的用set的size數(shù)值。確認邏輯后，通過新方法簡化計算（當前秒數(shù)-當天凌晨的秒數(shù)），替換調用的方法，解決計算過多的問題。上線后觀察服務器負載和cpu使用率，對比異常時間段下降了30倍，恢復至正常狀態(tài)，至此該問題得已解決。
五、總結
在編碼的過程中，除了要實現(xiàn)業(yè)務的邏輯，也要注重代碼性能的優(yōu)化。一個業(yè)務需求，能實現(xiàn)，和能實現(xiàn)的更高效、更優(yōu)雅其實是兩種截然不同的工程師能力和境界的體現(xiàn)，而后者也是工程師的核心競爭力。
在代碼編寫完成之后，多做 review，多思考是不是可以用更好的方式來實現(xiàn)。
線上問題不放過任何一個小細節(jié)，細節(jié)是魔鬼，技術的同學需要有刨根問題的求知欲和追求卓越的精神，只有這樣，才能不斷的成長和提升。
六、參考
awesome-scripts
https://github.com/superhj1987/awesome-scripts
useful scripts
https://github.com/oldratlee/useful-scripts
線上問題定位工具，CPU 負載特別高的問題排查分析工具
https://www.cnblogs.com/jovic/p/14882664.html
