跟蹤診斷技術(shù) SIG 致力于為操作系統(tǒng)生態(tài)提供系統(tǒng)性，工具化，并以數(shù)據(jù)為支撐的發(fā)現(xiàn)、跟蹤和診斷問題的能力。
歡迎更多開發(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)定運行 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īng)常出現(xiàn)較大的增長，從而引起系統(tǒng)不穩(wěn)定。此時特別需要能回朔歷史數(shù)據(jù)，查看指標(biāo)波動時刻的進(jìn)程級 CPU 和內(nèi)存等影響因素。
ssar 查看整機 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 65908852021-09-08T18:37:00 299.93 230.25 128084182021-09-08T18:38:00 116.58 79.43 141190962021-09-08T18:39:00 401.88 101.75 105802582021-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 3pid ppid pcpu pucpu pscpu cmd1537 1536 95.3 65.0 30.3 java29349 1 0.3 0.1 0.2 sresar11 2 0.1 0.0 0.1 migration/0
ssar procs -f 2021-09-08T18:38:00 -r 2 -o pid,ppid,rss,rss_dlt,nlwp,cmd -k rss_dlt -l 3pid ppid rss rss_dlt nlwp cmd197779 1 14624 9472 1 syslog-ng185017 1 136328 5400 1 systemd-journal27495 77722 360 360 1 sleep
通過上面的方法，發(fā)掘出了影響整機指標(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_datetime2021-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
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)的顯示機器的負(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
對于 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_faultdo_page_fault__do_page_faulthandle_mm_fault__do_faultfilemap_fault__lock_page_or_retrywait_on_page_bit_killablesleep_on_page_killable
系統(tǒng)內(nèi)存不足相關(guān)的問題，一直是日常運維中最常見的問題之一。有時候我們會從系統(tǒng)日志中看到類似這樣的日志信息“page allocction failure: order:4”，這是 free 內(nèi)存不足，并且伴隨內(nèi)存碎片化，內(nèi)核空間申請不到高階內(nèi)存的表現(xiàn)。
定位這類問題需先對整機內(nèi)存不足程度做一個診斷，anonpages 指標(biāo)是匿名頁，memfree 指標(biāo)是整機 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/s2021-09-09T10:40:00 11151058 1716004 0.00 0.002021-09-09T10:41:00 12008117 1615129 0.00 0.002021-09-09T10:42:00 13993906 1404292 0.00 0.002021-09-09T10:43:00 15869526 1233360 0.00 0.002021-09-09T10:44:00 17135683 1083402 43821.88 0.002021-09-09T10:45:00 19488155 829303 45080.95 0.002021-09-09T10:46:00 20787968 712429 10452.02 455.902021-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 層面出現(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 打滿的同時每秒整機主缺頁中斷數(shù)也非常高，這正是造成系統(tǒng) IO 打滿的直接原因。
ssar -i 1 -o pgmajfaultcollect_datetime pgmajfault/s:50:00 43491.31:51:00 44432.01:52:00 45464.78:53:00 43991.22:54:00 45922.34ssar procs -f 2021-09-09T14:51:00 -r 1 -o pid,rss,maj_flt,maj_dlt,cmd -k maj_dlt -l 5pid rss maj_flt maj_dlt cmd58532 8240736 126575484 1305199 java46873 8237292 173405708 1257924 java51357 577796 13201 63 python253136 566352 11687 46 syslog-ng46025 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ò)層面，日常運維中也會受到網(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ā)來了較多的建連請求，也可能是服務(wù)端長時間沒有調(diào)用 accept() 來消費 accept 隊列中的半連接請求。
做驅(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[]default=[{src_path='/proc/mydev', turn=true, cfile='mydev'},]$ sudo systemctl restart sresar
修改完配置完后，可以使用如下命令獲取歷史數(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 -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ù)據(jù)。
./ssar -i 1s -f +10 -o'metric=d|src_path=/proc/mydev|line=1|column=1|alias=indicator1;metric=c|src_path=/proc/mydev|line=1|column=2|alias=indicator2'
對于多行或者多列指標(biāo)含義相近的情況，也可以參考如下 2 個用法。
$ 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 -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 的 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 5Time --N1--- N1- N1- --------N1-------- --N2--- N2- N2- --------N2------Time count irq CPU name count irq CPU name09/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
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 2802962021-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
SIG是開放的，并爭取讓交付成果成為社區(qū)發(fā)行的一部分，由組內(nèi)核心成員主導(dǎo)治理，可通過郵件列表和組內(nèi)的成員進(jìn)行交流。龍蜥社區(qū)SIG目前已超20個，包括跟蹤診斷技術(shù)SIG、商密軟件棧、高性能存儲技術(shù)SIG、Java語言與虛擬機SIG、Cloud Kernel、OceanBase SIG等。
SIG網(wǎng)址：https://openanolis.cn/sig
