跟蹤診斷技術 SIG 致力於為作業系統生態提供系統性，工具化，並以資料為支撐的發現、跟蹤和診斷問題的能力。

SIG目標：為龍蜥社群（OpenAnolis ）開源作業系統，提供一個全棧覆蓋核心與核心元件的跟蹤和診斷工具，增強龍蜥社群（OpenAnolis）全棧的可觀察性和可靠性。

作者廣成（聞茂泉）、無牙（李靖軒）分別是龍蜥社群 跟蹤診斷技術 SIG 核心成員。

歡迎更多開發者加入跟蹤診斷技術SIG：

網址：

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

前言

ssar 是阿里自研並貢獻至龍蜥社群的一款系統效能監控工具。該工具系統開銷很小，已經在公司部分業務規模化部署， 且持續穩定執行 1 年以上。

ssar 工具近期在國內領先的作業系統開源社群及創新平臺龍蜥社群開源，歡迎大家訪問龍蜥社群（）下載 ssar 工具原始碼適用。原始碼中提供了相關的編譯和安裝步驟，還提供了具體《使用參考手冊》。

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

一、定位 CPU 和記憶體波動時的程式級因素

日常運維中，整機 CPU 和記憶體經常出現較大的增長，從而引起系統不穩定。此時特別需要能回朔歷史資料，檢視指標波動時刻的程式級 CPU 和記憶體等影響因素。

ssar 檢視整機 CPU 和記憶體變化趨勢方法 。其中 user、system 和 anonpages 分別是核心用於指代使用者空間 CPU 使用、核心空間 CPU 使用和匿名頁記憶體的指標名。

$ ssar -i 1 -o user,system,anonpages
collect_datetime       user/s   system/s  anonpages
2021-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 分鐘內，核心態 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和記憶體波動詳情

透過上面的方法，發掘出了影響整機指標波動的程式，還可以進一步透過 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         2
021-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秒級精度的系統load資訊

ssar 的 load5s 子命令不僅將 load 的精度提高到了 5s，還創造性增加了load5s 指標， load5s 指標比 load1、load5 和 load15 指標更加精準 ，更能反映系統當時的壓力情況。這裡明顯可以看出傳統的 load1 指標在系統負載壓力消失後，還一定的滯後性，但load5s指標卻可以精準的顯示機器的負載壓力。


$ ssar load5s

collect_datetime       threads    load1   runq  load5s


2021-08-09T14:17:35       1047     0.28      2      1


2021-08-09T14:17:40       1058     0.25      1      0


2021-08-09T14:17:47       3047   113.46   1453   1414


2021-08-09T14:17:53       3053   264.62   2002   2001


2021-08-09T14:17:59       3053   403.74   2002   2002


2021-08-09T14:18:05       1049   371.41      1      0


2021-08-09T14:18:10       1055   341.67      1      0


2021-08-09T14:18:15       1048   314.31      1      0





$ ssar load5s -f 2021-07-15T19:00:00 -r 300 -z

四、記錄執行緒D狀態異常的stack詳情

對於 load5s 值大於 CPU 核數一定倍數的情況，會觸發 load 詳情的採集，其中針對 D 狀態執行緒會抽樣記錄核心呼叫棧。使用 load2p 可以顯示詳細的 D 狀態呼叫棧資訊。

$ ssar load2p -c 2021-09-08T17:25:00 --stackinfo
# 透過呼叫棧資訊，再結合一定的核心程式碼知識，即可以判斷出當時系統問題。
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

五、診斷整機高階記憶體不足情況

系統記憶體不足相關的問題，一直是日常運維中最常見的問題之一。有時候我們會從系統日誌中看到類似這樣的日誌資訊“page allocction failure: order:4”，這是 free 記憶體不足，並且伴隨記憶體碎片化，核心空間申請不到高階記憶體的表現。

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

$ ssar -i 1 -o anonpages,memfree,pgsteal_kswapd,pgsteal_direct
collect_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

可以看到，隨著系統的 anonpages 匿名頁記憶體的增長，memfree 空閒記憶體逐步減少，到達一定閾值後，開始非同步記憶體回收 pgsteal_kswapd，空閒記憶體進一步減少進一步引起直接記憶體回收 pgsteal_direct。

