簡(jiǎn)介：本文從大量的性能診斷實(shí)踐出發(fā)，來(lái)介紹 SysAK 在性能診斷上的方法論及相關(guān)工具。

文/張毅：系統(tǒng)運(yùn)維SIG核心成員、SysAK 項(xiàng)目負(fù)責(zé)人；毛文安：系統(tǒng)運(yùn)維 SIG 負(fù)責(zé)人。

系統(tǒng)運(yùn)維既要業(yè)務(wù)穩(wěn)定的運(yùn)行，又要最大化的利用資源，因此對(duì)于應(yīng)用性能的評(píng)估也是重要的一環(huán)，作為系統(tǒng)運(yùn)維的利器，SysAK 自然少不了這方面的能力。但對(duì)于應(yīng)用性能的診斷，有時(shí)比穩(wěn)定性問(wèn)題更難，非專(zhuān)業(yè)人員甚至有無(wú)從下手的感覺(jué)。本文從大量的性能診斷實(shí)踐出發(fā)，來(lái)介紹 SysAK 在性能診斷上的方法論及相關(guān)工具。

SysAK 應(yīng)用性能診斷方法

簡(jiǎn)而言之，SysAK 診斷應(yīng)用性能的基本思路就是自頂向下并進(jìn)行關(guān)聯(lián)拓展。

自上向下即應(yīng)用->OS->硬件，關(guān)聯(lián)拓展則包括同級(jí)應(yīng)用、系統(tǒng)影響、以及網(wǎng)絡(luò)拓?fù)洹Ｕf(shuō)起來(lái)簡(jiǎn)單，但實(shí)施起來(lái)卻是一個(gè)大工程。

1、應(yīng)用畫(huà)像

首先做的就是應(yīng)用畫(huà)像，要對(duì)應(yīng)用的性能進(jìn)行診斷，首先要對(duì)其進(jìn)行畫(huà)像，包括其業(yè)務(wù)吞吐、系統(tǒng)資源使用等，然后再根據(jù)畫(huà)像中占比比較大的性能瓶頸進(jìn)行逐一專(zhuān)項(xiàng)分析。具體來(lái)說(shuō)，包括應(yīng)用的并發(fā)數(shù)、運(yùn)行和睡眠的統(tǒng)計(jì)。 并發(fā)數(shù)簡(jiǎn)單，統(tǒng)計(jì)業(yè)務(wù)任務(wù)數(shù)就行了，這個(gè)主要是為后面的資源使用作為參考。

1.1、運(yùn)行統(tǒng)計(jì)

即對(duì)系統(tǒng)基礎(chǔ)資源的利用進(jìn)行分類(lèi)統(tǒng)計(jì)，應(yīng)用運(yùn)行時(shí)基礎(chǔ)資源占用就4類(lèi)：

Cpu

通過(guò) cpu 占用可知應(yīng)用本身的吞吐是否高，并進(jìn)一步通過(guò) user/sys 的 cpu 占比可得知業(yè)務(wù)運(yùn)行時(shí)更多的是在業(yè)務(wù)自身還是在內(nèi)核資源的使用上。所以此處至少要包含運(yùn)行時(shí)長(zhǎng)、以及 user、sys 的各自比例。如果 sys 占比高，需要繼續(xù)分析對(duì)應(yīng)內(nèi)核資源是否有異常情況，否則更多時(shí)候需要分析硬件資源上是否有瓶頸。

內(nèi)存

通過(guò)內(nèi)存的使用情況來(lái)判斷內(nèi)存的申請(qǐng)與訪(fǎng)問(wèn)是否是制約業(yè)務(wù)性能的因素。所以此處至少要包含內(nèi)存分配總量、頻率、缺頁(yè)次數(shù)、跨 NUMA 節(jié)點(diǎn)訪(fǎng)問(wèn)次數(shù)和大小等的統(tǒng)計(jì)。

文件

通過(guò)文件訪(fǎng)問(wèn)的情況來(lái)判斷文件 IO 是否是制約業(yè)務(wù)性能的因素。此處至少要包含文件讀寫(xiě)頻率、pagecache 命中率、平均 IO 時(shí)延等的統(tǒng)計(jì)。

網(wǎng)絡(luò)

通過(guò)報(bào)文流量來(lái)判斷網(wǎng)絡(luò)是否是制約業(yè)務(wù)性能的因素，此處至少要包含流量統(tǒng)計(jì)、對(duì)端鏈接的網(wǎng)絡(luò)拓?fù)涞取?/p>

