1. 首頁 > 科技 > >

CPU|龍蜥利器：系統運維工具 SysAK的云上應用性能診斷

cpu

CPU|龍蜥利器：系統運維工具 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 ， 或者單次單次運行過過長 ， 那么都都可能會影響到業務的性能 ， 可以對中斷進行打散綁定等操作觀察效果 。

相關經驗推薦