系統(tǒng)性能監(jiān)控工具ssar實(shí)例精選 | 龍蜥SIG

時(shí)間：2021-12-09 15:44:59

關(guān)鍵字： SAR CPU 內(nèi)存 TCP

手機(jī)看文章

掃描二維碼
隨時(shí)隨地手機(jī)看文章

[導(dǎo)讀]跟蹤診斷技術(shù)SIG致力于為操作系統(tǒng)生態(tài)提供系統(tǒng)性，工具化，并以數(shù)據(jù)為支撐的發(fā)現(xiàn)、跟蹤和診斷問(wèn)題的能力。SIG目標(biāo)：為龍蜥社區(qū)（OpenAnolis）開(kāi)源操作系統(tǒng)，提供一個(gè)全棧覆蓋內(nèi)核與核心組件的跟蹤和診斷工具，增強(qiáng)龍蜥社區(qū)（OpenAnolis）全棧的可觀察性和可靠性。作者廣成（...

跟蹤診斷技術(shù) SIG 致力于為操作系統(tǒng)生態(tài)提供系統(tǒng)性，工具化，并以數(shù)據(jù)為支撐的發(fā)現(xiàn)、跟蹤和診斷問(wèn)題的能力。

SIG目標(biāo)：為龍蜥社區(qū)（OpenAnolis）開(kāi)源操作系統(tǒng)，提供一個(gè)全棧覆蓋內(nèi)核與核心組件的跟蹤和診斷工具，增強(qiáng)龍蜥社區(qū)（OpenAnolis）全棧的可觀察性和可靠性。作者廣成（聞茂泉）、無(wú)牙（李靖軒）分別是龍蜥社區(qū)跟蹤診斷技術(shù) SIG 核心成員。
歡迎更多開(kāi)發(fā)者加入跟蹤診斷技術(shù)SIG：

網(wǎng)址：https://openanolis.cn/sig/tracing

郵件列表：cloud-kernel@lists.openanolis.cn

前言

ssar 是阿里自研并貢獻(xiàn)至龍蜥社區(qū)的一款系統(tǒng)性能監(jiān)控工具。該工具系統(tǒng)開(kāi)銷很小，已經(jīng)在公司部分業(yè)務(wù)規(guī)模化部署，且持續(xù)穩(wěn)定運(yùn)行 1 年以上。

ssar 工具近期在國(guó)內(nèi)領(lǐng)先的操作系統(tǒng)開(kāi)源社區(qū)及創(chuàng)新平臺(tái)龍蜥社區(qū)開(kāi)源，歡迎大家訪問(wèn)龍蜥社區(qū)（https://openanolis.cn/sig/tracing）下載 ssar 工具源碼適用。源碼中提供了相關(guān)的編譯和安裝步驟，還提供了具體《使用參考手冊(cè)》。

ssar 工具在日常使用中也解決了很多實(shí)際的生產(chǎn)問(wèn)題，為了能讓大家更快速的了解 ssar 的用途，這里特別從案例使用的角度挑選了工具的十大典型使用場(chǎng)景進(jìn)行介紹。

一、定位 CPU 和內(nèi)存波動(dòng)時(shí)的進(jìn)程級(jí)因素

日常運(yùn)維中，整機(jī) CPU 和內(nèi)存經(jīng)常出現(xiàn)較大的增長(zhǎng)，從而引起系統(tǒng)不穩(wěn)定。此時(shí)特別需要能回朔歷史數(shù)據(jù)，查看指標(biāo)波動(dòng)時(shí)刻的進(jìn)程級(jí) CPU 和內(nèi)存等影響因素。

ssar 查看整機(jī) CPU 和內(nèi)存變化趨勢(shì)方法。其中 user、system 和 anonpages 分別是內(nèi)核用于指代用戶空間 CPU 使用、內(nèi)核空間 CPU 使用和匿名頁(yè)內(nèi)存的指標(biāo)名。