1.2、睡眠統(tǒng)計(jì)

如果應(yīng)用運(yùn)行周期內(nèi)，睡眠時(shí)間占比很大，則很可能是影響業(yè)務(wù)性能的關(guān)鍵因素，此時(shí)就要分析睡眠的詳細(xì)情況了。至少要包含三類(lèi)行為的數(shù)據(jù)統(tǒng)計(jì)，包括具體行為的次數(shù)和時(shí)長(zhǎng)：

主動(dòng)睡眠：這類(lèi)數(shù)據(jù)如果占比過(guò)高，則說(shuō)明是應(yīng)用自身行為。 用戶(hù)臨界資源競(jìng)爭(zhēng)：這些數(shù)據(jù)如果占比過(guò)高，則需要優(yōu)化應(yīng)用。 內(nèi)核資源等待：這類(lèi)數(shù)據(jù)如果占比過(guò)高，則需要分析具體的系統(tǒng)內(nèi)核資源瓶頸。 在有了應(yīng)用畫(huà)像以后，我們就對(duì)應(yīng)用運(yùn)行過(guò)程中的基本情況有了了解，如果發(fā)現(xiàn)瓶頸不在業(yè)務(wù)自身，那么就需要繼續(xù)往下分析對(duì)應(yīng)的系統(tǒng)資源或者硬件瓶頸了。

2、系統(tǒng)內(nèi)核資源

系統(tǒng)內(nèi)核資源制約應(yīng)用性能的地方又可分為三大類(lèi)：

2.1、干擾

一個(gè)服務(wù)器操作系統(tǒng)運(yùn)行過(guò)程中，對(duì)應(yīng)用運(yùn)行的干擾源可能會(huì)很多，但干擾不一定會(huì)對(duì)業(yè)務(wù)造成影響，所以至少需要包含這些干擾源的頻率和運(yùn)行時(shí)間，來(lái)評(píng)估是否是關(guān)鍵因素。

至少需要包括以下干擾源的統(tǒng)計(jì)：

設(shè)備硬件中斷

如果在業(yè)務(wù)運(yùn)行過(guò)程中，某一類(lèi)中斷頻率過(guò)高或者集中到某個(gè) cpu，或者單次單次運(yùn)行過(guò)過(guò)長(zhǎng)，那么都都可能會(huì)影響到業(yè)務(wù)的性能，可以對(duì)中斷進(jìn)行打散綁定等操作觀察效果。

系統(tǒng)定時(shí)中斷

系統(tǒng)定時(shí)器過(guò)多，也可能會(huì)對(duì)業(yè)務(wù)的喚醒造成延遲，通常可以分析業(yè)務(wù)進(jìn)程是否有大量的使用高精度定時(shí)器。

軟中斷

可能是網(wǎng)絡(luò)流量是否有突發(fā)增加等。

內(nèi)核線(xiàn)程

其他高優(yōu)先級(jí)應(yīng)用

2.2、瓶頸

系統(tǒng)內(nèi)核資源種類(lèi)繁多，應(yīng)用模型不同，對(duì)內(nèi)核資源的依賴(lài)也不同，所有瓶頸點(diǎn)無(wú)法完全覆蓋，但至少需要包含幾大類(lèi)常見(jiàn)的內(nèi)核資源的統(tǒng)計(jì)數(shù)據(jù)：

運(yùn)行隊(duì)列長(zhǎng)度

這個(gè)可以表明是否業(yè)務(wù)進(jìn)程/線(xiàn)程并發(fā)過(guò)多，或者是否綁核不合理等

fs/block 層時(shí)延

對(duì)于不同的文件系統(tǒng)或設(shè)備、IO 調(diào)度算法，可能會(huì)有不同的瓶頸點(diǎn)，通常需要進(jìn)行分段統(tǒng)計(jì)時(shí)延來(lái)確定

內(nèi)存分配延時(shí)

受內(nèi)存水位、碎片的影響，內(nèi)存分配的時(shí)延有時(shí)可能會(huì)很大

pagefault 時(shí)長(zhǎng)與頻率

內(nèi)存缺頁(yè)導(dǎo)致的內(nèi)存請(qǐng)求、重映射、tlb flush 等對(duì)的開(kāi)銷(xiāo)是非常大的，如果頻繁的進(jìn)入到 pagefault 流程中，可以考慮從應(yīng)用策略上進(jìn)行優(yōu)化，比如預(yù)分配內(nèi)存池、使用大頁(yè)等。

關(guān)鍵路徑 kernel 鎖的競(jìng)爭(zhēng)

