簡介：?你還在為分析機器負載高而苦惱？這款 ssar 工具獨創 load5s 指標精準定位超硬核。??

編者按：本文整理自龍蜥SIG技術周會，作者聞茂泉，阿里云計算平臺事業部SRE運維專家，是龍蜥社區跟蹤診斷SIG核心成員。本文帶你了解 ssar 的基本功能和使用、初步學習用 ssar 解決單機 OS 問題的診斷。直播視頻回放已上線至龍蜥社區官網：首頁-支持-視頻，歡迎觀看。

一、系統性能分析工具 ssar 功能定位??

說起性能分析就不得不提到《性能之巔》這本書，它是業界里程碑式的經典書籍。在書中第 4 章觀測工具部分，Brendan 告訴我們觀測工具主要包括：計數器(Counters)、跟蹤(Tracing)、采樣(Profiling)和監控(Monitoring)幾大類。

依據數據獲取方式和數據實時性兩個維度，可以將性能觀測工具做個分類：

1）左上角 A 區是直接讀取計數器實時數據的一些系統命令，top、ps 這些命令我們都很常用，它們讀取的是 /proc/ 這個目錄的信息，這里面的數據是內核幫我們記賬出來的。

2）左下角 B 區也是基于計數器的 ，但它是記錄歷史信息的工具，比如說最常用的就是sar工具，下文我們統稱這類工具為系統性能監控工具。在阿里內部也有 tsar 工具，國外還有開源軟件 atop。系統性能監控工具一方面可以回溯歷史數據，同時也提供實時模式數據。

3）右上角 C 區跟蹤采樣工具，內核的 tracepoint、kprobe 等就是跟蹤類工具，perf 工具主要是采樣類工具，下文我們統稱這兩類工具為跟蹤采樣工具。目前這些工具都是只獲取實時的數據。如果不結合其他工具，單純使用它們來追查歷史數據，它們是無法提供的。

4）右下角 D 區，我們認為可以通過 B 區和 C 區的工具協同使用達到目標。C 區工具只負責獲取內核關鍵數據，B 區工具只負責數據采集和數據獲取，二者之間使用標準數據接口。

我們在性能分析工程實踐中重點聚焦在左下 B 區和右上 C 區藍框 2 個象限的建設上。今天我們主要探討的就是 B 區的系統性能監控工具建設情況。以后會再給大家介紹 C 區的工具建設情況。

在對系統性能監控和跟蹤采樣工具的具體理解上，我們認同如下 3 個理念：

1）內核計數器(Counters)信息獲取代價低，無額外開銷。相比較而言，跟蹤采樣工具或多或少都有一些運行開銷，如 kprobe 的使用還可能會引起一些穩定性風險。因此，我們傾向于最大化挖掘計數器信息的價值。比如要獲知機器直接內存回收的信息時，內核計數器已經提供了更低代價獲取的直接內存回收和異步內存回收的指標，就完全沒必要使用 ftrace 監控直接內存回收的情況了。另一方面，對于內核計數器不能涵蓋的細顆粒度內核數據，還必須要依賴內核跟蹤采樣工具獲取。比如當 IOPS 較高時，我們想了解具體的每一個 IO 讀寫的具體文件信息，內核計數器中完全沒有相關信息。只有讓跟蹤采樣工具專注于自己的核心任務，才更有條件打磨出更加穩定和可靠的精品工具。

2）現有的系統性能監控工具，除單機監控工具外，還有很多白屏化的監控平臺。白屏化監控平臺一般都是將數據采集到中心數據庫，然后再集中展示。白平化監控平臺采集更詳細的計數器信息時，不可避免的都會遇到存儲成本的問題，不宜將過多數據采集到白屏化監控平臺。但同時對于一些高頻使用的常規指標，如 CPU、內存和網絡使用率情況，使用白屏化監控平臺展示，確實可以大大提升可觀測性。所以高頻常規指標使用白屏化監控平臺的同時，仍然需要一個數據指標更加豐富的單機系統性能監控工具配合使用。在一些關鍵時刻，還必須依賴這些低頻數據來分析和定位問題。