在這樣空閒記憶體嚴重不足的前提下，可能會進一步引發核心高階記憶體不足的情況發生。從資料中可以看到 2021-09-09T10:46:00 時刻的 order4 記憶體庫存為0。

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

六、定位 Cgroup 級別的記憶體顛簸問題

在 cgroup 層面出現記憶體不足時，也有一個記憶體顛簸問題，會引起系統嚴重的問題。

$ tsar2 --io -i 1 -I nvme0n1p1 -s rs,rarqsz,util
Time           nvme0n1p1 nvme0n1p1 nvme0n1p1
Time                  rs    rarqsz      util
09/09/21-14:50     66.1K     10.25    100.00
09/09/21-14:51     71.1K     13.25    100.00
09/09/21-14:52     63.8k     10.00    100.00
09/09/21-14:53     57.0k     14.50    100.00
09/09/21-14:54     64.0k     14.00    100.00

效能優越的 nvme 磁碟，有時候磁碟 util 也會被打

滿到 100%，可以觀察到相應的磁碟讀 IO 高達數萬，同時單次讀 IO 大小隻有 10 多個 Kb 大小。造成這種情況的最常見原因之一是 cgroup 級別的記憶體顛簸。透過核心指標 pgmajfault 可以看到在 IO 打滿的同時每秒整機主缺頁中斷數也非常高，這正是造成系統 IO 打滿的直接原因。



$ 
ssar -i 1 -o pgmajfault


collect_datetime    
pgmajfault/s


2021-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 子命令，可以定位到發生大量主缺頁中斷的正是 pid 為 58532 和 46873 這 2 個 java 程式。引起 java 程式大量發生主缺頁中斷的原因是程式 rss 記憶體極度逼近 cgroup 組設定的memory.limit_in_bytes 值，導致 cgroup 組內留給 clean 狀態的程式碼段記憶體空間不足以完全載入所有程式程式碼段。所以程式碼段在程式執行中，只能不斷的被丟棄再從磁碟讀取。

七、網路 TCP 重傳擴充套件資訊

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


$ tsar2 --retran

Time           --retran--- --retran--- --retran-- --retran-- -retran- ----retran----

Time           RetransSegs FastRetrans LossProbes RTORetrans RTORatio LostRetransmit


08/09/21-16:45       49.44       34.41      16.02       6.41    12.97           0.26


08/09/21-16:50       44.07       29.03      16.84       8.21    18.63           0.13


08/09/21-16:55       37.58       18.72      10.91      11.44    30.44           0.02





$ tsar2 --tcpofo

Time           -tcpofo-- ---tcpofo--- ---tcpofo--- -tcpofo- tcpofo- -tcpofo-

Time           OfoPruned DSACKOfoSent DSACKOfoRecv OFOQueue OFODrop OFOMerge


08/09/21-16:45      0.00         0.00         0.00   251.86    0.00     0.00


08/09/21-16:50      0.00         0.00         0.00   182.35    0.00     0.00


08/09/21-16:55      0.00         0.00         0.00   115.70    0.00     0.00

在 tcp 重傳方面，我們提供了許多相比 tcp 重傳率之外，更為細緻的指標。現代 Linux 系統，早已經有除 200ms 超時重傳之外的多種重傳的方式來加速網路抖動或者異常狀態下的恢復。這裡我們將 TCP 的重傳進行了更細緻的分類，包括快重傳、尾包重傳和超時重傳，不同的重傳對於業務的影響是完全不同的，相當多的時候，我們可能觀察到快重傳或者尾包重傳很高，但超時重傳並不多，這個時候往往並不影響業務。而一旦出現大量的超時重傳，往往意味著真正的網路異常。

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

以上資料再結合 ssar 的歷史資料，找到某些重傳或亂序的異常點，可以幫我們很快定位一些 tcp 問題的原因。


$ tsar2 --tcpdrop

Time           ----tcpdrop----- --tcpdrop-- ----tcpdrop---- ----tcpdrop---- --tcpdrop--

