1. 前言

限于作者能力水平，本文可能存在謬誤，因此而給讀者帶來(lái)的損失，作者不做任何承諾。

2. 性能分析概述

通常，我們是通過(guò)理論指導(dǎo)實(shí)踐，而實(shí)踐又反哺完善理論，二者缺一不可。
總的來(lái)說(shuō)，性能優(yōu)化是從 時(shí)間 和 空間 兩方面做出優(yōu)化，然后取得一個(gè)可接受的平衡點(diǎn)。記住，無(wú)論怎么優(yōu)化，也無(wú)法超出物理硬件的極限，假設(shè) CPU 的最高頻率是 1.5GHz ，就不可能優(yōu)化出 1.6GHz 的效果。
在現(xiàn)在復(fù)雜的系統(tǒng)中，包含很多軟硬件資源，硬件資源如 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)、GPU 、音視頻Codec等等等等，軟件資源包括各個(gè)軟件模塊、第三方庫(kù)等等等，每一個(gè)都有可能成為我們優(yōu)化的目標(biāo)；從全局考慮(考慮所有軟硬件資源)，或者從某個(gè)局部考慮(只考慮某個(gè)或某幾個(gè)軟硬件資源)，需要采用的優(yōu)化方法可能又不一樣。
當(dāng)我們遇到一個(gè)性能問題，該當(dāng)如何下手？通盤考慮全局所有資源，讓每個(gè)部分達(dá)到最佳，當(dāng)然是我們最想要的。但是，有時(shí)候這并不現(xiàn)實(shí)，譬如程序使用了一個(gè)第三方庫(kù)，而它又不開源，那很可能你無(wú)法優(yōu)化它；又或者，我們只需要將程序某個(gè)功能點(diǎn)的執(zhí)行速度提高5%，這時(shí)候可能不需要考慮全局優(yōu)化，僅僅針對(duì)某個(gè)點(diǎn)就可以了。所以，對(duì)于優(yōu)化，我認(rèn)為第一步要做的，就是要確定優(yōu)化的目標(biāo)。同時(shí)，我們也應(yīng)該考慮可行性，最高頻 1.5GHz 的 CPU 永遠(yuǎn)也無(wú)法跑出 1.6GHz 的效果。當(dāng)然，可行性有時(shí)候不是那么一目了然，那就只能試試看了。

3. 性能分析方法論一覽

對(duì)于 Linux 下的性能分析，可能我們通常的做法是：用 top 或類似工具，對(duì)程序做基本觀察，確定程序是 CPU 密集型(也稱 計(jì)算密集型) 還是 IO 密集型，然后來(lái)進(jìn)行優(yōu)化。但世界哪有那么簡(jiǎn)單，一個(gè)程序，可能有時(shí)候是 CPU 密集型 ，有時(shí)候又呈現(xiàn)為 IO 密集型 ；有的線程是 CPU 密集型 ，有的線程又是 IO 密集型 。多進(jìn)程系統(tǒng)通常不可能只有一個(gè)程序在運(yùn)行，程序相互之間也可能對(duì)彼此的性能造成妨害。程序當(dāng)前可能運(yùn)行在用戶空間，也可能運(yùn)行于內(nèi)核空間系統(tǒng)調(diào)用，有時(shí)候瓶頸在于內(nèi)核，有時(shí)候瓶頸又在用戶空間……總之各種情形都有，不一而足。為應(yīng)對(duì)各種情形，我們應(yīng)該有一些方法論，作為一般性的指導(dǎo)，告訴我們?cè)撛鯓右徊讲絹?lái)定位分析性能問題。

3.1 TSA 和 USE

TSA 和 USE 是性能分析大佬 Brendan Gregg 提出的性能分析方法論。

3.1.1 TSA

3.1.1.1 TSA 概述

TSA 是 Thread State Analysis 的縮寫，直譯過(guò)來(lái)就是 線程狀態(tài)分析 。該方法總結(jié)為：

1. 對(duì)每個(gè)觀測(cè)線程，測(cè)試線程在各個(gè)不同狀態(tài)下的總時(shí)間；
2. 使用合適的工具，根據(jù)觀測(cè)到的線程在不同狀態(tài)的總時(shí)間，按總時(shí)間由長(zhǎng)到短對(duì)線程的各狀態(tài)進(jìn)行觀測(cè).

上面用術(shù)語(yǔ)“線程”來(lái)指代系統(tǒng)中的可運(yùn)行實(shí)體，它們可能是線程、任務(wù)、進(jìn)程。
線程消耗的總時(shí)間，可劃分到各個(gè)不同線程狀態(tài)。下面劃分了6種線程狀態(tài)，作為關(guān)鍵信息源，用來(lái)標(biāo)識(shí)分析性能相關(guān)問題：

. Executing: 在CPU上執(zhí)行。
             在CPU上執(zhí)行的時(shí)間，又細(xì)分為系統(tǒng)時(shí)間和用戶時(shí)間。
             對(duì)于系統(tǒng)時(shí)間，觀測(cè)CPU時(shí)間以及系統(tǒng)調(diào)用頻率；對(duì)于用戶時(shí)間，觀測(cè)CPU時(shí)間。
             注意，CPU時(shí)間可能包含在自旋鎖上自旋的時(shí)間。