3）傳統的黑屏系統性能監控工具，多年來一直相對比較固化，歷數 2010 年、2015 年、2020 年指標內容變化不是特別大。舉個例子，新版本內核的計數器中，網絡擴展指標多達 400 多個，僅 TCP 擴展指標就有 116 個，但是實際上常規的系統性能監控在TCP網絡指標這一塊，也就使用了不超過 15 個指標，大部分指標價值并沒有被挖掘出來。這些網絡的內核計數器指標，在很多網絡相關問題發生時，都很有實用價值。

基于這些理念，我們認為研發一款數據指標更全、迭代周期更短、性能更加穩定的系統性能監控工具，以應對日益復雜的系統性能問題是很必要的。

今天我們要介紹的阿里自研 ssar 工具，就是這樣一款系統性能監控類工具，并且已經在知名的操作系統社區龍蜥開源。它幾乎涵蓋了傳統系統性能監控 sar 工具的所有功能，同時擴展了更多的整機級別的指標，新增了進程級指標和特色的 load 指標、load 高問題的診斷是這個工具一個獨特的功能。

開源軟件 atop 也是這樣一個類似功能的系統性能監控工具。公開渠道了解到友商也在大規模部署 atop 工具，這說明在業界其他互聯網公司也感受到了擁有這樣一個功能定位的監控工具的重要性。

二、系統性能分析工具 ssar 簡介

系統性能監控工具 ssar 開源地址（見文末），其中 Reference_zh-CN.md 是更詳細的中文幫助手冊，package 目錄中有 rpm 和 deb 包提供，其他操作系統可以自行編譯打包。

ssar工具分為采集器、內層的通用查詢器、外層的增強查詢器和經典查詢器幾部分。

1）采集器 sresar：C 語言實現的一個常駐進程，將數據記錄到本地磁盤，采集數據內容包括：(a) 按文件單位采集的整機數據、meminfo、stat、vmstat等； (b) 包含 24 個指標的進程級數據；(c) 獨特的 load5s 指標和詳細的 R 或 D 狀態線程詳情數據；

2）通用查詢器 ssar 命令：c++ 語言實現，負責按文件名、某行、某列等通用規則對文件數據進行邏輯解析；

3）古典查詢器tsar2：python 語言實現，對 ssar 命令進行封裝，全面兼容 tsar 命令；

4）增強查詢器ssar+：python 語言實現，對 ssar 命令進行封裝，規劃上是未來 ssar 工具的主要核心，適合于把較復雜的數據邏輯放在 python 語言實現層。

三、系統性能分析工具 ssar 支持快速開發迭代

傳統 sar 工具只采集一些固定指標，使用 C 語言采集數據的同時進行指標解析。在這種模式下，不是極難擴展新指標，就是擴展新指標開發迭代周期特別長。

ssar工具完全顛覆了傳統 sar工具的架構設計，在產品設計和程序架構上做了很多變化，可以讓我們快速、低開發成本的增加新的計數器指標。

1）如果我們需要關注一個新的指標，而這個指標又沒有被采集。對于傳統的系統性能監控工具sar來說，修改發布迭代周期是非常長的，發布下來可能要數周到數月，中間要經過逐步的灰度發布過程。在學習內核知識或者解決生產問題的時候，新問題等不起這么久。但 ssar 工具以文件為采集單位，不需要修改代碼，直接修改配置文件，重啟 srerar 采集進程就可以采集到一個新的數據源文件。新增采集文件可在 sys.conf 文件中的 file 區域增加一行配置項，其中 sre_path 為數據源位置，cfile 為數據文件存儲名，turn 為開啟采集。

2）ssar 工具把一些通用處理邏輯都抽象到通用查詢器 ssar 命令里，配置了文件采集后，只需一條 ssar 命令即可查詢顯示數據，完美實現分鐘級周期的開發迭代。其中cfile指定存儲文件名，line 指定第 3 行，column 指定第 5 到 15 行，metric 指定顯示原值，alias指定指標名稱。

3）ssar 會把更加復雜的數據邏輯放到外層 python 語言的查詢器中實現。這個時候很容易通過在 python 語言中適應數據格式的變化。內核中有些指標的格式會隨著內核版本的變化而變化,比如 TCP 的 TimeWaitOverflow 指標在 3.10、4.9 和 4.19 版中所處的列數就不同。此時通過 python 語言可以輕松獲取 column 值，再傳遞給ssar通用查詢器。即使面對未來的內核版本中的各種未知格式變化，我們也可以在python語言查詢器中輕松應對自如。可隨時調試和升級python查詢器，如 cp tsar2 ?/tmp/test.py。不論是單機環境 debug，還是腳本批量下發，均可輕量級操作。