$ ssar -i 1 -o user,system,anonpagescollect_datetime user/s system/s anonpages2021-09-08T18:36:00 787.38 145.30 6590885 2021-09-08T18:37:00 299.93 230.25 12808418 2021-09-08T18:38:00 116.58 79.43 14119096 2021-09-08T18:39:00 401.88 101.75 10580258 2021-09-08T18:40:00 332.68 279.62 8759586 ssar 查看進(jìn)程級(jí) CPU 影響因素的方法。通過(guò) procs 子命令可以顯示出 2021-09-08T18:38:00 到 2021-09-08T18:40:00 這 2 分鐘內(nèi)，內(nèi)核態(tài) CPU 使用最多的 3 個(gè)進(jìn)程列表。pucpu、pscpu 和 pcpu 分別表示該進(jìn)程的用戶空間 CPU 利用率，內(nèi)核空間 CPU 利用率和總 CPU 利用率。

$ ssar procs -f 2021-09-08T18:40:00 -r 2 -o pid,ppid,pcpu,pucpu,pscpu,cmd -k pscpu -l 3 pid ppid pcpu pucpu pscpu cmd 1537 1536 95.3 65.0 30.3 java 29349 1 0.3 0.1 0.2 sresar 11 2 0.1 0.0 0.1 migration/0 ssar 查看進(jìn)程級(jí)內(nèi)存影響因素的方法。通過(guò) procs 子命令可以顯示出 2021-09-08T18:36:00 到 2021-09-08T18:38:00 這 2 分鐘內(nèi)，內(nèi)存申請(qǐng)?jiān)隽孔疃嗟?3 個(gè)進(jìn)程列表。rss_dlt 表示 rss 內(nèi)存的增量值。

$ ssar procs -f 2021-09-08T18:38:00 -r 2 -o pid,ppid,rss,rss_dlt,nlwp,cmd -k rss_dlt -l 3 pid ppid rss rss_dlt nlwp cmd 197779 1 14624 9472 1 syslog-ng 185017 1 136328 5400 1 systemd-journal 27495 77722 360 360 1 sleep

二、跟蹤單進(jìn)程的CPU和內(nèi)存波動(dòng)詳情

通過(guò)上面的方法，發(fā)掘出了影響整機(jī)指標(biāo)波動(dòng)的進(jìn)程，還可以進(jìn)一步通過(guò) proc 子命令更進(jìn)一步追蹤特定進(jìn)程的 CPU 和內(nèi)存變化情況。其中左尖括號(hào)（<）表示 2021-08-09T11:39:00 時(shí)刻該 sresar 進(jìn)程還沒(méi)有啟動(dòng)，右尖括號(hào)（>）表示 2021-08-09T11:47:00 時(shí)刻該 sresar 進(jìn)程已經(jīng)結(jié)束。

$ ssar proc -p $(pidof sresar) -i1 -o collect_datetime,rss,min_flt,cmdcollect_datetime rss min_flt cmd start_datetime 2021-08-09T11:39:00 < < < < 2021-08-09T11:40:00 1524 631 sresar 2021-08-09T11:39:182021-08-09T11:41:00 1708 1231 sresar 2021-08-09T11:39:182021-08-09T11:42:00 3552 1748 sresar 2021-08-09T11:39:182021-08-09T11:43:00 3552 1748 sresar 2021-08-09T11:39:182021-08-09T11:44:00 3552 1749 sresar 2021-08-09T11:39:182021-08-09T11:45:00 3552 1749 sresar 2021-08-09T11:39:182021-08-09T11:46:00 3552 1749 sresar 2021-08-09T11:39:182021-08-09T11:47:00 > > > >
$ ssar proc -p $(pidof sresar) -i 1 --mem$ ssar proc -p $(pidof sresar) -i 1 --cpu

三、記錄5秒級(jí)精度的系統(tǒng)load信息

ssar 的 load5s 子命令不僅將 load 的精度提高到了 5s，還創(chuàng)造性增加了load5s 指標(biāo)，load5s 指標(biāo)比 load1、load5 和 load15 指標(biāo)更加精準(zhǔn)，更能反映系統(tǒng)當(dāng)時(shí)的壓力情況。這里明顯可以看出傳統(tǒng)的 load1 指標(biāo)在系統(tǒng)負(fù)載壓力消失后，還一定的滯后性，但load5s指標(biāo)卻可以精準(zhǔn)的顯示機(jī)器的負(fù)載壓力。