. Runnable: 等待調(diào)度到CPU行執(zhí)行。
            等待調(diào)度的時(shí)間，可以觀察CPU的利用率和飽和率、施加的各種資源限制(如cgroup
            等)、進(jìn)程CPU綁定。
. Anonymous Paging: 類似于Runnable，但是在等待進(jìn)行頁(yè)換出處理。
                    檢查系統(tǒng)內(nèi)存的使用狀況、資源限制狀態(tài)檢查(如memcg等)。
. Sleeping: 等待I/O狀態(tài), 包括網(wǎng)絡(luò)、磁盤 等I/O操作。
            檢查系統(tǒng)調(diào)用的時(shí)間和相關(guān)資源、mmap()引發(fā)的I/O；檢查資源忙碌狀態(tài)；
            通過(guò)off-cpu分析工具檢查線程阻塞。
. Lock: 等待獲取同步鎖。
        觀察線程等待的鎖、造成鎖等待的原因，以及鎖機(jī)制分析。
. Idle: 空閑狀態(tài)，無(wú)事可干，等待分配工作。

這個(gè)狀態(tài)列表，在不同的操作系統(tǒng)下，可能要做些調(diào)整，取決于用來(lái)測(cè)量評(píng)估工具報(bào)告的狀態(tài)。觀察這些線程狀態(tài)的工具，如 Linux 下的 top, mpstat, prstat 等等。有些監(jiān)視程序，可能將時(shí)間消耗歸結(jié)到某個(gè)程序組件，如時(shí)間消耗在 MySQL，PHP 等線程，這種方法稱為 面向請(qǐng)求(request-oriented) 的方法，這種方法可能造成誤導(dǎo)，這時(shí)可以通過(guò) TSA 方法來(lái)搞清楚真正的原因，通過(guò)調(diào)查發(fā)現(xiàn)，MySQL 線程的大部分 Runnable 狀態(tài)，即等待被調(diào)度到 CPU 執(zhí)行，這也就意味著，實(shí)際上是別的線程占用了 CPU 時(shí)間，而不是 MySQL 線程，所以 面向請(qǐng)求(request-oriented) 方法的結(jié)論造成了誤導(dǎo)，但通過(guò) TSA 可以修正它，這樣引導(dǎo)我們可以將注意力轉(zhuǎn)移到真正消耗 CPU 時(shí)間的線程上去。

3.1.1.2 TSA 狀態(tài)轉(zhuǎn)換

3.1.1.3 延遲類狀態(tài)

將 Runnable, Anonymous Paging, Sleeping, Lock 這4個(gè)狀態(tài)統(tǒng)稱為 延遲類狀態(tài)，一旦發(fā)現(xiàn)這類狀態(tài)的時(shí)間超過(guò)了 10% ，通?？梢赞D(zhuǎn)為檢查其它狀態(tài)的時(shí)間消耗，這可以簡(jiǎn)化分析過(guò)程。

3.1.1.3 TSA 總結(jié)

TSA 方法是一個(gè)簡(jiǎn)單的、用來(lái)分析每線程性能的方法，它為性能分析提供一個(gè)起點(diǎn)和方向。在分析的早期，可以使用個(gè)方法，和后述的 USE 方法一起，對(duì)性能問題起到基本的了解。

3.1.2 USE

3.1.2.1 USE 簡(jiǎn)介

USE 是 Utilization Saturation and Errors 的縮寫，是一種用列舉的 檢查清單 來(lái)分析性能問題的方法。該方法從提出問題開始，然后尋求問題的答案；而不是從給定的測(cè)量結(jié)果，然后逆向?qū)で蟠鸢?。針?duì)不同的操作系統(tǒng)，USE 方法使用的 檢查清單 各不相同。USE 方法可以總結(jié)為：

對(duì)每個(gè)資源，檢查 利用率、飽和度、錯(cuò)誤狀態(tài)。

USE 方法旨在用于性能分析的早期，以確定系統(tǒng)瓶頸。為方便后面的闡述，先給出幾個(gè)術(shù)語(yǔ)定義：

資源: CPU, 磁盤, 網(wǎng)絡(luò), mutex, ...
利用率: 【資源】處于忙碌狀態(tài)的平均時(shí)間。也可以說(shuō)成資源已使用的比例，譬如100%表示不能接收更多的工作。
飽和度: 【資源】不能處理的額外工作的程度。如【資源】上等待隊(duì)列的長(zhǎng)度?？梢悦枋觥举Y源】競(jìng)爭(zhēng)的激烈程度。
錯(cuò)誤狀態(tài): 【資源】錯(cuò)誤事件計(jì)數(shù)。

這 3 個(gè)指標(biāo)可能以如下形式描述：