四、ssar 工具整機指標使用介紹

ssar 命令顯示整機指標信息，其中 /s 結尾的是增量指標，表示當前時刻和上一個時刻的區間內平均每秒的增量數值。無 /s 結尾的是刻度指標，只表示當前時刻的瞬時值。

使用 help 選項可獲取整機指標使用幫助信息。

各個選項參數的含義如上所示，選項參數有如下一些特點：

1）-f 選項指定顯示數據的結束時間點，-b 選項指定顯示數據的開始時間點，-r 選項指定顯示數據的時間區間長度，三個選項只需指定 2 個即可。-f 選項默認值為當前時刻，-r 選項默認值為 300 分鐘。

2）各個選項參數值大多可以支持輸入小數，單位分別支持天、時、分、秒，如1.2d、5.5h、60m 和 1s。如無單位后綴，則默認單位后綴是m分鐘，如 60 同 60m。

3）-H選項用于隱藏header信息，使輸出結果更便于各種 shell 命令的解析，--api輸出json格式數據，使輸出結果更便于python腳本等高級語言解析。

4）小o選項用于指定輸出數據列的字段信息，多列指標用逗號隔開。對于高頻常用的多個字段輸出，還提供字段組合選項，如--cpu、--mem。大O選項用于在既有字段組合輸出基礎上，追加輸出指標信息。因此，大O選項可與--cpu ?--mem等同時使用，而小o選項和大O選項及其他字段組合互斥。

ssar 對整機指標的采集是以文件為單位，通過 toml 格式的配置文件 /etc/ssar/sys.conf 配置及開關文件的采集：

1）src_path='/proc/stat' 表示采集數據源文件位置為/proc/stat；

2）cfile='stat'表示保存的數據文件后綴名為 stat；

3）turn 選項控制當前采集是否開啟，設置為 true 開啟采集；

4）gzip 選項控制采集文件是否采用 gzip 壓縮格式存儲，設置為 true 開啟壓縮；

ssar 支持兩種數據提取方式，預定義方式和自定義方式。

ssar 預定義指標提取數據方式適合于使用 ssar 命令直接消費數據的場景。預定義指標可在 sys.conf 文件中靈活的配置，下面 2 個例子說明了如何配置預定義指標：

1）配置項 user 表示指標名為 user，數據文件后綴為 stat，取開頭為 cpu 的行的第 2 列數據的差值，輸出字段寬度 10 個字節。

2）配置項insegs表示指標名為 insegs，數據文件后綴為 snmp，取第 8 行的第 11 列數據的差值，輸出字段寬度 10 個字節。

配置了預定義指標后，可以進一步配置 view 視圖，聚合預定義指標到一個視圖下。這就是 ssar --cpu 的命令里 --cpu 的來源。

ssar 也支持自定義指標方式提取數據指標，自定義指標提取數據方式適合于使用python語言封裝的查詢器使用。如下是一些自定義指標方式的使用示例：

1）取 meminfo 中 MemFree 值，字段名命名為 freessar -o 'metric=c|cfile=meminfo|line_begin=MemFree:|column=2|alias=free'

2）取 snmp 中第 8 行第 13 列值的差值ssar -o 'metric=d:cfile=snmp:line=8:column=13:alias=retranssegs'

3）顯示 cpu0 到 cpu15 的 idle 的實時模式數據

ssar -o 'metric=d|cfile=stat|line=2-17|column=5|alias=idle_{line};' -f +100

自定義方式使用方法說明：

1）cfile 用來指定數據文件中的后綴名，需要同 sys.conf 配置文件中的 [file] 部分的 cfile 的值保持一致；

2）line 直接指定指標所在的行數，line 與 line_begin 不能同時指定；

3）line_begin 指定指標所在行的行首匹配關鍵字符串，需要保證在整個文件中獨一無二；

4）column 指定指標在特定行所處的列數，列以空格為分隔符；

5）metric 用于指定按以上規則獲取到值后是原值輸出，還是取相鄰時間的差值輸出，值為c表示原值輸出，為d表示取差值輸出；

