龍蜥利器:系統運維工具 SysAK的雲上應用性能診斷 | 龍蜥技術

簡介:本文從大量的性能診斷實踐出發,來介紹 SysAK 在性能診斷上的方法論及相關工具。

文/張毅:系統運維SIG核心成員、SysAK 項目負責人;毛文安:系統運維 SIG 負責人。

系統運維既要業務穩定的運行,又要最大化的利用資源,因此對於應用性能的評估也是重要的一環,作爲系統運維的利器,SysAK 自然少不了這方面的能力。但對於應用性能的診斷,有時比穩定性問題更難,非專業人員甚至有無從下手的感覺。本文從大量的性能診斷實踐出發,來介紹 SysAK 在性能診斷上的方法論及相關工具。

SysAK 應用性能診斷方法

簡而言之,SysAK 診斷應用性能的基本思路就是自頂向下並進行關聯拓展。

自上向下即應用->OS->硬件,關聯拓展則包括同級應用、系統影響、以及網絡拓撲。說起來簡單,但實施起來卻是一個大工程。

1、應用畫像

首先做的就是應用畫像,要對應用的性能進行診斷,首先要對其進行畫像,包括其業務吞吐、系統資源使用等,然後再根據畫像中佔比比較大的性能瓶頸進行逐一專項分析。具體來說,包括應用的併發數、運行和睡眠的統計。 併發數簡單,統計業務任務數就行了,這個主要是爲後面的資源使用作爲參考。

1.1、運行統計

即對系統基礎資源的利用進行分類統計,應用運行時基礎資源佔用就4類:

Cpu

通過 cpu 佔用可知應用本身的吞吐是否高,並進一步通過 user/sys 的 cpu 佔比可得知業務運行時更多的是在業務自身還是在內核資源的使用上。所以此處至少要包含運行時長、以及 user、sys 的各自比例。如果 sys 佔比高,需要繼續分析對應內核資源是否有異常情況,否則更多時候需要分析硬件資源上是否有瓶頸。

內存

通過內存的使用情況來判斷內存的申請與訪問是否是制約業務性能的因素。所以此處至少要包含內存分配總量、頻率、缺頁次數、跨 NUMA 節點訪問次數和大小等的統計。

文件

通過文件訪問的情況來判斷文件 IO 是否是制約業務性能的因素。此處至少要包含文件讀寫頻率、pagecache 命中率、平均 IO 時延等的統計。

網絡

通過報文流量來判斷網絡是否是制約業務性能的因素,此處至少要包含流量統計、對端鏈接的網絡拓撲等。

1.2、睡眠統計

如果應用運行週期內,睡眠時間佔比很大,則很可能是影響業務性能的關鍵因素,此時就要分析睡眠的詳細情況了。至少要包含三類行爲的數據統計,包括具體行爲的次數和時長:

主動睡眠:這類數據如果佔比過高,則說明是應用自身行爲。 用戶臨界資源競爭:這些數據如果佔比過高,則需要優化應用。 內核資源等待:這類數據如果佔比過高,則需要分析具體的系統內核資源瓶頸。 在有了應用畫像以後,我們就對應用運行過程中的基本情況有了瞭解,如果發現瓶頸不在業務自身,那麼就需要繼續往下分析對應的系統資源或者硬件瓶頸了。

2、系統內核資源

系統內核資源制約應用性能的地方又可分爲三大類:

2.1、干擾

一個服務器操作系統運行過程中,對應用運行的干擾源可能會很多,但干擾不一定會對業務造成影響,所以至少需要包含這些干擾源的頻率和運行時間,來評估是否是關鍵因素。

至少需要包括以下干擾源的統計:

設備硬件中斷

如果在業務運行過程中,某一類中斷頻率過高或者集中到某個 cpu,或者單次單次運行過過長,那麼都都可能會影響到業務的性能,可以對中斷進行打散綁定等操作觀察效果。