$ ssar load5scollect_datetime threads load1 runq load5s2021-08-09T14:17:35 1047 0.28 2 12021-08-09T14:17:40 1058 0.25 1 02021-08-09T14:17:47 3047 113.46 1453 14142021-08-09T14:17:53 3053 264.62 2002 20012021-08-09T14:17:59 3053 403.74 2002 20022021-08-09T14:18:05 1049 371.41 1 02021-08-09T14:18:10 1055 341.67 1 02021-08-09T14:18:15 1048 314.31 1 0
$ ssar load5s -f 2021-07-15T19:00:00 -r 300 -z

四、記錄線程D狀態(tài)異常的stack詳情

對(duì)于 load5s 值大于 CPU 核數(shù)一定倍數(shù)的情況，會(huì)觸發(fā) load 詳情的采集，其中針對(duì) D 狀態(tài)線程會(huì)抽樣記錄內(nèi)核調(diào)用棧。使用 load2p 可以顯示詳細(xì)的 D 狀態(tài)調(diào)用棧信息。

$ ssar load2p -c 2021-09-08T17:25:00 --stackinfo# 通過(guò)調(diào)用棧信息，再結(jié)合一定的內(nèi)核代碼知識(shí)，即可以判斷出當(dāng)時(shí)系統(tǒng)問(wèn)題。page_fault do_page_fault __do_page_fault handle_mm_fault __do_fault filemap_fault __lock_page_or_retry wait_on_page_bit_killable sleep_on_page_killable

五、診斷整機(jī)高階內(nèi)存不足情況

系統(tǒng)內(nèi)存不足相關(guān)的問(wèn)題，一直是日常運(yùn)維中最常見(jiàn)的問(wèn)題之一。有時(shí)候我們會(huì)從系統(tǒng)日志中看到類似這樣的日志信息“page allocction failure: order:4”，這是 free 內(nèi)存不足，并且伴隨內(nèi)存碎片化，內(nèi)核空間申請(qǐng)不到高階內(nèi)存的表現(xiàn)。

定位這類問(wèn)題需先對(duì)整機(jī)內(nèi)存不足程度做一個(gè)診斷，anonpages 指標(biāo)是匿名頁(yè)，memfree 指標(biāo)是整機(jī) free 內(nèi)存， pgsteal_kswapd 指標(biāo)是每秒異步內(nèi)存回收數(shù)量，pgsteal_direct 是每秒直接內(nèi)存回收數(shù)量。

$ ssar -i 1 -o anonpages,memfree,pgsteal_kswapd,pgsteal_directcollect_datetime anonpages memfree pgsteal_kswapd/s pgsteal_direct/s 2021-09-09T10:40:00 11151058 1716004 0.00 0.00 2021-09-09T10:41:00 12008117 1615129 0.00 0.00 2021-09-09T10:42:00 13993906 1404292 0.00 0.00 2021-09-09T10:43:00 15869526 1233360 0.00 0.00 2021-09-09T10:44:00 17135683 1083402 43821.88 0.00 2021-09-09T10:45:00 19488155 829303 45080.95 0.00 2021-09-09T10:46:00 20787968 712429 10452.02 455.90 2021-09-09T10:47:00 21725142 614698 0.00 2313.68 可以看到，隨著系統(tǒng)的 anonpages 匿名頁(yè)內(nèi)存的增長(zhǎng)，memfree 空閑內(nèi)存逐步減少，到達(dá)一定閾值后，開(kāi)始異步內(nèi)存回收 pgsteal_kswapd，空閑內(nèi)存進(jìn)一步減少進(jìn)一步引起直接內(nèi)存回收 pgsteal_direct。

在這樣空閑內(nèi)存嚴(yán)重不足的前提下，可能會(huì)進(jìn)一步引發(fā)內(nèi)核高階內(nèi)存不足的情況發(fā)生。從數(shù)據(jù)中可以看到 2021-09-09T10:46:00 時(shí)刻的 order4 內(nèi)存庫(kù)存為0。

$ ssar -i 1 --node0collect_datetime order0 order1 order2 order3 order4 order52021-09-09T10:40:00 139116 429294 226754 51287 37276 441812021-09-09T10:41:00 20070 89672 37399 51721 37277 441812021-09-09T10:42:00 31154 71323 36612 49952 37277 441812021-09-09T10:43:00 73309 93733 36843 49249 36256 441572021-09-09T10:44:00 76885 73331 36409 48408 35477 421812021-09-09T10:45:00 46915 140381 40744 47815 34313 441712021-09-09T10:46:00 28346 16054 6420 141 0 02021-09-09T10:47:00 34694 29549 16750 3042 1481 319