6）alias 用于指定當前指標輸出的標題名或 json 格式中的 key 值.

tsar工具是阿里集團的一款經典系統性能監控工具。基于ssar命令的整機自定義指標方式，使用python語言封裝的 tsar2 命令幾乎完全兼容tsar命令。

各個模塊的指標集合：

tsar2 命令不但功能十分強大，而且開發成本極低：

1）tsar2開發周期只有不到2周時間；

2）tsar2命令兼容 tsar 功能部分的python代碼實現只有600多行；

3）tsar2在兼容原有基礎功能的基礎上還新增了4組網絡診斷指標，不考慮前期預研的時間，4組指標的代碼實現時間只用了2個小時。4組網絡診斷指標：tsar2 ?--tcpofo、tsar2 ?--retran、tsar2 ?--tcpdrop、tsar2 ?--tcperr。

基于 ssar 良好的擴展性和低擴展開發門檻，針對軟中斷分布不均這種業界常見問題，使用 python 語言實現了 3 組功能強大的診斷功能：

1）首先，tsar2 的 cputop 子命令可以將各個核軟中斷 CPU 使用率(sirq)最高的核排序出來。N1 表示排序最高的 CPU 信息，N2 表示排序次高的 CPU 信息。比如 11:35 這個時刻下 N1 的三個值表示 54 號核 CPU 的 sirq 軟中斷使用率為第 54 號核 CPU 資源的 21.84%。從圖中顯示的部分數據看 54 號核頻繁出現軟中斷 sirq 使用較高的情況。

2）如果我們不確定找到 54 號核 CPU 是否準確，還可以通過 tsar2 命令的 cpu 視圖中指定觀察 cpu54 核的 sirq 的變化。

3）一旦確定軟中斷 CPU 使用率異常的 CPU 核號，可以通過 tsar2 的 irqtop 子命令查找引起問題的具體軟中斷信息。在 irqtop 子命令中指定 54 號 CPU，并排序出軟中斷次數最多的 irq 號是 155，對應的 irq 名稱是 virtio3-input.1，并且看到 11:50:48 秒的軟中斷次數高達 1.9K。

irqtop子命令默認只支持實時模式。如需開啟歷史模式可去掉命令中-l選項，同時還需要修改配置文件 sys.conf，開啟 interrupts 數據文件的采集。

如此強大的cputop和irqtop子命令同樣也是在python語言中，通過400行代碼輕松實現。這里也同樣表明了在ssar架構下，開發新的系統性能監控功能的靈活優勢。

五、ssar工具進程指標使用介紹

ssar 的 procs 子命令可以顯示多進程信息，效果相當于可以顯示任意歷史時刻的 linux ps 命令的輸出。

ssar 的 procs 子命令選項可參考ssar procs -h命令，選項參數有如下一些特點：

1）-f、-b和-r選項同樣只需指定2個選項即可，-f選項默認值為當前時刻，-r選項默認值為5分鐘。多進程子命令情況下，只會在開始和結束時刻分別取 2 個時刻數據進行對比。瞬時的刻度類指標只顯示結束時刻值。

2）強大的字段排序功能支持多字段依次排序，先按第一個字段排序，相同值按第二個字段排序。排序字段前減號表示降序排序，排序字段前加號表示升序排序。每個字段都有系統內建排序規則，通常數據類指標按降序排序，如rss，屬性指標按升序排序，如 pid。

3）所有進程排序后，-l選項可限制輸出進程的行數。

4）兩個特色的指標組合 --job 和 --sched，用于進程組和調度問題排查。

ssar 的 proc 子命令顯示單進程縱向歷史時刻信息。

1）-p選項為必選參數，用于指定需要顯示的進程的 pid 信息。

2）-f選項指定結束時間點，-b選項指定開始時間點，-r選項指定時間跨度，三個選項只需指定2個即可。-f默認值為當前時刻，-r默認值為 300 分鐘。

3）-H選項隱藏header信息更便于shell腳本解析，--api選項輸出json格式數據更便于python腳本等高級語言解析。

4）小 o 選項用于指定輸出數據列的字段，多列指標用逗號隔開。對于高頻常用的多字段同時輸出，還提供字段組合選項，如 --cpu、--mem。大 O 選項用于在既有字段組合輸出基礎上，追加輸出字段指標。因此，大 O 選項可與 --cpu ?--mem 等同時使用，而小 o 選項和大 O 選項及其他字段組合互斥。

