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

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

關鍵字： SAR CPU 內存 TCP

手機看文章

掃描二維碼
隨時隨地手機看文章

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

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

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

網址：https://openanolis.cn/sig/tracing

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

前言

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

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

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

一、定位 CPU 和內存波動時的進程級因素

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

ssar 查看整機 CPU 和內存變化趨勢方法。其中 user、system 和 anonpages 分別是內核用于指代用戶空間 CPU 使用、內核空間 CPU 使用和匿名頁內存的指標名。

$ 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 查看進程級 CPU 影響因素的方法。通過 procs 子命令可以顯示出 2021-09-08T18:38:00 到 2021-09-08T18:40:00 這 2 分鐘內，內核態(tài) CPU 使用最多的 3 個進程列表。pucpu、pscpu 和 pcpu 分別表示該進程的用戶空間 CPU 利用率，內核空間 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 查看進程級內存影響因素的方法。通過 procs 子命令可以顯示出 2021-09-08T18:36:00 到 2021-09-08T18:38:00 這 2 分鐘內，內存申請增量最多的 3 個進程列表。rss_dlt 表示 rss 內存的增量值。

$ 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

二、跟蹤單進程的CPU和內存波動詳情

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

$ 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 指標，load5s 指標比 load1、load5 和 load15 指標更加精準，更能反映系統(tǒng)當時的壓力情況。這里明顯可以看出傳統(tǒng)的 load1 指標在系統(tǒng)負載壓力消失后，還一定的滯后性，但load5s指標卻可以精準的顯示機器的負載壓力。

$ 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 核數一定倍數的情況，會觸發(fā) load 詳情的采集，其中針對 D 狀態(tài)線程會抽樣記錄內核調用棧。使用 load2p 可以顯示詳細的 D 狀態(tài)調用棧信息。

$ ssar load2p -c 2021-09-08T17:25:00 --stackinfo# 通過調用棧信息，再結合一定的內核代碼知識，即可以判斷出當時系統(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

五、診斷整機高階內存不足情況

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

定位這類問題需先對整機內存不足程度做一個診斷，anonpages 指標是匿名頁，memfree 指標是整機 free 內存， pgsteal_kswapd 指標是每秒異步內存回收數量，pgsteal_direct 是每秒直接內存回收數量。

$ 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 匿名頁內存的增長，memfree 空閑內存逐步減少，到達一定閾值后，開始異步內存回收 pgsteal_kswapd，空閑內存進一步減少進一步引起直接內存回收 pgsteal_direct。

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

在 cgroup 層面出現內存不足時，也有一個內存顛簸問題，會引起系統(tǒng)嚴重的問題。

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

七、網絡 TCP 重傳擴展信息

在主機網絡層面，日常運維中也會受到網絡丟包、重傳和亂序等問題的困擾。這里也提供了幾組更加深入的網絡指標供診斷網絡問題使用。

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

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

以上數據再結合 ssar 的歷史數據，找到某些重傳或亂序的異常點，可以幫我們很快定位一些 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 建連請求，導致 TCP 的 accept 隊列滿了，這種情況說明到達服務端的新建連接請求比服務端 accept() 消費新的連接請求的速度要快，有可能是突發(fā)來了較多的建連請求，也可能是服務端長時間沒有調用 accept() 來消費 accept 隊列中的半連接請求。

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

做驅動開發(fā)的同學很可能希望能記錄自己的驅動模塊中一些性能數據，ssar 工具為這種場景提供了簡單和完善的采集方案。只需要驅動開發(fā)同學，將內核模塊中的性能指標通過/proc/或/sys/下的偽文件方式暴露為用戶空間即可。數據可以是累積值，也可以是瞬時值，例如 mydev 偽文件中有 2 個值，左側的indicator1 是累積值，右側的 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 # 重啟采集進程配置文件生效 ?

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

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

命令略微改變下，獲取實時數據。

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

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

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

特定 CPU 的 softirq 資源消耗過多，會影響此 CPU 上用于用戶空間的資源使用。因此當中斷分布不均時，會嚴重影響用戶空間進程的執(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高達百分之十幾之多。針對更多核 CPU 的情況，可以使用 tsar2 cputop 子命令排序輸出 softirq 占用比最高的 CPU。

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

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

默認情況下 CPU 級別的中斷情況不開啟歷史采集，需要將配置文件中 interrupts 部分修改為如下配置開啟。

{src_path='interrupts', turn=true, gzip=true}, 如果需要獲取實時數據，可將上面命令增加-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

十、支持靈活的數據輸出和解析

ssar 不僅數據指標非常豐富，而且輸出格式上也非常易于使用和解析。ssar 的所有數據輸出，都支持支持 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 對于數據項中出現的各種“-”、“*”和“<”等符號信息，提供-P 選項參數隱藏輸出，可以讓上層調用腳本減少處理異常數據的工作。

$ 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—— 完 ——
關于龍蜥社區(qū)SIGSIG是開放的，并爭取讓交付成果成為社區(qū)發(fā)行的一部分，由組內核心成員主導治理，可通過郵件列表和組內的成員進行交流。龍蜥社區(qū)SIG目前已超20個，包括跟蹤診斷技術SIG、商密軟件棧、高性能存儲技術SIG、Java語言與虛擬機SIG、Cloud Kernel、OceanBase SIG等。

女人被狂躁到高潮视频免费无遮挡,内射人妻骚骚骚,免费人成小说在线观看网站,九九影院午夜理论片少妇,免费av永久免费网址

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