六、定位 Cgroup 級(jí)別的內(nèi)存顛簸問(wèn)題

在 cgroup 層面出現(xiàn)內(nèi)存不足時(shí)，也有一個(gè)內(nèi)存顛簸問(wèn)題，會(huì)引起系統(tǒng)嚴(yán)重的問(wèn)題。

$ tsar2 --io -i 1 -I nvme0n1p1 -s rs,rarqsz,utilTime nvme0n1p1 nvme0n1p1 nvme0n1p1Time rs rarqsz util09/09/21-14:50 66.1K 10.25 100.0009/09/21-14:51 71.1K 13.25 100.0009/09/21-14:52 63.8k 10.00 100.0009/09/21-14:53 57.0k 14.50 100.0009/09/21-14:54 64.0k 14.00 100.00 性能優(yōu)越的 nvme 磁盤，有時(shí)候磁盤 util 也會(huì)被打滿到 100%，可以觀察到相應(yīng)的磁盤讀 IO 高達(dá)數(shù)萬(wàn)，同時(shí)單次讀 IO 大小只有 10 多個(gè) Kb 大小。造成這種情況的最常見(jiàn)原因之一是 cgroup 級(jí)別的內(nèi)存顛簸。通過(guò)內(nèi)核指標(biāo) pgmajfault 可以看到在 IO 打滿的同時(shí)每秒整機(jī)主缺頁(yè)中斷數(shù)也非常高，這正是造成系統(tǒng) IO 打滿的直接原因。

$ ssar -i 1 -o pgmajfaultcollect_datetime pgmajfault/s2021-09-09T14:50:00 43491.31 2021-09-09T14:51:00 44432.01 2021-09-09T14:52:00 45464.78 2021-09-09T14:53:00 43991.22 2021-09-09T14:54:00 45922.34
$ ssar procs -f 2021-09-09T14:51:00 -r 1 -o pid,rss,maj_flt,maj_dlt,cmd -k maj_dlt -l 5 pid rss maj_flt maj_dlt cmd 58532 8240736 126575484 1305199 java 46873 8237292 173405708 1257924 java 51357 577796 13201 63 python 253136 566352 11687 46 syslog-ng 46025 1229520 478 42 bash 進(jìn)一步，通過(guò) ssar 的 procs 子命令，可以定位到發(fā)生大量主缺頁(yè)中斷的正是 pid 為 58532 和 46873 這 2 個(gè) java 進(jìn)程。引起 java 進(jìn)程大量發(fā)生主缺頁(yè)中斷的原因是進(jìn)程 rss 內(nèi)存極度逼近 cgroup 組設(shè)置的memory.limit_in_bytes 值，導(dǎo)致 cgroup 組內(nèi)留給 clean 狀態(tài)的代碼段內(nèi)存空間不足以完全加載所有程序代碼段。所以代碼段在程序執(zhí)行中，只能不斷的被丟棄再?gòu)拇疟P讀取。

七、網(wǎng)絡(luò) TCP 重傳擴(kuò)展信息

在主機(jī)網(wǎng)絡(luò)層面，日常運(yùn)維中也會(huì)受到網(wǎng)絡(luò)丟包、重傳和亂序等問(wèn)題的困擾。這里也提供了幾組更加深入的網(wǎng)絡(luò)指標(biāo)供診斷網(wǎng)絡(luò)問(wèn)題使用。

$ tsar2 --retranTime --retran--- --retran--- --retran-- --retran-- -retran- ----retran----Time RetransSegs FastRetrans LossProbes RTORetrans RTORatio LostRetransmit08/09/21-16:45 49.44 34.41 16.02 6.41 12.97 0.2608/09/21-16:50 44.07 29.03 16.84 8.21 18.63 0.1308/09/21-16:55 37.58 18.72 10.91 11.44 30.44 0.02
$ tsar2 --tcpofoTime -tcpofo-- ---tcpofo--- ---tcpofo--- -tcpofo- tcpofo- -tcpofo-Time OfoPruned DSACKOfoSent DSACKOfoRecv OFOQueue OFODrop OFOMerge08/09/21-16:45 0.00 0.00 0.00 251.86 0.00 0.0008/09/21-16:50 0.00 0.00 0.00 182.35 0.00 0.0008/09/21-16:55 0.00 0.00 0.00 115.70 0.00 0.00 ?