5）左尖括號 < 表示7點02分sleep.sh進程還沒啟動，右尖括號 > 表示7點22分進程已結束。此功能可以協助判斷一個特定進程的開始和結束時間范圍。

下面通過一個簡單的例子，來說明下如何通過 ssar 進程級指標診斷線程數打滿問題。Linux 內核有個參數 kernel.pid_max = 131072，這個參數會設置機器的總線程數上限。

1）一臺機器在非工作時段發生了異常進程創建大量線程將線程數打爆的情況。凌晨3點整，整機線程數飆升到了131.1K，且持續時間極短，3點1分已經恢復。

2）傳統條件下，這種場景的發生根本來不及等待人工登錄上去抓取現場信息。如今有了ssar工具對歷史信息的自動采集，我們可以等到工作時間，使用ssar的多進程子命令輕松獲取進程級原因。NLWP(Number of light weight process)表示一個進程的線程數，使用-k選項數按 nlwp 字段排序可以發現是 pid 為 1045 的 Java 進程引起線程數打滿。

3）不放心的同學，還可以使用 awk 將這個問題時刻2021-03-30T03:00:00的所有線程數相加，和為 131024，印證了確實等同于當時機器總線程數plit值131.1K。

六、ssar工具load指標使用介紹

傳統的系統性能監控工具中的 load1 指標盡管比 load5 和 load15 指標更精準，仍然不能滿足排查問題時對時間范圍的精準度的要求。ssar 在國內外全行業獨創了 load5s 指標，該指標可以讓我們將 load 的準確性提升到 5 秒級的精度。load5s 指標的準確性絕不僅體現在采集頻率上，簡單說 load5s 指標就是 R+D 的線程數，也是內核數據結構中的全局變量 active 值。為了準確理解 linux load 和 load5s 指標，執行如下實驗操作：

找一臺實驗機器，先編譯一個可以模擬 D 狀態線程的程序 uninterruptible。然后用 stress 命令啟動 100 個進程執行 30 秒后退出。大約再等 20 秒左右再批量循環啟動 1000 個 uninterruptible 進程。執行結束后，效果如下圖所示。

1）綠色時間區域，5 分 52 秒時 load5s 和 load1 都處于一個低水位，毫無疑問說明當時機器負載壓力很低。

2）第一個紅色時間區域，伴隨著stress命令開始執行，load5s 和 load1 都同時升高，6分07秒時刻，load5s 值已經達到78，load1 開始升高到 6.27，但是這個 load1 的值遠遠不能體現出當前機器上并發運行的線程的狀況。隨著時間的推移，6分32秒這個時刻，load1的值緩慢升到了39.22。

3）第一個藍色時間區域，伴隨著stress命令進程退出，load5s已經迅速跌回到一個低水位，6分37秒這個時刻的 load5s 值也同時迅速降低到了很低的值0，機器的R+D狀態線程已經幾乎沒有了，系統完全沒有任何壓力。但此時load1還保持在36.08的高值。明顯可以看出傳統的 load1 指標在系統負載壓力消失后，還一定的滯后性。

在后面2個紅色區域和2個藍色區域，也可以觀察到同樣的現象。共同的規律是紅色區域開始時刻，代表R+D狀態線程數的load5s值明顯很高，但相同時刻的load1卻還較低。藍色區域開始時刻，代表R+D狀態線程數的load5s值已經為0，但相同時刻load1卻還較高。

上面這個實驗充分說明 load5s 才是更能準確反映系統負載壓力的指標，而單純用 load1 值判斷機器的負載是不準確的。所以我們需要用 load5s 指標替代 load1 指標來精準判斷機器負載發生的時間范圍。這里強調一下，load5s指標完全在用戶態通過工程化的方法巧妙獲取，沒有對內核模塊的任何依賴。

除 load5s 指標外，上面的解決方案中，還提供了一組指標用于全面的評估系統負載情況。其中 load5s 是 R+D 狀態的線程數之和，runq是當時的R狀態線程數，threads是所有狀態線程數總和，因此 threads 值是 load5s 值的天花板，threads 最大值受內核參數設置限制。

