簡介：本文從大量的性能診斷實踐出發，來介紹 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、交互的應用環境

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

總結

最后的最后，以一張大圖來進行總結。

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

原文鏈接

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

總結

以上是生活随笔為你收集整理的龙蜥利器：系统运维工具 SysAK的云上应用性能诊断 | 龙蜥技术的全部內容，希望文章能夠幫你解決所遇到的問題。

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