闻茂泉：系统性能监控与分析的工程化实践之路
點擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”
后臺回復(fù)"書"，獲取
后臺回復(fù)“k8s”，可領(lǐng)取k8s資料
一、系統(tǒng)性能分析工具ssar功能定位
說起性能分析就不得不提到《性能之巔》這本書，它是業(yè)界里程碑式的經(jīng)典書籍。在書中第4章觀測工具部分，Brendan告訴我們觀測工具主要包括：計數(shù)器(Counters)、跟蹤(Tracing)、采樣(Profiling)和監(jiān)控(Monitoring)幾大類。
依據(jù)數(shù)據(jù)獲取方式和數(shù)據(jù)實時性，將性能觀測工具做了分類：
1）左上角A區(qū)是直接讀取計數(shù)器實時數(shù)據(jù)的一些系統(tǒng)命令，top、ps這些命令我們都很常用，它們讀取的是/proc/這個目錄的信息，這里面的數(shù)據(jù)是內(nèi)核幫我們記賬出來的。
2）左下角B區(qū)也是基于計數(shù)器的?，但它是記錄歷史信息的工具，比如說最常用的就是sar工具，下文我們統(tǒng)稱這類工具為系統(tǒng)性能監(jiān)控工具。在阿里內(nèi)部也有tsar工具，國外還有開源軟件atop。系統(tǒng)性能監(jiān)控工具一方面可以回朔歷史數(shù)據(jù)，同時也提供實時模式數(shù)據(jù)。
3）右上角C區(qū)跟蹤采樣工具，內(nèi)核的tracepoint，kprobe等就是跟蹤類工具，perf工具主要是采樣類工具，下文我們統(tǒng)稱這兩類工具為跟蹤采樣工具。目前這些工具都是只獲取實時的數(shù)據(jù)。如果不結(jié)合其他工具，單純使用它們來追查歷史數(shù)據(jù)，它們是無法提供的。
4）右下角D區(qū)，我們認(rèn)為可以通過B區(qū)和C區(qū)的工具協(xié)同使用達(dá)到目標(biāo)。
我們在性能分析工程實踐中重點聚焦在左下B區(qū)和右上C區(qū)藍(lán)框2個象限的建設(shè)上。今天我們主要探討的就是B區(qū)的系統(tǒng)性能監(jiān)控工具建設(shè)情況。以后再給大家介紹C區(qū)的工具建設(shè)情況。
系統(tǒng)性能監(jiān)控工具和跟蹤采樣工具各有優(yōu)勢和特點，我們認(rèn)為應(yīng)該挖據(jù)各自潛力、發(fā)揮各自優(yōu)勢，讓他們都最大限度在系統(tǒng)性能分析工作中發(fā)揮恰當(dāng)?shù)淖饔?#xff0c;切不可偏頗于任何一方。
在對系統(tǒng)性能監(jiān)控和跟蹤采樣工具的具體理解上，我們認(rèn)同如下3個理念：
1）內(nèi)核計數(shù)器(Counters)信息獲取代價低，無額外開銷。相比較而言，跟蹤采樣工具或多或少都有一些運行開銷，如kprobe的使用還可能會引起一些穩(wěn)定性風(fēng)險。因此，我們傾向于最大化挖掘計數(shù)器信息的價值，給跟蹤采樣工具減負(fù)。比如要獲知機(jī)器直接內(nèi)存回收的信息時，內(nèi)核計數(shù)器已經(jīng)提供了更低代價獲取的直接內(nèi)存回收和異步內(nèi)存回收的指標(biāo)，就完全沒必要使用ftrace監(jiān)控直接內(nèi)存回收的情況了。另一方面，對于內(nèi)核計數(shù)器不能涵蓋的細(xì)顆粒度內(nèi)核數(shù)據(jù)，還必須要依賴內(nèi)核跟蹤采樣工具獲取。比如當(dāng)IOPS較高時，我們想了解具體的每一個IO讀寫的具體文件信息，內(nèi)核計數(shù)器中完全沒有相關(guān)信息。只有讓跟蹤采樣工具專注于自己的核心任務(wù)，才更有條件打磨出更加穩(wěn)定和可靠的產(chǎn)品級工具方案。畢竟只專注于2件事，比同時干10件事更容易干的出色。
2）現(xiàn)有的系統(tǒng)性能監(jiān)控工具，除單機(jī)監(jiān)控工具外，還有很多白屏化的監(jiān)控平臺。白屏化監(jiān)控平臺一般都是將數(shù)據(jù)采集到中心數(shù)據(jù)庫，然后再集中展示。白平化監(jiān)控平臺采集更詳細(xì)的計數(shù)器信息時，總會遇到存儲成本的壓力的問題，因此不宜將過多計數(shù)器指標(biāo)采集到白屏化監(jiān)控平臺。但同時對于一些高頻使用的常規(guī)指標(biāo)，如CPU、內(nèi)存和網(wǎng)絡(luò)使用率情況，使用白屏化監(jiān)控平臺展示，確實可以大大提升可觀測性。所以高頻常規(guī)指標(biāo)使用白屏化監(jiān)控平臺的同時，仍然需要依賴一個數(shù)據(jù)更加豐富的黑屏系統(tǒng)性能監(jiān)控工具作為補(bǔ)充，以應(yīng)對一些關(guān)鍵時刻必須依賴的低頻計數(shù)器數(shù)據(jù)。
3）傳統(tǒng)的黑屏系統(tǒng)性能監(jiān)控工具，多年來一直相對比較固化，歷數(shù)2010年、2015年、2020年指標(biāo)內(nèi)容變化不是特別大。舉個例子，新版本內(nèi)核的計數(shù)器中，網(wǎng)絡(luò)擴(kuò)展指標(biāo)多達(dá)400多個，僅TCP擴(kuò)展指標(biāo)就有116個，但是實際上常規(guī)的系統(tǒng)性能監(jiān)控在TCP網(wǎng)絡(luò)指標(biāo)這一塊，也就使用了不超過15個指標(biāo)，大部分指標(biāo)價值并沒有被挖掘出來。這些網(wǎng)絡(luò)的內(nèi)核計數(shù)器指標(biāo)，在很多網(wǎng)絡(luò)相關(guān)問題發(fā)生時，都特別有使用價值。
基于這些理念，我們認(rèn)為研發(fā)一款數(shù)據(jù)指標(biāo)更全、迭代周期更短、性能更加穩(wěn)定的系統(tǒng)性能監(jiān)控工具，以應(yīng)對日益復(fù)雜系統(tǒng)性能問題是很必要的。
今天我們要介紹的阿里自研ssar工具，就是這樣一款系統(tǒng)性能監(jiān)控類工具，并且已經(jīng)在知名的操作系統(tǒng)社區(qū)龍蜥開源。它幾乎涵蓋了傳統(tǒng)系統(tǒng)性能監(jiān)控sar工具的所有功能，同時擴(kuò)展了更多的整機(jī)級別的指標(biāo)，新增了進(jìn)程級指標(biāo)和特色的load指標(biāo)，load高問題的診斷是這個工具一個獨特的功能。
開源軟件atop也是這樣一個類似功能的系統(tǒng)性能監(jiān)控工具。公開渠道了解到友商也在大規(guī)模部署atop工具，這說明在業(yè)界其他互聯(lián)網(wǎng)公司也感受到了擁有這樣一個功能定位的監(jiān)控工具的重要性。
下文我會用幾個例子說明我們是如何結(jié)合使用系統(tǒng)性能監(jiān)控工具和跟蹤采樣工具的。
二、系統(tǒng)性能分析工具ssar介紹
系統(tǒng)性能監(jiān)控工具ssar開源地址：
https://gitee.com/anolis/tracing-ssar.git
其中Reference_zh-CN.md是詳細(xì)的中文幫助手冊，package目錄中有rpm和deb包提供，其他操作系統(tǒng)可以自行編譯打包。
ssar工具分為采集器、內(nèi)層的通用查詢器、外層的增強(qiáng)查詢器和經(jīng)典查詢器幾部分。
1）采集器sresar：C語言實現(xiàn)的一個常駐進(jìn)程，將數(shù)據(jù)記錄到本地磁盤，采集數(shù)據(jù)內(nèi)容包括：
???(a) 按文件單位采集的整機(jī)數(shù)據(jù)，meminfo、stat、vmstat等；
???(b) 包含24個指標(biāo)的進(jìn)程級數(shù)據(jù)；
???(c) 獨特的load5s指標(biāo)和詳細(xì)的R或D狀態(tài)線程詳情數(shù)據(jù)；
2）通用查詢器ssar命令：c++語言實現(xiàn)，負(fù)責(zé)按文件名、某行、某列等通用規(guī)則對文件數(shù)據(jù)進(jìn)行邏輯解析。
3）古典查詢器tsar2：python語言實現(xiàn)，對ssar命令進(jìn)行封裝，全面兼容tsar命令；
4）增強(qiáng)查詢器ssar+：python語言實現(xiàn)，對ssar命令進(jìn)行封裝，規(guī)劃上是未來ssar工具的主要核心，適合于把較復(fù)雜的數(shù)據(jù)邏輯放在python語言實現(xiàn)層。
2.1、系統(tǒng)性能分析工具ssar支持快速迭代
傳統(tǒng)sar工具只采集一些固定指標(biāo)。在使用C語言采集的同時進(jìn)行指標(biāo)解析的模式下，不是極難擴(kuò)展新指標(biāo)，就是擴(kuò)展新指標(biāo)迭代周期特別長。
ssar工具完全顛覆了傳統(tǒng)sar工具的架構(gòu)設(shè)計，在產(chǎn)品設(shè)計和程序架構(gòu)上做了很多變化，可以讓我們快速、低成本的增加新的計數(shù)器指標(biāo)。
1）如果我們關(guān)注一個新的指標(biāo)，但是又沒有被采集。對于修改傳統(tǒng)的系統(tǒng)性能監(jiān)控工具sar來說，修改發(fā)布迭代周期是非常長的，發(fā)布下來可能要數(shù)周到數(shù)月。在學(xué)習(xí)內(nèi)核知識或者解決生產(chǎn)問題的時候，新問題等不起這么久。但ssar工具以文件為采集單位，不需要修改代碼，直接改一下配置文件，重啟srerar采集進(jìn)程就可以采集一個新的數(shù)據(jù)源文件。新增采集文件可在sys.conf文件中的file區(qū)域增加一行配置項，其中sre_path為數(shù)據(jù)源位置，cfile為數(shù)據(jù)文件存儲名，turn為開啟采集。
2）ssar把一些通用處理邏輯都抽象到ssar命令通用查詢器里，配置文件采集后，只需一條ssar命令查詢顯示數(shù)據(jù)，完美實現(xiàn)分鐘級周期的迭代。其中cfile指定存儲文件名，line指定第3行，column指定第5到15行，metric指定顯示原值，alias指定指標(biāo)名稱。
3）更加復(fù)雜的邏輯，ssar把它轉(zhuǎn)移到外層python語言的查詢器中實現(xiàn)。這個時候你很容易通過在python中的修改來適應(yīng)數(shù)據(jù)解析的變化。內(nèi)核中有些指標(biāo)伴隨著內(nèi)核版本的變化格式也在變化,比如TCP的TimeWaitOverflow指標(biāo)在3.10、4.9和4.19版中所處的列數(shù)就不同。此時可以python語言中輕松獲取column值，傳遞給ssar通用查詢器。即使面對未來內(nèi)核版本中的未知變化，我們也可以通過python查詢器應(yīng)付自如?？呻S時調(diào)試和升級python查詢器，如cp tsar2 ?/tmp/test.py,不論是單機(jī)環(huán)境debug，還是腳本批量下發(fā)，均可輕量級操作。
2.2、系統(tǒng)性能分析工具ssar不占用額外存儲空間
相比較傳統(tǒng)系統(tǒng)性能監(jiān)控工具，ssar的特點是能記錄更加豐富的計數(shù)器 (Counters) 指標(biāo)信息，但這也會占用更多的磁盤存儲空間。ssar工具默認(rèn)記錄7天歷史數(shù)據(jù)，通常占用磁盤空間不超過1GB。近20年來，隨著存儲技術(shù)的發(fā)展，單位空間的磁盤存儲成本價格下降到千分之一。適當(dāng)提高系統(tǒng)性能監(jiān)控工具的采集數(shù)據(jù)量是有一定可行性的。
為了追求更加完美的磁盤空間穩(wěn)定性，ssar仍然設(shè)計了更加積極的磁盤存儲空間策略。還設(shè)置了專門的參數(shù)，當(dāng)磁盤空間使用率達(dá)到閾值(默認(rèn)90%)后，會停止數(shù)據(jù)采集。不但如此，當(dāng)由于其他進(jìn)程原因使磁盤空間數(shù)據(jù)繼續(xù)增長并超過90%時，ssar會啟動對7天內(nèi)較早歷史數(shù)據(jù)的刪除工作，直到磁盤空間使用率小于90%或?qū)sar歷史數(shù)據(jù)基本刪除。
用圖示表示，圖中藍(lán)色的部分就是A、B、C、D中各臺機(jī)器的原來磁盤空間使用情況，有多些的，有少些的。
傳統(tǒng)的系統(tǒng)性能監(jiān)控工具會占用每臺機(jī)器固定的磁盤存儲空間，相當(dāng)于不區(qū)分各個機(jī)器的磁盤空間使用現(xiàn)狀，每臺機(jī)器都增加圖中紅色部分的磁盤空間占用。當(dāng)系統(tǒng)性能監(jiān)控工具采集數(shù)據(jù)量較大后，必須重新規(guī)劃磁盤分區(qū)的存儲空間。
ssar系統(tǒng)性能監(jiān)控工具，使用的是圖中這個綠色區(qū)域的存儲空間。無需重新規(guī)劃磁盤分區(qū)的存儲空間。
實際生產(chǎn)中磁盤空間的規(guī)劃，一般都會保留一定的free空間作為buffer，應(yīng)對突發(fā)情況。傳統(tǒng)系統(tǒng)性能監(jiān)控工具所在磁盤分區(qū)必須相應(yīng)的規(guī)劃一個額外的磁盤空間，而ssar工具的這種磁盤空間處理邏輯不用規(guī)劃額外的磁盤空間。唯一的缺點就是磁盤打滿同時又需要消費ssar數(shù)據(jù)的場景，但這個場景概率極低。
三、ssar工具診斷l(xiāng)inux?load和背后索歷程
傳統(tǒng)的系統(tǒng)性能監(jiān)控工具中的load1指標(biāo)盡管比load5和load15指標(biāo)更精準(zhǔn)，仍然不能滿足排查問題時的時間維度的精準(zhǔn)度要求。ssar在國內(nèi)外全行業(yè)獨創(chuàng)了load5s指標(biāo)，該指標(biāo)可以讓我們將load的準(zhǔn)確性提升到5秒級的精度。load5s指標(biāo)的準(zhǔn)確性絕不僅體現(xiàn)在采集頻率上，簡單說load5s指標(biāo)就是R+D的線程數(shù)，也是內(nèi)核數(shù)據(jù)結(jié)構(gòu)中的全局變量active值。
下面通過一個實驗來帶大家理解load5s指標(biāo)。我們找一臺實驗機(jī)器，我們在終端窗口A查看load，沒有任何負(fù)載壓力load1非常低。我們現(xiàn)在再開一個終端窗口B，運行一個模擬負(fù)載壓力的命令，命令內(nèi)容是“stress -t 40 -c 1000”，其中stress命令需要自己安裝。stress 命令主要用來模擬系統(tǒng)負(fù)載較高時的場景，這里并發(fā)啟動1000個消耗CPU資源的單線程進(jìn)程，就是1000個線程,并且控制只運行40秒后就停止。我們測試的stress命令是15分10秒執(zhí)行的，經(jīng)過40秒就是15分50秒結(jié)束。stress命令執(zhí)行結(jié)束后，我們再回到終端A使用ssar load5s命令查看運行效果。
依次分析實驗的結(jié)果：
1）綠色時間區(qū)域15分09秒時，load5s和load1都還處于一個低水位，毫無疑問說明當(dāng)時機(jī)器負(fù)載壓力很低。
2）伴隨著15分10秒stress命令開始執(zhí)行后，紅色時間區(qū)域load5s和load1都同時升高, 15分14秒采集時刻，load5s值已經(jīng)達(dá)到1003，load1開始升高到80.4，但是這個load1的值遠(yuǎn)遠(yuǎn)不能體現(xiàn)出當(dāng)前機(jī)器上并發(fā)運行1000個負(fù)載壓力的線程的狀況。隨著時間的推移，15分46秒這個時刻，load1的值緩慢升到了489.16。
3）15分50秒1000個stress并發(fā)進(jìn)程退出，在藍(lán)色時間區(qū)域15分52秒這個時刻的load5s值也同時迅速降低到了很低的值0。但是我們看到15分52秒這個時刻的load1值，依然有449.99這么高，這里的load1值看上去是及其令人迷惑的。
上面這個實驗說明load5s才是更準(zhǔn)確反映系統(tǒng)負(fù)載壓力的指標(biāo)，而單純用load1值判斷機(jī)器的負(fù)載是不準(zhǔn)確的。所以我們需要用load5s指標(biāo)替代load1指標(biāo)來精準(zhǔn)判斷機(jī)器負(fù)載發(fā)生的時間范圍。除load5s指標(biāo)外，上面的解決方案中，還提供了一組指標(biāo)用于全面的評估系統(tǒng)負(fù)載情況。其中l(wèi)oad5s是R+D狀態(tài)的線程數(shù)之和，runq是當(dāng)時的R狀態(tài)線程數(shù)，threads是所有狀態(tài)線程數(shù)總和，因此threads值是load5s值的天花板，threads最大值受內(nèi)核參數(shù)設(shè)置限制。
ssar工具還會根據(jù)load5s和CPU核數(shù)之比，來觸發(fā)對load詳情的采集，前邊的actr是采集到并發(fā)的R狀態(tài)線程數(shù)，actd是采集到并發(fā)的D狀態(tài)線程數(shù)，act是actr和actd數(shù)之和。當(dāng)我們需要了解load構(gòu)成的詳細(xì)因素時，可以借助load2p子命令進(jìn)一步顯示actr和actd的詳情數(shù)據(jù)。
雖然load5s指標(biāo)體系能如此精準(zhǔn)的反應(yīng)系統(tǒng)的負(fù)載壓力情況，但我們并沒有依賴kprobe、ebpf等任何跟蹤采樣技術(shù)。load5s指標(biāo)完全在用戶態(tài)通過工程化的方法巧妙獲取，充分體現(xiàn)了我們“最大化挖掘計數(shù)器歷史信息價值”的理念。
如此神奇的load5s指標(biāo)，在最初的發(fā)現(xiàn)和理解過程，還曾經(jīng)深入借助了跟蹤采樣工具的支持，下面按時間線來回顧下這個歷程。
1）首先結(jié)合systemtap工具的使用，同時閱讀內(nèi)核load部分的內(nèi)核代碼，了解到linux load的計算邏輯是在calc_global_load函數(shù)中獲取一個active全局變量（active包含R和D兩種狀態(tài)的線程數(shù)量），然后按照每隔5秒鐘的頻率采樣，最后由近及遠(yuǎn)按不同權(quán)重計算出load值。歸納起來的公式就是：
load1(n)??=func1(load1(n-1), active(n))
load1(n-1) ?=func1(load1(n-2), active(n-1))
當(dāng)前的這個load1值，是拿5秒鐘前的上一個load1跟當(dāng)前時刻這個active值做一個計算得出來的。那上一個時刻load1值就是上上一個時刻load1值和上一個時刻active值計算出來的，所以這是一個無限遞歸的過程。
2）遺憾的是內(nèi)核并沒有暴露active變量值，但我們可以借助一個kprobe內(nèi)核模塊hook內(nèi)核變量并通過proc接口暴露給用戶空間。可參考本人較早文章《深度好文：全面解析 Linux Load 》，其中有如下代碼:
git clone https://github.com/os-health/load5s.git
通過暴露的內(nèi)核變量值，運行l(wèi)oad預(yù)測腳本，按照內(nèi)核里面load的計算方法，在用戶空間重算一遍load值，結(jié)果如圖。
看到內(nèi)核吐出的current_load值25.07和我們shell腳本預(yù)測的predict_load值25.07完全一樣，說明在load_predict.sh腳本中計算邏輯就是內(nèi)核對load值的計算邏輯。這個預(yù)測值25.07是根據(jù)上一個load1值24.38和load5s值的33（load5s就是active值）計算而來。
3）由此，我們完全可以反其道而行。既然是這個25.07是通過這24.38和33這兩個值算出來的，我們完全可以監(jiān)控這個load1的值的變化，然后每5秒鐘去把這個active值反算出來就可以了。
active(n)???= func2(load1(n)?,?load1(n-1))
通過在用戶空間反算active值，使其在工程上具有極大的通用性和可靠性，我們將active值命名為load5s。
四、ssar工具診斷sys CPU高和背后探索歷程
在load高的各種場景中，有一種R狀態(tài)線程數(shù)并發(fā)多的load高是由于sys CPU使用率偏高引起的。ssar全面的指標(biāo)體系，從多個角度將這種場景發(fā)生過程進(jìn)行了透徹的呈現(xiàn)。
為了準(zhǔn)確的說明問題，有必要回顧下內(nèi)核內(nèi)存回收的相關(guān)概念。如圖所示，當(dāng)整機(jī)free內(nèi)存低于黃線low閾值時，內(nèi)核異步內(nèi)存回收線程kswapd開始被喚醒，kswapd會在其他進(jìn)程申請內(nèi)存的同時回收內(nèi)存。當(dāng)整機(jī)free內(nèi)存到達(dá)紅線min閾值時，觸發(fā)整機(jī)直接內(nèi)存回收，所有來自用戶空間的內(nèi)存申請將被阻塞住，線程狀態(tài)同時轉(zhuǎn)換為D狀態(tài)。此時只有來自內(nèi)核空間的內(nèi)存申請可以繼續(xù)使用min值以下的free內(nèi)存。后續(xù)當(dāng)整機(jī)free內(nèi)存逐步恢復(fù)到綠線high閾值以上后，kswapd線程停止內(nèi)存回收工作。
下面以ssar的數(shù)據(jù)指標(biāo)為依據(jù)，一步一步的展示了當(dāng)整機(jī)內(nèi)存緊張后是如何引起sys CPU高，并進(jìn)而引發(fā)load高的完整過程：
1）用戶空間java進(jìn)程在20點43分到20點45分2分鐘內(nèi)大量申請24GB內(nèi)存；
2）整機(jī)內(nèi)存used在20點43分到20點45分2分鐘內(nèi)迅速增長了26GB，同時整機(jī)free內(nèi)存迅速減少了14GB；
3）free內(nèi)存在20點45分時只有3GB，低于low閾值，pgscan_kswapd/s值非0表明觸發(fā)kswapd異步內(nèi)存回收。
4）kswapd異步內(nèi)存回收跟不上進(jìn)程內(nèi)存申請的速度，當(dāng)free內(nèi)存達(dá)到min閾值時，pgscan_direct/s值非0表明觸發(fā)直接內(nèi)存回收，用戶空間內(nèi)存申請進(jìn)程D住。棧頂函數(shù)sleep_one_page和congestion_wait等都是典型的直接內(nèi)存回收時的特征。
5）20點44分到20點45分出現(xiàn)大量網(wǎng)絡(luò)吞吐，每秒進(jìn)出流量分別達(dá)到1.5G和1.0G。網(wǎng)絡(luò)流量吞吐會伴有內(nèi)核空間內(nèi)存申請，繼續(xù)消耗min閾值以下(橙色部分)free內(nèi)存。
6）內(nèi)核網(wǎng)絡(luò)模塊會申請order3階內(nèi)存，20點45分時刻buddyinfo中order3以上高階內(nèi)存消耗殆盡，剩余的3GB free內(nèi)存處于碎片化狀態(tài)。內(nèi)核空間申請的內(nèi)存是連續(xù)內(nèi)存，雖然order2和order1有庫存，但申請order3時是無法被分配的，內(nèi)核只能處于忙等狀態(tài)。
7）觸發(fā)內(nèi)核態(tài)忙等，同時會引發(fā)20點44分到20點45分的sys CPU升高，sys CPU平均每秒占總CPU資源的89.61%，擠占用戶空間既有進(jìn)程CPU資源，同期用戶態(tài)CPU使用從原來的72.59%降低到7.73%。
8）觸發(fā)直接內(nèi)存回收時，會引發(fā)大量D狀態(tài)線程，后續(xù)order3庫存枯竭引發(fā)sys CPU高后，會繼續(xù)引發(fā)大量R狀態(tài)線程。load5s子命令看到的現(xiàn)象就是先出現(xiàn)load5s指標(biāo)升高，再出現(xiàn)load5s和runq同時升高。
以上各指標(biāo)立體的展現(xiàn)了整機(jī)內(nèi)存不足時，如何引發(fā)load高的機(jī)制。有人也許會好奇，一開始是如何將這些指標(biāo)關(guān)聯(lián)到一起的。高階內(nèi)存不足引起sys CPU異常的場景，在問題調(diào)查早期也的確是通過采樣(Profiling)工具火焰圖獲取的直接線索。在火焰圖熱點函數(shù)棧中有__alloc_skb這樣函數(shù)，再結(jié)合內(nèi)核代碼，之后才想到補(bǔ)充buddyinfo內(nèi)核計數(shù)器指標(biāo)觀察order0到order10的情況。
補(bǔ)充buddyinfo計數(shù)器指標(biāo)后，再遇到sys CPU高問題，通過以上指標(biāo)體系就直接可以判斷了，不用再次使用采樣工具(perf)。
終于有一天，sys CPU又打高了，但是并沒有同時出現(xiàn)內(nèi)存相關(guān)指標(biāo)的異常，只發(fā)現(xiàn)占用sys CPU的是大量內(nèi)核線程kworker。
這時還需要繼續(xù)借助采樣(Profiling)工具獲取火焰圖分析。
根據(jù)火焰圖中熱點函數(shù)ext4_mb_regular_allocator/ext4_mb_good_group，再結(jié)合sys CPU占用率高的進(jìn)程是kworker，結(jié)合內(nèi)核代碼可以看到這是文件系統(tǒng)方面的函數(shù)，在分配空閑塊。自然就會去想到查看磁盤空間指標(biāo)，發(fā)現(xiàn)確實出現(xiàn)了100%的情況發(fā)生。
這是本文第二個例子體現(xiàn)了“最大化挖掘計數(shù)器歷史信息價值，發(fā)揮計數(shù)器指標(biāo)和跟蹤采樣工具各自的優(yōu)勢”的理念。
五、ssar工具診斷IOPS打滿和背后探索歷程
本文舉的第三個例子，是關(guān)于nvme協(xié)議的SSD盤的。這種盤IO性能很高，有時候會遇到讀的IOPS高達(dá)上萬的情況，磁盤IO Util打到100%，而且單IO size特別小只有4KB。
阿里有一個自研的IO跟蹤工具，可以抓到每一個IO讀寫了那個文件。最初出現(xiàn)這種IO打滿情況時，我們使用阿里自研的IO跟蹤工具抓取了每一個IOPS的詳情，發(fā)現(xiàn)讀取的文件都是二進(jìn)制的so包，而且分析扇區(qū)地址Sector信息時發(fā)現(xiàn)同一個扇區(qū)地址平均最多每秒被重復(fù)讀取了178次，這是非常不符合常規(guī)的。正常情況下，我們的程序是一次性從磁盤加載到內(nèi)存空間，不會重復(fù)加載，但是這里一秒鐘重復(fù)加載178次，說明一秒內(nèi)又被丟棄了177次。問題調(diào)查到這里，我們自然想去查看內(nèi)存方面的問題。
經(jīng)分析最終確認(rèn)是cgroup的內(nèi)存設(shè)置問題，該進(jìn)程的memory.limit_in_bytes設(shè)置為4GB，當(dāng)前進(jìn)程的rss內(nèi)存使用已經(jīng)到了3.9GB，剩余的100MB空間不足以完全加載800MB的clean 狀態(tài)的二進(jìn)制可執(zhí)行代碼部分。先加載第一個100MB的代碼段，當(dāng)開始執(zhí)行第二個100MB的代碼段時，必須釋放一些第一個100MB的代碼段。如此就會出現(xiàn)反復(fù)加載同一個扇區(qū)地址代碼段的情況。
了解了這種場景的原理，會發(fā)現(xiàn)出現(xiàn)這種場景時整機(jī)和進(jìn)程級別的主缺頁中斷數(shù)會大量增加。當(dāng)再次出現(xiàn)磁盤讀IO異常高時，我們可以不依賴IO跟蹤工具，直接查看整機(jī)主缺頁中斷數(shù)，判斷是否又發(fā)生了內(nèi)存顛簸。
當(dāng)確定時發(fā)生內(nèi)存顛簸時，再進(jìn)一步通過ssar進(jìn)程級指標(biāo)確定大量發(fā)生主缺頁中斷的進(jìn)程。通過pid查看進(jìn)程cgroup中memory.limit_in_bytes 值的設(shè)置，并對比進(jìn)程當(dāng)前的rss值也可以診斷這類問題。并且這類問題不論發(fā)生在任何時間，都可以通過ssar指標(biāo)輕松診斷。
前面在linux load、sys CPU和IOPS的性能分析過程中，分享了3個案例。這3個案例都貫穿了一個性能分析的思路，最大化挖掘計數(shù)器歷史信息的價值，解放跟蹤采樣工具。使用跟蹤采樣工具探索發(fā)現(xiàn)問題的內(nèi)在邏輯后，再將相關(guān)計數(shù)器指標(biāo)固化到ssar系統(tǒng)性能監(jiān)控工具中。
想知道更多？掃描下面的二維碼關(guān)注我后臺回復(fù)"技術(shù)"，加入技術(shù)群 后臺回復(fù)“k8s”，可領(lǐng)取k8s資料【精彩推薦】ClickHouse到底是什么？為什么如此牛逼！
原來ElasticSearch還可以這么理解
面試官：InnoDB中一棵B+樹可以存放多少行數(shù)據(jù)？
架構(gòu)之道：分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)
星巴克不使用兩階段提交
面試官：Redis新版本開始引入多線程，談?wù)勀愕目捶?#xff1f;
喜馬拉雅自研網(wǎng)關(guān)架構(gòu)演進(jìn)過程
收藏：存儲知識全面總結(jié)
微博千萬級規(guī)模高性能高并發(fā)的網(wǎng)絡(luò)架構(gòu)設(shè)計
總結(jié)
以上是生活随笔為你收集整理的闻茂泉：系统性能监控与分析的工程化实践之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 怎样的代码算是好代码？
- 下一篇： 系统、应用监控的缜密思路，堪称性能瓶颈的