ssar 工具還會根據 load5s 和 CPU 核數之比的大小，來觸發對 load 詳情的采集，前邊的 actr 是采集到的并發R狀態線程數，actd 是采集到的并發 D 狀態線程數，act 是 actr 和 actd 數之和。當我們需要了解load構成的詳細因素時，可以借助load2p子命令進一步顯示actr和actd的詳情信息。

未觸發 load 詳情采集的采集時刻，act 值不存在，顯示為短橫線-。可以用-z選項過濾出 load5s 子命令輸出結果中act存在值的時刻，即 ssar load5s -z。

然后再用 load2p 子命令顯示更加詳細的load詳情信息，選項-c 指定需要顯示的load詳情的時刻值。load2p子命令一共可輸出6個視圖的信息，loadrd、stack、loadr、loadd、psr和stackinfo。

1）loadrd視圖顯示指定時刻所有R和D狀態的線程信息，每個線程包括線程狀態、線程ID、進程ID、CPU核號、線程調度優先級和命令名稱。ssar 只采集 R 和 D 狀態的線程信息。

2）stack視圖顯示抽樣后的D狀態調用棧，最多抽樣100個。每個D狀態線程調用棧包含線程ID、進程ID、進程名稱、棧頂函數位置、棧頂函數名和完整的調用棧。

3）基于以上2個視圖的信息，load2p子命令又聚合了4個視圖信息，并且默認只顯示這4個聚合視圖 loadr、loadd、psr 和stackinfo。Loadr 視圖按 pid 聚合 R 狀態線程信息，適合診斷 loadR 高時的進程級因素。

4）loadd視圖按pid聚合D狀態線程信息，適合診斷loadD高時的進程級因素。

5）psr視圖按CPU核號psr聚合，適合診斷綁核不均的情況。

6）stackinfo視圖按調用棧聚合，對loadD高時，診斷D狀態線程發生的原因特別有用。

七、ssar工具配置文件說明

ssar工具的主配置文件是/etc/ssar/ssar.conf，其中分為[main]、[load]和[proc]三部分。

1）[main]部分配置選項主要用于設置ssar工具整體的一些選項內容，[load]和[proc]分別對應load信息采集和進程信息采集部分的選項，整機信息的配置選項在前文介紹的/etc/ssar/sys.conf文件中獨立設置。

2）duration_threshold選項設置最多保留168小時。inode_use_threshold、 disk_use_threshold和disk_available_threshold這3個選項任意一個條件不滿足時，則停止數據采集，并且開始從時間最老的數據到最新的逐步刪除數據，以試圖使剛才不成立的條件成立，一直刪除到只剩最新的一個小時數據目錄為止。ssar工具的這種磁盤空間處理邏輯可以說不占用額外的磁盤空間。

3） load5s_flag、 proc_flag和sys_flag分別控制采集器三部分數據的采集，嵌入式系統中可以同時關閉load5s_flag和proc_flag后再配置sys.conf，從而做到只采集自己關注的數據源。

4） scatter_second選項用于在大規模集群中，使各個主機的采集時間分散化。

5） load5s_threshold設置load詳情采集觸發閾值，不同角色的服務器此閾值需要根據各自特點個性化設置。

八、ssar工具CPU使用率綜合分析

Linux top命令中有2處%Cpu，一處是在頭部，另外是在每個進程信息中。關于兩者之間的關系，我們借助ssar工具的使用簡單介紹一下。

為了準確理解linux CPU Usage指標，在一臺4核機器上執行如下實驗。A終端執行命令 ? stress -t 120 -c 3，執行時間為23時23分20秒，120秒后會結束。B終端同時執行top命令，如圖所示。

理解 CPU Usage 指標：

1）在A終端上，等待stress執行結束2分鐘后，執行tsar2命令。23時25分的user值為75.60，它的含義表示23時24分到23時25分這60秒內的平均user CPU使用為75.60%。這里看出tsar2的user值等同于top命令的us值75.2，區別就是tsar2的是60秒平均值，top的是運行時刻的之前3秒的平均值，但因為三個stress命令運行平穩，top的3秒平均值也基本代表60秒的均值。

2）在A終端上繼續執行ssar命令，23時25分的user/s值為301.35。ssar的cpu值是取自/proc/stat，單位是內核tick數。x86_64系統每秒100個tick，即100HZ。4顆CPU總數就是每秒400個tick， 23:25時間的user值是301.35，它的含義表示23時24分到23時25分這60秒內的平均每秒user CPU使用量為301.35 tick數。