在 tcp 重傳方面，我們提供了許多相比 tcp 重傳率之外，更為細(xì)致的指標(biāo)?，F(xiàn)代 Linux 系統(tǒng)，早已經(jīng)有除 200ms 超時(shí)重傳之外的多種重傳的方式來(lái)加速網(wǎng)絡(luò)抖動(dòng)或者異常狀態(tài)下的恢復(fù)。這里我們將 TCP 的重傳進(jìn)行了更細(xì)致的分類，包括快重傳、尾包重傳和超時(shí)重傳，不同的重傳對(duì)于業(yè)務(wù)的影響是完全不同的，相當(dāng)多的時(shí)候，我們可能觀察到快重傳或者尾包重傳很高，但超時(shí)重傳并不多，這個(gè)時(shí)候往往并不影響業(yè)務(wù)。而一旦出現(xiàn)大量的超時(shí)重傳，往往意味著真正的網(wǎng)絡(luò)異常。

--tcpofo 可以讓我們看到當(dāng)前收到的一些亂序的情況，亂序跟重傳往往是關(guān)聯(lián)的，一般情況下，收到亂序報(bào)文會(huì)看到 OFOQueue 增加，而一旦看到 OFODrop，則說(shuō)明收到的亂序的報(bào)文被丟失了，這個(gè)時(shí)候很可能是我們隊(duì)列中亂序報(bào)文太多，或者我們應(yīng)用進(jìn)程沒(méi)有及時(shí)將 tcp 接收隊(duì)列中的數(shù)據(jù)包收走。

以上數(shù)據(jù)再結(jié)合 ssar 的歷史數(shù)據(jù)，找到某些重傳或亂序的異常點(diǎn)，可以幫我們很快定位一些 tcp 問(wèn)題的原因。

$ tsar2 --tcpdropTime ----tcpdrop----- --tcpdrop-- ----tcpdrop---- ----tcpdrop---- --tcpdrop--Time LockDroppedIcmps ListenDrops ListenOverflows PrequeueDropped BacklogDrop08/09/21-16:45 0.00 0.28 0.28 0.00 0.0008/09/21-16:50 0.00 1.97 1.97 0.00 0.0008/09/21-16:55 0.00 21.96 21.96 0.00 0.00
$ tsar2 --tcperrTime ---tcperr--- ---tcperr--- ---tcperr--- ---tcperr---- --tcperr---Time RenoFailures SackFailures LossFailures AbortOnMemory AbortFailed08/09/21-16:45 0.00 0.00 0.00 0.00 0.0008/09/21-16:50 0.00 0.00 0.00 0.00 0.0008/09/21-16:55 0.00 0.00 0.00 0.00 0.00 ?

對(duì)于 TCP 的一些典型丟包和異常，可以通過(guò) --tcpdrop/--tcperr 來(lái)觀察，譬如上面我們看到在 08/09/21-16:55 時(shí)，有較多的 ListenDrops 和 ListenOverflows，說(shuō)明有較多的 TCP SYN 建連請(qǐng)求，導(dǎo)致 TCP 的 accept 隊(duì)列滿了，這種情況說(shuō)明到達(dá)服務(wù)端的新建連接請(qǐng)求比服務(wù)端 accept() 消費(fèi)新的連接請(qǐng)求的速度要快，有可能是突發(fā)來(lái)了較多的建連請(qǐng)求，也可能是服務(wù)端長(zhǎng)時(shí)間沒(méi)有調(diào)用 accept() 來(lái)消費(fèi) accept 隊(duì)列中的半連接請(qǐng)求。

八、自定義采集任意系統(tǒng)指標(biāo)

做驅(qū)動(dòng)開(kāi)發(fā)的同學(xué)很可能希望能記錄自己的驅(qū)動(dòng)模塊中一些性能數(shù)據(jù)，ssar 工具為這種場(chǎng)景提供了簡(jiǎn)單和完善的采集方案。只需要驅(qū)動(dòng)開(kāi)發(fā)同學(xué)，將內(nèi)核模塊中的性能指標(biāo)通過(guò)/proc/或/sys/下的偽文件方式暴露為用戶空間即可。數(shù)據(jù)可以是累積值，也可以是瞬時(shí)值，例如 mydev 偽文件中有 2 個(gè)值，左側(cè)的indicator1 是累積值，右側(cè)的 indicator2 是瞬時(shí)值。