系統定時中斷

系統定時器過多,也可能會對業務的喚醒造成延遲,通常可以分析業務進程是否有大量的使用高精度定時器。

軟中斷

可能是網絡流量是否有突發增加等。

內核線程

其他高優先級應用

2.2、瓶頸

系統內核資源種類繁多,應用模型不同,對內核資源的依賴也不同,所有瓶頸點無法完全覆蓋,但至少需要包含幾大類常見的內核資源的統計數據:

運行隊列長度

這個可以表明是否業務進程/線程併發過多,或者是否綁核不合理等

fs/block 層時延

對於不同的文件系統或設備、IO 調度算法,可能會有不同的瓶頸點,通常需要進行分段統計時延來確定

內存分配延時

受內存水位、碎片的影響,內存分配的時延有時可能會很大

pagefault 時長與頻率

內存缺頁導致的內存請求、重映射、tlb flush 等對的開銷是非常大的,如果頻繁的進入到 pagefault 流程中,可以考慮從應用策略上進行優化,比如預分配內存池、使用大頁等。

關鍵路徑 kernel 鎖的競爭

鎖是不可避免的機制,kernel 態鎖競爭通常會導致 sys 態的 cpu 升高,需要結合上下文進行具體分析。

2.3、策略

上述提到內核資源無法完全覆蓋,但可以有另外一種方法去能觀測一些數據,因爲不同的內核策略可能有比較大的性能差異,所以可以嘗試通過不同系統間的對比,找出配置的差異點。通常的系統配置採集如下:

內核啓動參數

內核配置接口 sysctl/procfs/sysfs

內核模塊差異

cgroup配置

3、虛擬化

當上述找不到瓶頸點時,或者我們想繼續挖掘性能的剩餘價值,通常就會到硬件這一側,而目前業務部署在雲上居多,所以在深入硬件層前,虛擬化層或者說主機側也是繞不開的必要因素。對主機側的性能分析,針對系統內核資源制約可以複用上述的方法,但對業務畫像可以少做不少事,相對於應用業務,虛擬化這層的邏輯不會無限變化,我們可以從各個渠道瞭解到雲廠商提供的虛擬化方案,目前主流的是 Linux kvm 方案。因此可以針對性的對 kvm 這個方案所所及到的技術點做特別分析。此處應該包含的統計包括:

qemu 線程的被搶佔頻率及時間、guest陷出頻率及事件、qemu線程在host上運行的時間

通過這些來綜合判斷是否是由於虛擬化層帶來的性能損失或者是否有改善的可能性。

4、硬件性能

最後,真正到了硬件層,到這裏通常都是由於單純從應用層或者系統層無法找到更多的優化空間了。其實又有兩種思路,一種是看看硬件利用率的點,看能否反向調整應用,對硬件使用的熱點減少依賴或者分散利用;另一種就是應用無法調整了,評估硬件的性能是否真正已到瓶頸。對於前者,又可以延伸出一套方法論來,比如 Ahmed Yasin 的TMAM,在 sysAK 中不做過多延伸,但仍然有必要的工作要做,除 cache、tlb miss、cpi 這些數據採集外,更關鍵的是怎麼將這些數據結合應用進程的運行情況進行分析,比如同一 cpu 上的 cache 或帶寬競爭多,是由於當前業務自身的程序設計,還是有其他進程存在爭搶導致,對於爭搶導致的可以通過綁核、rdt 等技術進行配合優化。

5、交互的應用環境

還沒完,這裏還少了一個拼圖,現在絕大多數應用都不是單機的,交互的應用之間也會產生性能影響,因此在應用畫像中,我們曾提到過網絡連接的拓撲,就是用於此。我們可以將上述所有的性能診斷方法在和當前應用進行交互的對象上覆制一遍。

總結

最後的最後,以一張大圖來進行總結。

而圖中涉及的工具將會在後續的實戰篇中出現,敬請期待。

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章