3）我們可以查看tsar2的python源碼，能夠了解到tsar2的user值是ssar的user值占ssar所有CPU使用量之和的百分比。

4）在A終端上繼續執行ssar procs子命令。23時25分的三個stress進程的pucpu值都為100.0。這里的每一個100.0的含義是這個進程在23時24分到23時25分這60秒內的進程的平均用戶空間CPU使用率為100.0。計算過程是用進程的cpu時間片除以自然時長，再乘以100，即百分比的100。這個算法和top命令下半部分的進程級別的%CPU一致。

5）這里我們可以看到這樣的數據關系301.25 ≈ 100 + 100 + 100 + 3.3，只不過整機user CPU值301.35是自然時間乘以了100HZ，進程級CPU是乘以了百分比的100。使用ssar --cpu和ssar procs --cpu兩個命令，已經可以將整機總體的CPU使用情況和進程級別CPU使用情況的關聯起來。

6）最后top命令中的us值和進程信息中的%CPU的關系也就自然建立起來了。一點不同就是top中是將整體CPU使用情況進一步計算了一次百分占比。

九、ssar工具內存回收案例

在 load 高的各種場景中，有一種R狀態線程數并發多的load高是由于sys CPU使用率偏高引起的。ssar 全面的指標體系，從多個角度將這種場景發生過程進行了透徹的呈現。為了準確的說明問題，有必要回顧下內核內存回收的相關概念。如圖所示，當整機free內存低于黃線low閾值時，內核的異步內存回收線程kswapd開始被喚醒，kswapd會在其他進程申請內存的同時回收內存。當整機free內存觸達紅線min閾值時，觸發整機直接內存回收，所有來自用戶空間的內存申請將被阻塞住，線程狀態同時轉換為D狀態。此時只有來自內核空間的內存申請可以繼續使用min值以下的free內存。后續當整機free內存逐步恢復到綠線high閾值以上后，kswapd線程停止內存回收工作。

下面以ssar的數據指標為依據，一步一步的展示了當整機內存緊張后是如何引起sys CPU高，并進而引發load高的完整過程：

1）用戶空間java進程在20點43分到20點45分2分鐘內大量申請24GB內存；

2）整機內存used在20點43分到20點45分2分鐘內迅速增長了26GB，同時整機free內存迅速減少了14GB；

3）free內存在20點45分時只有3GB，低于low閾值，pgscan_kswapd/s值非0表明觸發kswapd異步內存回收。

4）kswapd異步內存回收跟不上進程內存申請的速度，當free內存低至min閾值時，pgscan_direct/s值非0表明觸發直接內存回收，用戶空間內存申請進程開始D住。棧頂函數sleep_one_page和congestion_wait等都表明發生了直接內存回收。

5）20點44分到20點45分出現大量網絡吞吐，每秒進出流量分別達到1.5G和1.0G。網絡流量吞吐會伴有內核空間內存申請，繼續消耗min閾值以下(橙色部分)free內存。

6）內核網絡模塊會申請order3階內存，20點45分時刻buddyinfo中order3以上高階內存消耗殆盡，剩余的3GB free內存處于碎片化狀態。內核空間申請的內存是連續內存，雖然order2和order1有庫存，但申請order3時是無法被分配的，內核只能處于忙等狀態。

7）觸發內核態忙等，同時會引發20點44分到20點45分的sys CPU升高，sys CPU平均每秒占總CPU資源的89.61%，擠占用戶空間既有進程CPU資源，同期用戶態CPU使用從原來的72.59%降低到7.73%。

8）觸發直接內存回收時，會引發大量D狀態線程，后續order3庫存枯竭引發sys CPU高后，會繼續引發大量R狀態線程。load5s子命令看到的現象就是先出現load5s指標升高，再出現load5s和runq同時升高。

內存回收是生產環境較常見的一個情況。除以上場景外，生產中還會發生其他場景的內存回收,數據指標的表現上也有差異。還需要借助其他性能分析工具，結合內核代碼進一步分析。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的直播回顾：准确性提升到 5 秒级，ssar 独创的 load5s 指标有多硬核？| 龙蜥技术的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。