$ cat /proc/mydev104377580 7252 ssar 工具配置采集的方法比較簡(jiǎn)單。

$ cat /etc/ssar/sys.conf [file]default=[ {src_path='/proc/mydev', turn=true, cfile='mydev'},]
$ sudo systemctl restart sresar # 重啟采集進(jìn)程配置文件生效 ?

修改完配置完后，可以使用如下命令獲取歷史數(shù)據(jù)。

$ ssar -i 1 -f 2021-09-09T17:20:00 -r 60 -o 'metric=d:cfile=mydev:line=1:column=1:alias=indicator1;metric=c:cfile=mydev:line=1:column=2:alias=indicator2'collect_datetime indicator1/s indicator22021-09-09T17:30:00 884.40 71922021-09-09T17:31:00 652.15 70782021-09-09T17:32:00 799.73 76762021-09-09T17:33:00 708.37 79532021-09-09T17:34:00 596.47 7738 ?

命令略微改變下，獲取實(shí)時(shí)數(shù)據(jù)。

$ ssar -i 1s -f 10 -o 'metric=d|cfile=mydev|line=1|column=1|alias=indicator1;metric=c|cfile=mydev|line=1|column=2|alias=indicator2'collect_datetime indicator1/s indicator22021-09-09T17:40:00 668.50 70042021-09-09T17:40:01 480.38 61152021-09-09T17:40:02 651.55 64962021-09-09T17:40:03 789.15 64332021-09-09T17:40:04 867.93 7508 不安裝ssar軟件包，只拷貝 ssar 程序，也可以直接使用獲取實(shí)時(shí)數(shù)據(jù)。

$ ssar -o 'metric=d:cfile=stat:line=2:column=2-11:alias=cpu0_{column};' # cpu0第2到11列數(shù)據(jù) $ ssar -o 'metric=d|cfile=stat|line=2-17|column=5|alias=idle_{line};' # cpu0到15的idle ssar 還支持指標(biāo)不是整數(shù)的情況，支持實(shí)數(shù)和字符串形式的指標(biāo)，參考如下用法。

$ ssar -o 'metric=c:cfile=loadavg:line=1:column=1:dtype=float:alias=load1'# load1實(shí)型數(shù)據(jù)$ ssar -o 'metric=c|cfile=loadavg|line=1|column=4|dtype=string|alias=rp'# rp字符串信息如果只想采集這個(gè)驅(qū)動(dòng)指標(biāo)文件mydev，ssar還提供了2個(gè)配置參數(shù)load5s_flag 和 proc_flag 來(lái)關(guān)閉load和進(jìn)程級(jí)指標(biāo)采集。節(jié)省不必要的磁盤存儲(chǔ)空間開(kāi)銷。

九、診斷特定CPU中斷不均情況

特定 CPU 的 softirq 資源消耗過(guò)多，會(huì)影響此 CPU 上用于用戶空間的資源使用。因此當(dāng)中斷分布不均時(shí)，會(huì)嚴(yán)重影響用戶空間進(jìn)程的執(zhí)行。首先需要了解 softirq 資源消耗在各個(gè) CPU 之間是否均衡。

$ tsar2 --cpu -I cpu,cpu0,cpu1,cpu2,cpu3,cpu4,cpu5,cpu6,cpu7 -s sirq -i 1Time --cpu-- -cpu0-- -cpu1-- -cpu2-- -cpu3-- -cpu4-- -cpu5-- -cpu6-- -cpu7--Time sirq sirq sirq sirq sirq sirq sirq sirq sirq09/09/21-21:15 1.44 0.01 0.01 0.01 2.28 0.02 15.69 2.72 5.5709/09/21-21:16 1.98 0.01 0.01 0.01 2.56 0.03 18.40 2.56 8.9309/09/21-21:17 2.61 0.01 0.01 0.01 2.31 0.09 17.28 2.21 3.5909/09/21-21:18 1.84 0.01 0.01 0.01 1.97 0.03 12.16 2.04 8.7509/09/21-21:19 1.32 0.01 0.01 0.01 1.66 0.03 16.52 1.69 6.77 ?

