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

時間：2021-12-09 15:44:59

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

手機(jī)看文章

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

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

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

SIG目標(biāo)：為龍蜥社區(qū)（OpenAnolis）開源操作系統(tǒng)，提供一個全棧覆蓋內(nèi)核與核心組件的跟蹤和診斷工具，增強(qiáng)龍蜥社區(qū)（OpenAnolis）全棧的可觀察性和可靠性。作者廣成（聞茂泉）、無牙（李靖軒）分別是龍蜥社區(qū)跟蹤診斷技術(shù) SIG 核心成員。
歡迎更多開發(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)開銷很小，已經(jīng)在公司部分業(yè)務(wù)規(guī)模化部署，且持續(xù)穩(wěn)定運(yùn)行 1 年以上。

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

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

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

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

ssar 查看整機(jī) CPU 和內(nèi)存變化趨勢方法。其中 user、system 和 anonpages 分別是內(nèi)核用于指代用戶空間 CPU 使用、內(nèi)核空間 CPU 使用和匿名頁內(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)程級 CPU 影響因素的方法。通過 procs 子命令可以顯示出 2021-09-08T18:38:00 到 2021-09-08T18:40:00 這 2 分鐘內(nèi)，內(nèi)核態(tài) CPU 使用最多的 3 個進(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)程級內(nèi)存影響因素的方法。通過 procs 子命令可以顯示出 2021-09-08T18:36:00 到 2021-09-08T18:38:00 這 2 分鐘內(nèi)，內(nèi)存申請增量最多的 3 個進(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)存波動詳情

通過上面的方法，發(fā)掘出了影響整機(jī)指標(biāo)波動的進(jìn)程，還可以進(jìn)一步通過 proc 子命令更進(jìn)一步追蹤特定進(jìn)程的 CPU 和內(nèi)存變化情況。其中左尖括號（<）表示 2021-08-09T11:39:00 時刻該 sresar 進(jìn)程還沒有啟動，右尖括號（>）表示 2021-08-09T11:47:00 時刻該 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秒級精度的系統(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)時的壓力情況。這里明顯可以看出傳統(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詳情

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

$ ssar load2p -c 2021-09-08T17:25:00 --stackinfo# 通過調(diào)用棧信息，再結(jié)合一定的內(nèi)核代碼知識，即可以判斷出當(dāng)時系統(tǒng)問題。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)的問題，一直是日常運(yùn)維中最常見的問題之一。有時候我們會從系統(tǒng)日志中看到類似這樣的日志信息“page allocction failure: order:4”，這是 free 內(nèi)存不足，并且伴隨內(nèi)存碎片化，內(nèi)核空間申請不到高階內(nèi)存的表現(xiàn)。

定位這類問題需先對整機(jī)內(nèi)存不足程度做一個診斷，anonpages 指標(biāo)是匿名頁，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 匿名頁內(nèi)存的增長，memfree 空閑內(nèi)存逐步減少，到達(dá)一定閾值后，開始異步內(nèi)存回收 pgsteal_kswapd，空閑內(nèi)存進(jìn)一步減少進(jìn)一步引起直接內(nèi)存回收 pgsteal_direct。

在這樣空閑內(nèi)存嚴(yán)重不足的前提下，可能會進(jìn)一步引發(fā)內(nèi)核高階內(nèi)存不足的情況發(fā)生。從數(shù)據(jù)中可以看到 2021-09-09T10:46:00 時刻的 order4 內(nèi)存庫存為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 級別的內(nèi)存顛簸問題

在 cgroup 層面出現(xiàn)內(nèi)存不足時，也有一個內(nèi)存顛簸問題，會引起系統(tǒng)嚴(yá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 磁盤，有時候磁盤 util 也會被打滿到 100%，可以觀察到相應(yīng)的磁盤讀 IO 高達(dá)數(shù)萬，同時單次讀 IO 大小只有 10 多個 Kb 大小。造成這種情況的最常見原因之一是 cgroup 級別的內(nèi)存顛簸。通過內(nèi)核指標(biāo) pgmajfault 可以看到在 IO 打滿的同時每秒整機(jī)主缺頁中斷數(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)一步，通過 ssar 的 procs 子命令，可以定位到發(fā)生大量主缺頁中斷的正是 pid 為 58532 和 46873 這 2 個 java 進(jìn)程。引起 java 進(jìn)程大量發(fā)生主缺頁中斷的原因是進(jìn)程 rss 內(nèi)存極度逼近 cgroup 組設(shè)置的memory.limit_in_bytes 值，導(dǎo)致 cgroup 組內(nèi)留給 clean 狀態(tài)的代碼段內(nèi)存空間不足以完全加載所有程序代碼段。所以代碼段在程序執(zhí)行中，只能不斷的被丟棄再從磁盤讀取。

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

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

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

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

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

$ 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 ?

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

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

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

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

$ 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ù)據(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ù)和字符串形式的指標(biāo)，參考如下用法。

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

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

特定 CPU 的 softirq 資源消耗過多，會影響此 CPU 上用于用戶空間的資源使用。因此當(dāng)中斷分布不均時，會嚴(yán)重影響用戶空間進(jìn)程的執(zhí)行。首先需要了解 softirq 資源消耗在各個 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 ?

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

tsar2 irqtop 即可快速定位引起 cpu5 的 softirq 資源占比高的原因是中斷名稱為 virtio-output.1 的 158 號中斷，并且顯示出每秒平均中斷數(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 級別的中斷情況不開啟歷史采集，需要將配置文件中 interrupts 部分修改為如下配置開啟。

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

$ 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 等高級語言的解析。使用方法就是在命令上增加一個 --api 選項。

$ 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"}] 對于 shell 等腳本解析，ssar 也提供了便利，-H 選項可以隱藏掉各種 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 對于數(shù)據(jù)項中出現(xiàn)的各種“-”、“*”和“<”等符號信息，提供-P 選項參數(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 工具代碼庫地址：https://codeup.openanolis.cn/codeup/tracing_diagnosis/ssar.git—— 完 ——
關(guān)于龍蜥社區(qū)SIGSIG是開放的，并爭取讓交付成果成為社區(qū)發(fā)行的一部分，由組內(nèi)核心成員主導(dǎo)治理，可通過郵件列表和組內(nèi)的成員進(jìn)行交流。龍蜥社區(qū)SIG目前已超20個，包括跟蹤診斷技術(shù)SIG、商密軟件棧、高性能存儲技術(shù)SIG、Java語言與虛擬機(jī)SIG、Cloud Kernel、OceanBase SIG等。

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