我們的應用程序都是運行在各種語言的運行時、操作系統(tǒng)內核、以及 CPU 等硬件之上的。大家平時一般都是使用Go、Java等語言進行開發(fā)。但這些語言的下面是由運行時、內核、硬件等多層支撐起來的。

我們的程序在運行的時候，很多時候性能卡點可能并不一定是自己的應用代碼導致的。也有可能是下層的軟件的運行狀況不佳造成的。性能卡點有可能出現(xiàn)在硬件上。我們了解了CPU硬件影響程序運行性能的關鍵指標，分別是平均每條指令的時鐘周期個數(shù) CPI 和緩存命中率。性能卡點也有可能出現(xiàn)在內核軟件上。今天我們就來看下在內核中存在的可能會影響我們程序性能的幾個關鍵指標。

其實，內核開發(fā)者們也都知道內核運行的過程中，哪些開銷會比較高。所以老早就給我們提供了一種名為軟件性能事件的支持。以方便我們應用的開發(fā)者來觀測這些事件發(fā)生的次數(shù)，以及發(fā)生時所觸發(fā)的函數(shù)調用鏈。

一、軟件性能事件列表

通過 perf 的 list 子命令可以查看到當前系統(tǒng)都支持哪些軟件性能事件。

其中上面命令中的 sw 是 software 的簡稱，其實指的就是內核。下面的列表列明了一些影響性能的事件，我們挨個來解釋。

alignment-faults

這個指的是對齊異常。簡單來說，當CPU訪問內存地址時，如果發(fā)現(xiàn)訪問的地址是不對齊的，那內核向內存請求數(shù)據的時候可能一次 IO 不夠，還得再觸發(fā)一次 IO 才能把數(shù)據給讀取回來。對齊異常會增加本來不需要的內存 IO，必然會拖累程序運行性能。

如果你還沒理解的話，可以看下圖。在下圖中 0-63 和 64-127 地址的數(shù)據都可以由一次內存 IO 完成。但如果你的應用程序非得從 40 位置開始要個長為 64 的數(shù)據。那就是不對齊的。

context-switches

進程上下文切換。平均每次切換都得 3-5 us。這對于運行的飛快的操作系統(tǒng)來說，已經是一個非常長的時間了，而更為關鍵的是，對于用戶程序來說，這段時間完完全全就是浪費的。頻繁的上下文切換還會進一步導致 CPU 緩存命中率變差，拉高 CPI。

cpu-migrations

進程如果每次調度的時候都能夠在同一個CPU核上執(zhí)行，那大概率這個核的L1、L2、L3等緩存里存儲的數(shù)據還能用的上，緩存命中率高可以避免對數(shù)據的訪問穿透到過慢的內存中。所以內核在調度器的實現(xiàn)上開發(fā)了wake_affine機制來使得調度盡可能地使用上一次用過的核。

但如果進程在調度器喚醒的時候發(fā)現(xiàn)上一次使用過的核被別的進程占了，那該怎么辦?？偛恢劣诓蛔屵@個進程喚醒，硬等上一次用過的這個CPU核吧。給它分配一個別的核讓進程可以及時獲得CPU也許更好。但這時就會導致進程執(zhí)行時在CPU之間跳來跳去，這種現(xiàn)象就叫做任務遷移。

顯然任務遷移是對CPU緩存不太友好的。如果遷移次數(shù)過多必然會導致進程運行性能的下降。

emulation-faults

emulation-faults 錯誤是在 QEMU 虛擬機中運行 x86 應用程序時出現(xiàn)的一種錯誤類型。x86 程序需要在 x86 架構的計算機上運行，并且依賴于該計算機的硬件架構和指令集。QEMU 作為一款模擬器，可以模擬 x86 硬件架構和指令集，但是由于模擬器與真實硬件之間存在差異，因此在運行 x86 應用程序時可能會產生 emulation-faults 錯誤。

page-faults