利用率: 一段時(shí)間內(nèi)的百分比，如一個(gè)磁盤以 90% 的利用率在運(yùn)行。
飽和度: 隊(duì)列長(zhǎng)度。如 CPU 的平均運(yùn)行隊(duì)列長(zhǎng)度為 4 。
錯(cuò)誤狀態(tài)：如網(wǎng)絡(luò)接口發(fā)生50次沖突錯(cuò)誤。

對(duì)錯(cuò)誤狀態(tài)應(yīng)該引起重視，因?yàn)樗鼈儠?huì)降低性能。這在它們可恢復(fù)時(shí)，可能不會(huì)被注意到。
CPU 緩存 和 其它未列出的資源，可以在 USE 方法之后檢查 - 在排除系統(tǒng)瓶頸之后。如果不確定是否要添加上述列表之外的資源到檢查清單，請(qǐng)包含該資源，然后查看運(yùn)行中資源指標(biāo)的情況。

3.1.2.2 低利用率是否意味著沒有飽和？

即使長(zhǎng)時(shí)間平均利用率低，突發(fā)的高利用率也可能導(dǎo)致飽和性能問題。

3.1.2.3 使用 USE

使用 USE 方法，第一步是列出系統(tǒng)中可能造成性能瓶頸的資源列表；接著測(cè)試單個(gè)資源的能夠達(dá)到的上限性能；最后是順著資源清單列表，以合適的工具來(lái)查看資源當(dāng)前的指標(biāo)：利用率、飽和度、錯(cuò)誤狀態(tài)。操作步驟，一如下面的流程圖：

3.1.2.3 常見資源列表 和 它們的測(cè)量指標(biāo)

資源包括 硬件資源 和 軟件資源 兩大類。
常見 硬件資源 列表 和 測(cè)量指標(biāo)：

資源     | 測(cè)量指標(biāo)
---------|----------------------------------
CPU      | 利用率 
         | 飽和度：運(yùn)行隊(duì)列長(zhǎng)度 或 調(diào)度延遲
---------|----------------------------------
內(nèi)存     | 利用率：系統(tǒng)可用內(nèi)存
         | 飽和度：頁(yè)面換出
         | 錯(cuò)誤：內(nèi)存分配失敗次數(shù)
---------|----------------------------------
存儲(chǔ)設(shè)備 | 利用率：設(shè)備忙碌狀態(tài)比例
         | 飽和度：等待隊(duì)列長(zhǎng)度
         | 錯(cuò)誤狀態(tài)：hard, soft, ...
---------|----------------------------------
......

可能的 軟件資源 和 可能的 測(cè)量指標(biāo)：

資源                 | 測(cè)量指標(biāo)
---------------------|--------------------------------
鎖(mutex,...)        | 利用率：鎖持有的時(shí)長(zhǎng)
                     | 飽和度：等待鎖的隊(duì)列長(zhǎng)度
---------------------|--------------------------------
線程池               | 利用率：線程忙于處理工作的時(shí)間
                     | 飽和度：等待線程池處理的請(qǐng)求數(shù)
---------------------|--------------------------------
系統(tǒng)最大線程數(shù)       | ......
---------------------|--------------------------------
系統(tǒng)最大文件描述符數(shù) | ......
---------------------|--------------------------------
......

這些沒有一定的規(guī)范，可以按實(shí)際情況來(lái)定義。

3.1.2.4 USE 總結(jié)

USE 方法是一種簡(jiǎn)單的策略，可用于執(zhí)行完整的系統(tǒng)運(yùn)行狀況檢查，識(shí)別常見的瓶頸和錯(cuò)誤。它可以在調(diào)查的早期部署，并快速識(shí)別問題區(qū)域，然后如果需要，可以更詳細(xì)地研究其他方法。USE 的優(yōu)勢(shì)在于它的速度和可見性：通過(guò)考慮所有資源，你不太可能忽略任何問題。但是，它只會(huì)發(fā)現(xiàn)某些類型的問題 - 瓶頸和錯(cuò)誤 - 并且應(yīng)該被視為更大工具箱中的一員。

3.2 Intel TMA

Intel 在 CPU 微架構(gòu)層面，提供對(duì)性能分析的支持。使用自頂向下的分析方法，具有固定的套路和模式。對(duì)這個(gè)不熟悉，提到 VTune 估計(jì)不少人就明了了。
更多細(xì)節(jié)可參考 vtune-profiler 。

3.3 ARM Top-Down

利用 ARM PMU(Performance Monitor Unit) 從微架構(gòu)層面進(jìn)行性能分析。更多細(xì)節(jié)參考下列資料：
https://community.arm.com/support-forums/f/high-performance-computing-forum/46701/top-down-microarchitectural-analysis
https://community.arm.com/arm-community-blogs/b/infrastructure-solutions-blog/posts/arm-neoverse-v1-top-down-methodology-for-performance-analysis
用于分析的腳本工具：
https://gitlab.arm.com/telemetry-solution/telemetry-solution

3.4 其它

其它我所不知道的方法論，將在未來(lái)添加。

4. 參考資料

https://brendangregg.com/usemethod.html
https://brendangregg.com/tsamethod.html文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-418170.html

到了這里，關(guān)于性能分析方法論簡(jiǎn)介的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！