Time           LockDroppedIcmps ListenDrops ListenOverflows PrequeueDropped BacklogDrop


08/09/21-16:45             0.00        0.28            0.28            0.00        0.00


08/09/21-16:50             0.00        1.97            1.97            0.00        0.00


08/09/21-16:55             0.00       21.96           21.96            0.00        0.00





$ tsar2 --tcperr

Time           ---tcperr--- ---tcperr--- ---tcperr--- ---tcperr---- --tcperr---

Time           RenoFailures SackFailures LossFailures AbortOnMemory AbortFailed


08/09/21-16:45         0.00         0.00         0.00          0.00        0.00


08/09/21-16:50         0.00         0.00         0.00          0.00        0.00


08/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() 消費新的連線請求的速度要快，有可能是突發來了較多的建連請求，也可能是服務端長時間沒有呼叫 accept() 來消費 accept 佇列中的半連線請求。

八、自定義採集任意系統指標

做驅動開發的同學很可能希望能記錄自己的驅動模組中一些效能資料，ssar 工具為這種場景提供了簡單和完善的採集方案。只需要驅動開發同學，將核心模組中的效能指標透過/proc/或/sys/下的偽檔案方式暴露為使用者空間即可。資料可以是累積值，也可以是瞬時值，例如 mydev 偽檔案中有 2 個值，左側的indicator1 是累積值，右側的 indicator2 是瞬時值。

$ cat /proc/mydev
104377580      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=myde'
collect_datetime     indicator1/s  indicator2
2021-09-09T17:30:00        884.40        7192
2021-09-09T17:31:00        652.15        7078
2021-09-09T17:32:00        799.73        7676
2021-09-09T17:33:00        708.37        7953
2021-09-09T17:34:00        596.47        7738

命令略微改變下，獲取實時資料。

$ 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  indicator2
2021-09-09T17:40:00        668.50        7004
2021-09-09T17:40:01        480.38        6115
2021-09-09T17:40:02        651.55        6496
2021-09-09T17:40:03        789.15        6433
2021-09-09T17:40:04        867.93        7508

不安裝ssar軟體包，只複製 ssar 程式，也可以直接使用獲取實時資料。

$ ./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'

對於多行或者多列指標含義相近的情況，也可以參考如下 2 個用法。

$ 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-1
7|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和程式級指標採集。節省不必要的磁碟儲存空間開銷。

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

特定 CPU 的 softirq 資源消耗過多，會影響此 CPU 上用於使用者空間的資源使用。因此當中斷分佈不均時，會嚴重影響使用者空間程式的執行。首先需要了解 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    sirq
09/09/21-21:15    1.44    0.01    0.01    0.01    2.28    0.02   15.69    2.72    5.57
09/09/21-21:16    1.98    0.01    0.01    0.01    2.56    0.03   18.40    2.56    8.93
09/09/21-21:17    2.61    0.01    0.01    0.01    2.31    0.09   17.28    2.21    3.59
09/09/21-21:18    1.84    0.01    0.01    0.01    1.97    0.03   12.16    2.04    8.75
09/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, nvme0q10
9/09/21-22:59  765.32 158 5   virtio-output.1     234.97 154 5   nvme0q0, nvme0q1
09/09/21-23:00  763.63 154 5   nvme0q0, nvme0q1    393.88 158 5   virtio-output.1
09/09/21-23:01  531.87 158 5   virtio-output.1     225.03 154 5   nvme0q0,nvme0q1
09/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 -H
2021-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 -P
2021-09-10T12:10:00       1.31       2.58  81747740     281676

ssar 工具程式碼庫地址：

—— 完 ——

關於龍蜥社群SIG

加入龍蜥社群

加入微信群：新增社群助理-龍蜥社群小龍（微信：openanolis_assis），備註【龍蜥】拉你入群；加入釘釘群：掃描下方釘釘群二維碼。歡迎開發者/使用者加入龍蜥社群（OpenAnolis）交流，共同推進龍蜥社群的發展，一起打造一個活躍的、健康的開源作業系統生態！

系統效能監控工具ssar例項精選 | 龍蜥SIG

前言