線上運行環境有時候會遇到cpu 飆升的場景，一般來講對於多核的虛機，一個常見猝發場景就是高並發導致，核多並發高時，syscall會在鎖這塊 sys 消耗高,當然只有猜測不行，下面就列出了幾個常見捉鬼工具 ，後半部分會拿一個示例。

工具箱

1、nmon promes 分析

尤其是promes ,比較推薦用起來，提供比較立體的系統級別監控

2、perf 分析

perf top -a -G
perf top -a -e cs -G
perf record -g -p 14778 -e cycles sleep 10
TIPS:
perf 采樣界面中按
shift + e 可展開堆棧 
shift + c 可折疊
展開 折疊狀態分別截圖
右方向鍵可以下鉆函數查看其上下文（例如屬於哪個lib），左方向鍵返回
最好排在前面的幾個函數都去下鉆截圖
 

3、系統調用統計

{ top -H -p PID  -b -n 1|grep execname|awk ‘{print $1}‘| sed ‘s/\([0-9]*\)/-p \1/g‘|xargs strace -c  2> /tmp/stat & }; sleep 5;pkill strace

4、調用細節

{ top -H -p PID -b -n 1|grep execname|awk ‘{print $1}‘| sed ‘s/\([0-9]*\)/-p \1/g‘|xargs strace -i -v -T  2> /tmp/detail & }; sleep 5;pkill strace
 

5、sar -wq 1 10

6、vmstat 1 10

7、mpstat -I ALL 1

8、rpm -qa > /tmp/rpms

9、堆棧dump

echo 1 >   /proc/sys/kernel/sysrq
echo t > /proc/sysrq-trigger

一個案例

某數據庫系統導數據時，syscpu 會很高

可以看到每到任務運行時間，sys 就會高企，，初步分析，目標機器有16c，根據經驗懷疑是時間耗在並發鎖處理上，但是具體哪部分需要使用perf 線上抓取堆棧

，可以看見sys time 耗在了spinlock 處，是MM 系統的內存壓實整理例程中，結合該數據庫開啟了hugepage 因此初步可以斷定是因為內存過於碎片化，無法滿足巨頁分配，也就是整體看內存高階頁不足

當然伴隨的現象不止這一個，也註意到問題時刻系統的進程創建非常多，高達每秒數百，如下圖

這個與項目組認為的10並發是對不上的，因此的出的綜合結論是

sys高時間主要耗在了內存碎片整理， 主因是內存不足，伴隨現象之一是線程創建多 fork 300-800/s  內存回收多，很多cache 問題時間段回收，得擴內存，動態模型也似乎有問題，不知道fork 那麽多進程做什麽用 

上面的結論看著很模糊，但是提供了比較全面的現場總結，堅定了問題的排查方向，果然，項目組重新梳理代碼後，發現一處高並發場景，修改參數後，問題得以解決

高規格虛機 sys cpu高現場分析工具箱