1. 首頁 > 科技 > >

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

cpu


系統定時中斷
系統定時器過多 ， 也可能會對業務的喚醒造成延遲 ， 通?？梢苑治鰳I務進程是否有大量的使用高精度定時器 。
軟中斷
可能是網絡流量是否有突發增加等 。
內核線程
其他高優先級應用
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、交互的應用環境
還沒完 ， 這里還少了一個拼圖 ， 現在絕大多數應用都不是單機的 ， 交互的應用之間也會產生性能影響 ， 因此在應用畫像中 ， 我們曾提到過網絡連接的拓撲 ， 就是用于此 。 我們可以將上述所有的性能診斷方法在和當前應用進行交互的對象上復制一遍 。

相關經驗推薦