這是我們常說的缺頁中斷。用戶進程中在申請內存的時候，其實申請到的只是一個vm_area_struct而已，僅僅只是一段地址范圍。物理內存并不會立即就分配，具體的分配等到實際訪問的時候。當進程在運行的過程中在棧上開始分配和訪問變量的時候，如果物理頁還沒有分配，會觸發(fā)缺頁中斷。在缺頁中斷種來真正地分配物理內存。

其中缺頁中斷又分為兩種，分別是 major-faults 和 minor-faults。這兩種錯誤的區(qū)別在于 major-faults 會導致磁盤 IO 的發(fā)生，所以對程序運行的影響更大。

二、軟件性能事件的計數(shù)統(tǒng)計

了解了內核中可能會影響程序運行性能的幾種事件后，我們的一種需求就是看看系統(tǒng)中實際發(fā)生了多少次這樣的事件。這個使用 perf stat 子命令就可以辦到。

由于上述命令我是在我手頭的一臺開發(fā)機上操作的，所以很多指標都為 0 ，只發(fā)生了 56 次不太嚴重的 minor-faults。這個命令是統(tǒng)計的整個系統(tǒng)的情況。

如果只想查看指定的程序或進程，那就在后面跟上程序名，或者通過 -p 指定進程 pid

【文章福利】小編推薦自己的Linux內核技術交流群:【749907784】整理了一些個人覺得比較好的學習書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦！?。。ê曨l教程、電子書、實戰(zhàn)項目及代碼)? ? ??

三、軟件性能事件的函數(shù)棧跟蹤

很有可能在你知道你的系統(tǒng)某中指標發(fā)生的太多的話，你還想看看到底是那些函數(shù)調用鏈導致的的。這時候 perf record 命令可以幫助你進行棧的采樣。

例如，如果你想看一下 context-switches 都是如何發(fā)生的，那就來采個樣。

在上面的命令中，其中 -a 指的是要查看所有的棧，包括用戶棧，也包括內核棧。-g 指的是不僅僅采樣時要記錄當前在運行的函數(shù)名，還要記錄整個調用鏈。-e 指的是只采樣 context-switches 事件。sleep 指的是采集 30 秒。命令執(zhí)行完后，當前目錄下會輸出一個 perf.data 文件。

默認情況下，perf stat 是一秒要采集 4000 次。這會導致采集出來的 perf.data 文件過大，而且也會影響程序性能。你可以通過 -F 參數(shù)來控制采集頻率。

使用 perf script 可以查看該perf.data文件中的內容。

也可以使用 perf report 命令進行一個簡單的統(tǒng)計

最好的辦法是用 Brendan Gregg 大神的FlameGraph項目，把采樣獲得的 perf.data 渲染成非常直觀的火焰圖。

生成方式非常的簡單，只需要把 FlameGraph 項目下載下來，再分別使用 stackcollapse-perf.pl 和 flamegraph.pl 兩個腳本進行處理即可。

其中 stackcollapse-perf.pl 腳本作用是將調用棧處理為一行。行前面表示的是調用棧，后面輸出的是采樣到該函數(shù)在運行的次數(shù)。比如下面這個處理結果表示采樣時發(fā)現(xiàn) main;funcA;funcD;funcE;caculate 這個函數(shù)調用鏈路正在執(zhí)行的次數(shù)為 554118432 次，main;funcB;caculate 這個函數(shù)調用鏈路正在執(zhí)行的次數(shù)是 338716787。

flamegraph.pl 腳本工作原理是將 stackcollapse-perf.pl 繪制成 svg 圖片。

使用火焰圖對 context-switches 內核軟件事件采樣結果 perf.data 進行渲染后，這樣能清楚地看到哪個鏈路上的上下文切換發(fā)生的最為頻發(fā)。

通過對火焰圖的觀測，就可以分析發(fā)現(xiàn)是哪些原因導致了最多的進程上下文切換的開銷了。其它內核軟件事件，例如缺頁中斷、CPU遷移等分析原理也一樣。

原文作者：開發(fā)內功修煉