文/張毅：系統運維核心成員、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、互動的應用環境

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

總結

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

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

—— 完 ——