鎖是不可避免的機(jī)制，kernel 態(tài)鎖競(jìng)爭(zhēng)通常會(huì)導(dǎo)致 sys 態(tài)的 cpu 升高，需要結(jié)合上下文進(jìn)行具體分析。

2.3、策略

上述提到內(nèi)核資源無(wú)法完全覆蓋，但可以有另外一種方法去能觀測(cè)一些數(shù)據(jù)，因?yàn)椴煌膬?nèi)核策略可能有比較大的性能差異，所以可以嘗試通過(guò)不同系統(tǒng)間的對(duì)比，找出配置的差異點(diǎn)。通常的系統(tǒng)配置采集如下：

內(nèi)核啟動(dòng)參數(shù)

內(nèi)核配置接口 sysctl/procfs/sysfs

內(nèi)核模塊差異

cgroup配置

3、虛擬化

當(dāng)上述找不到瓶頸點(diǎn)時(shí)，或者我們想繼續(xù)挖掘性能的剩余價(jià)值，通常就會(huì)到硬件這一側(cè)，而目前業(yè)務(wù)部署在云上居多，所以在深入硬件層前，虛擬化層或者說(shuō)主機(jī)側(cè)也是繞不開(kāi)的必要因素。對(duì)主機(jī)側(cè)的性能分析，針對(duì)系統(tǒng)內(nèi)核資源制約可以復(fù)用上述的方法，但對(duì)業(yè)務(wù)畫(huà)像可以少做不少事，相對(duì)于應(yīng)用業(yè)務(wù)，虛擬化這層的邏輯不會(huì)無(wú)限變化，我們可以從各個(gè)渠道了解到云廠(chǎng)商提供的虛擬化方案，目前主流的是 Linux kvm 方案。因此可以針對(duì)性的對(duì) kvm 這個(gè)方案所所及到的技術(shù)點(diǎn)做特別分析。此處應(yīng)該包含的統(tǒng)計(jì)包括：

qemu 線(xiàn)程的被搶占頻率及時(shí)間、guest陷出頻率及事件、qemu線(xiàn)程在host上運(yùn)行的時(shí)間

通過(guò)這些來(lái)綜合判斷是否是由于虛擬化層帶來(lái)的性能損失或者是否有改善的可能性。

4、硬件性能

最后，真正到了硬件層，到這里通常都是由于單純從應(yīng)用層或者系統(tǒng)層無(wú)法找到更多的優(yōu)化空間了。其實(shí)又有兩種思路，一種是看看硬件利用率的點(diǎn)，看能否反向調(diào)整應(yīng)用，對(duì)硬件使用的熱點(diǎn)減少依賴(lài)或者分散利用；另一種就是應(yīng)用無(wú)法調(diào)整了，評(píng)估硬件的性能是否真正已到瓶頸。對(duì)于前者，又可以延伸出一套方法論來(lái)，比如 Ahmed Yasin 的TMAM，在 sysAK 中不做過(guò)多延伸，但仍然有必要的工作要做，除 cache、tlb miss、cpi 這些數(shù)據(jù)采集外，更關(guān)鍵的是怎么將這些數(shù)據(jù)結(jié)合應(yīng)用進(jìn)程的運(yùn)行情況進(jìn)行分析，比如同一 cpu 上的 cache 或帶寬競(jìng)爭(zhēng)多，是由于當(dāng)前業(yè)務(wù)自身的程序設(shè)計(jì)，還是有其他進(jìn)程存在爭(zhēng)搶導(dǎo)致，對(duì)于爭(zhēng)搶導(dǎo)致的可以通過(guò)綁核、rdt 等技術(shù)進(jìn)行配合優(yōu)化。

5、交互的應(yīng)用環(huán)境

還沒(méi)完，這里還少了一個(gè)拼圖，現(xiàn)在絕大多數(shù)應(yīng)用都不是單機(jī)的，交互的應(yīng)用之間也會(huì)產(chǎn)生性能影響，因此在應(yīng)用畫(huà)像中，我們?cè)岬竭^(guò)網(wǎng)絡(luò)連接的拓?fù)?#xff0c;就是用于此。我們可以將上述所有的性能診斷方法在和當(dāng)前應(yīng)用進(jìn)行交互的對(duì)象上復(fù)制一遍。

總結(jié)

最后的最后，以一張大圖來(lái)進(jìn)行總結(jié)。

而圖中涉及的工具將會(huì)在后續(xù)的實(shí)戰(zhàn)篇中出現(xiàn)，敬請(qǐng)期待。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。