通過(guò)命令可以看到，softirq 在各個(gè) CPU 之間分布并不均勻，cpu5 的 softirq高達(dá)百分之十幾之多。針對(duì)更多核 CPU 的情況，可以使用 tsar2 cputop 子命令排序輸出 softirq 占用比最高的 CPU。

tsar2 irqtop 即可快速定位引起 cpu5 的 softirq 資源占比高的原因是中斷名稱為 virtio-output.1 的 158 號(hào)中斷，并且顯示出每秒平均中斷數(shù)。

$ tsar2 irqtop -i 1 -C 5 Time --N1--- N1- N1- --------N1-------- --N2--- N2- N2- --------N2------Time count irq CPU name count irq CPU name 09/09/21-22:58 981.80 158 5 virtio-output.1 304.02 154 5 nvme0q0, nvme0q109/09/21-22:59 765.32 158 5 virtio-output.1 234.97 154 5 nvme0q0, nvme0q109/09/21-23:00 763.63 154 5 nvme0q0, nvme0q1 393.88 158 5 virtio-output.109/09/21-23:01 531.87 158 5 virtio-output.1 225.03 154 5 nvme0q0, nvme0q109/09/21-23:02 557.23 158 5 virtio-output.1 150.25 154 5 nvme0q0, nvme0q1 ?

默認(rèn)情況下 CPU 級(jí)別的中斷情況不開(kāi)啟歷史采集，需要將配置文件中 interrupts 部分修改為如下配置開(kāi)啟。

{src_path='interrupts', turn=true, gzip=true}, 如果需要獲取實(shí)時(shí)數(shù)據(jù)，可將上面命令增加-l選項(xiàng)即可。

$ tsar2 --cpu -I cpu,cpu0,cpu1,cpu2,cpu3,cpu4,cpu5,cpu6,cpu7 -s sirq -i 1 -l$ tsar2 irqtop -i 1 -C 5 -l

十、支持靈活的數(shù)據(jù)輸出和解析

ssar 不僅數(shù)據(jù)指標(biāo)非常豐富，而且輸出格式上也非常易于使用和解析。ssar 的所有數(shù)據(jù)輸出，都支持支持 json 格式輸出，便于 python 等高級(jí)語(yǔ)言的解析。使用方法就是在命令上增加一個(gè) --api 選項(xiàng)。

$ ssar -r 5 -o user,system,memfree,anonpages --api[{"anonpages":"280824","collect_datetime":"2021-09-10T12:00:00","memfree":"181753024","system":"-","user":"-"},{"anonpages":"280812","collect_datetime":"2021-09-10T12:05:00","memfree":"181752704","system":"2.35","user":"1.22"}] 對(duì)于 shell 等腳本解析，ssar 也提供了便利，-H 選項(xiàng)可以隱藏掉各種 header 信息。

$ ssar -r 5 -o user,system,memfree,anonpages -H2021-09-10T12:00:00 - - 81754836 280296 2021-09-10T12:05:00 1.29 2.57 81756712 280228 對(duì)于數(shù)據(jù)項(xiàng)中出現(xiàn)的各種“-”、“*”和“<”等符號(hào)信息，提供-P 選項(xiàng)參數(shù)隱藏輸出，可以讓上層調(diào)用腳本減少處理異常數(shù)據(jù)的工作。

$ ssar -r 5 -o user,system,memfree,anonpages -H -P2021-09-10T12:10:00 1.31 2.58 81747740 281676 ?

ssar 工具代碼庫(kù)地址：https://codeup.openanolis.cn/codeup/tracing_diagnosis/ssar.git—— 完 ——
關(guān)于龍蜥社區(qū)SIGSIG是開(kāi)放的，并爭(zhēng)取讓交付成果成為社區(qū)發(fā)行的一部分，由組內(nèi)核心成員主導(dǎo)治理，可通過(guò)郵件列表和組內(nèi)的成員進(jìn)行交流。龍蜥社區(qū)SIG目前已超20個(gè)，包括跟蹤診斷技術(shù)SIG、商密軟件棧、高性能存儲(chǔ)技術(shù)SIG、Java語(yǔ)言與虛擬機(jī)SIG、Cloud Kernel、OceanBase SIG等。