如何進行Linux的性能分析

今天就跟大家聊聊有關如何進行Linux的性能分析，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

當你登陸一臺 Linux 服務器之后，因為一個問題要做性能分析時：你會在第 1 分鐘內做哪些檢測呢?

在 Netflix，我們有很多 EC2 的 Linux 機器，并且也需要很多性能分析工具來監控和檢查它們的性能。包括有針對云上的監控工具  Atlas，和按需要進行實例分析的 Vector。雖然這些工具能幫助我們解決大多數問題，但是我們有時候還需要登陸機器實例去運行一些標準的 Linux  性能分析工具。

最開始的 60 秒：總結

在這篇文章中，Netflix 的性能分析工程師團隊會給你展示在最開始的 60 秒內，如何在命令行模式下使用已有的 Linux 標準工具進行性能優化檢測。在  60 秒內只需要通過運行下面的 10  個命令就可以對系統資源使用和運行進程有一個很高程度的了解。尋找錯誤信息和飽和度指標，并且可以顯示為請求隊列的長度，或者等待時長。因為它們都很容易理解，然后就是資源利用率。飽和度是指一個資源已經超過了它自己的負荷能力。

uptime dmesg | tail vmstat 1 mpstat -P ALL 1 pidstat 1 iostat -xz 1 free -m sar -n DEV 1 sar -n TCP,ETCP 1 top

有些命令需要安裝 sysstat 工具包。這些命令展示的指標會幫助你完成一些 USE(Utilization，Saturation，Errors)  方法：定位性能瓶頸的方法論。包括了檢查使用率(Utilization)，飽和度(Saturation)，所有資源(比如  CPU，內存，磁盤等)的錯誤指標(Errors)。同樣也要關注你什么時候檢查和排除一個資源問題，因為通過排除可以縮小分析范圍，同時也指導了任何后續的檢查。

下面的章節將會通過一個生產系統中的例子來介紹這些命令。要了解更多這些工具的信息，也可以查看它們的幫助手冊。

1. uptime

$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

這是一個快速展示系統平均負載的方法，這也指出了等待運行進程的數量。在 Linux 系統中，這些數字包括等待 CPU 運行的進程數，也包括了被不可中斷  I/O(通常是磁盤 I/O)阻塞的進程。這給出了資源負載的很直接的展示，可以在沒有其它工具的幫助下更好的理解這些數據。它是唯一快捷的查看系統負載的方式。

這三個數字是以遞減的方式統計了過去 1 分鐘，5 分鐘和 15  分鐘常數的平均數。這三個數字給我們直觀展示了隨著時間的變化系統負載如何變化。例如，如果你被叫去查看一個有問題的服務器，并且 1 分鐘的所代表的值比 15  分鐘的值低很多，那么你可能由于太遲登陸機器而錯過了問題發生的時間點。

在上面的例子中，平均負載顯示是在不斷增加的，1 分鐘的值是 30，相比 15 分鐘的值 19 來說是增加了。這個數字這么大就意味著有事情發生了：可能是  CPU 需求;vmstat 或者 mpstat 會幫助確認到底是什么，這些命令會在本系列的第 3 和第 4 個命令中介紹。

2. dmesg | tail

$ dmesg | tail [1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0 [...] [1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child [1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB [2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request.  Check SNMP counters.

這里展示的是最近 10 條系統消息日志，如果系統消息沒有就不會展示。主要是看由于性能問題導致的錯誤。上面這個例子中包含了殺死 OOM 問題的進程，丟棄  TCP 請求的問題。

所以要記得使用這個命令， dmesg 命令值得一用。

3. vmstat 1

$ vmstat 1 procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----  r  b swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  0 32  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  0 32  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  0 32  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  0 32  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  1  1  0  0 ^C

對虛擬內存統計的簡短展示，vmstat 是一個常用工具(最早是幾十年前為 BSD 創建的)。它每一行打印關鍵的服務信息統計摘要。

vmstat 使用參數 1 來運行的時候，是每 1 秒打印一條統計信息。在這個版本的 vmstat  中，輸出的第一行展示的是自從啟動后的平均值，而不是前一秒的統計。所以現在，可以跳過第一行，除非你要看一下抬頭的字段含義。

每列含義說明：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. r: CPU 上的等待運行的可運行進程數。這個指標提供了判斷 CPU 飽和度的數據，因為它不包含 I/O 等待的進程?？山忉尀椋骸皉” 的值比 CPU  數大的時候就是飽和的。

3. free：空閑內存，單位是 k。如果這個數比較大，就說明你還有充足的空閑內存?！癴ree -m” 和下面第 7  個命令，可以更詳細的分析空閑內存的狀態。

4. si，so：交換進來和交換出去的數據量，如果這兩個值為非 0 值，那么就說明沒有內存了。

5. us，sy，id，wa，st：這些是 CPU 時間的分解，是所有 CPU 的平均值。它們是用戶時間，系統時間(內核)，空閑，等待 I/O  時間，和被偷的時間(這里主要指其它的客戶，或者使用 Xen，這些客戶有自己獨立的操作域)。

CPU 時間的分解可以幫助確定 CPU 是不是非常忙(通過用戶時間和系統時間累加判斷)。持續的 I/O 等待則表明磁盤是瓶頸。這種情況下 CPU  是比較空閑的，因為任務都由于等待磁盤 I/O 而被阻塞。你可以把等待 I/O 看作是另外一種形式的 CPU 空閑，而這個命令給了為什么它們空閑的線索。

系統時間對于 I/O 處理來說是必須的。比較高的平均系統時間消耗，比如超過了 20%，就有必要進一步探索分析了：也有可能是內核處理 I/O  效率不夠高導致。

在上面的例子中，CPU 時間幾乎都是用戶級別的，說明這是一個應用級別的使用情況。如果CPU 的使用率平均都超過了 90%。這不一定問題;可以使用 “r”  列來檢查使用飽和度。

4. mpstat -p ALL 1

$ mpstat -P ALL 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)  07:38:49 PM  CPU   %usr  %nice   %sys %iowait   %irq  %soft  %steal  %guest  %gnice  %idle 07:38:50 PM  all  98.47   0.00   0.75    0.00   0.00   0.00    0.00    0.00    0.00   0.78 07:38:50 PM    0  96.04   0.00   2.97    0.00   0.00   0.00    0.00    0.00    0.00   0.99 07:38:50 PM    1  97.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   2.00 07:38:50 PM    2  98.00   0.00   1.00    0.00   0.00   0.00    0.00    0.00    0.00   1.00 07:38:50 PM    3  96.97   0.00   0.00    0.00   0.00   0.00    0.00    0.00    0.00   3.03 [...]

這個命令打印各個 CPU 的時間統計，可以看出整體 CPU 的使用是不是均衡的。有一個使用率明顯較高的 CPU  就可以明顯看出來這是一個單線程應用。

5. pidstat 1

$ pidstat 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)  07:41:02 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command 07:41:03 PM     0         9    0.00    0.94    0.00    0.94     1  rcuos/0 07:41:03 PM     0      4214    5.66    5.66    0.00   11.32    15  mesos-slave 07:41:03 PM     0      4354    0.94    0.94    0.00    1.89     8  java 07:41:03 PM     0      6521 1596.23    1.89    0.00 1598.11    27  java 07:41:03 PM     0      6564 1571.70    7.55    0.00 1579.25    28  java 07:41:03 PM 60004     60154    0.94    4.72    0.00    5.66     9  pidstat  07:41:03 PM   UID       PID    %usr %system  %guest    %CPU   CPU  Command 07:41:04 PM     0      4214    6.00    2.00    0.00    8.00    15  mesos-slave 07:41:04 PM     0      6521 1590.00    1.00    0.00 1591.00    27  java 07:41:04 PM     0      6564 1573.00   10.00    0.00 1583.00    28  java 07:41:04 PM   108      6718    1.00    0.00    0.00    1.00     0  snmp-pass 07:41:04 PM 60004     60154    1.00    4.00    0.00    5.00     9  pidstat ^C

pidstat 命令有點像 top 命令中的為每個 CPU  統計信息功能，但是它是以不斷滾動更新的方式打印信息，而不是每次清屏打印。這個對于觀察隨時間變化的模式很有用，同時把你看到的信息(復制粘貼)記到你的調查記錄中。

上面的例子可以看出是 2 個 java 進程在消耗 CPU。%CPU 列是所有 CPU 的使用率;1591% 是說明這個 java 進程消耗了幾乎 16  個 CPU 核。

6. iostat -xz 1

$ iostat -xz 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015  _x86_64_ (32 CPU)  avg-cpu:  %user   %nice %system %iowait  %steal   %idle           73.96    0.00    3.73    0.03    0.06   22.21  Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util xvda        0.00     0.23    0.21    0.18     4.52     2.08    34.37     0.00    9.98   13.80    5.42   2.44   0.09 xvdb        0.01     0.00    1.02    8.94   127.97   598.53   145.79     0.00    0.43    1.78    0.28   0.25   0.25 xvdc        0.01     0.00    1.02    8.86   127.79   595.94   146.50     0.00    0.45    1.82    0.30   0.27   0.26 dm-0        0.00     0.00    0.69    2.32    10.47    31.69    28.01     0.01    3.23    0.71    3.98   0.13   0.04 dm-1        0.00     0.00    0.00    0.94     0.01     3.78     8.00     0.33  345.84    0.04  346.81   0.01   0.00 dm-2        0.00     0.00    0.09    0.07     1.35     0.36    22.50     0.00    2.55    0.23    5.62   1.78   0.03 [...] ^C

這個工具對于理解塊設備(比如磁盤)很有用，展示了請求負載和性能數據。具體的數據看下面字段的解釋：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. r/s, w/s, rkB/s,  wkB/s：這些表示設備上每秒鐘的讀寫次數和讀寫的字節數(單位是k字節)。這些可以看出設備的負載情況。性能問題可能就是簡單的因為大量的文件加載請求。

3. await：I/O  等待的平均時間(單位是毫秒)。這是應用程序所等待的時間，包含了等待隊列中的時間和被調度服務的時間。過大的平均等待時間就預示著設備超負荷了或者說設備有問題了。

4. avgqu-sz：設備上請求的平均數。數值大于 1 可能表示設備飽和了(雖然設備通常都是可以支持并行請求的，特別是在背后掛了多個磁盤的虛擬設備)。

5. %util：設備利用率。是使用率的百分數，展示每秒鐘設備工作的時間。這個數值大于 60% 則會導致性能很低(可以在 await  中看)，當然這也取決于設備特點。這個數值接近 100% 則表示設備飽和了。

如果存儲設備是一個邏輯磁盤設備，后面掛載了多個磁盤，那么 100% 的利用率則只是表示有些 I/O 是在 100%  處理，然而后端的磁盤或許遠遠沒有飽和，還可以處理更多的請求。

請記住，磁盤 I/O 性能低不一定是應用程序的問題。許多技術通常都被用來實現異步執行  I/O，所以應用程序不會直接阻塞和承受延時(比如：預讀取和寫緩沖技術)。

7. free -m

$ free -m              total       used       free     shared    buffers     cached Mem:        245998      24545     221453         83         59        541 -/+ buffers/cache:      23944     222053 Swap:

右面兩列展示的是：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. buffers：用于塊設備 I/O 緩沖的緩存。

3. cached：用于文件系統的頁緩存。

我們只想檢測這些緩存的數值是否接近 0 。不為 0 的可能導致較高的磁盤 I/O(通過 iostat  命令來確認)和較差的性能問題。上面的例子看起來沒問題，都還有很多 M 字節。

“-/+ buffers/cache” 這一行提供了對已使用和空閑內存明確的統計。Linux  用空閑內存作為緩存，如果應用程序需要，可以快速拿回去。所以應該包含空閑內存那一列，這里就是這么統計的。甚至有一個網站專門來介紹 Linux  內存消耗的問題：linuxatemyram。

如果在 Linux 上使用了 ZFS 文件系統，則可能會更亂，因為當我們在開發一些服務的時候，ZFS 有它自己的文件系統緩存，而這部分內存的消耗是不會在  free -m 這個命令中合理的反映的。顯示了系統內存不足，但是 ZFS 的這部分緩存是可以被應用程序使用的。

8. sar -n DEV 1

$ sar -n DEV 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015     _x86_64_    (32 CPU)  12:16:48 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil 12:16:49 AM      eth0  18763.00   5032.00  20686.42    478.30      0.00      0.00      0.00      0.00 12:16:49 AM        lo     14.00     14.00      1.36      1.36      0.00      0.00      0.00      0.00 12:16:49 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00  12:16:49 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil 12:16:50 AM      eth0  19763.00   5101.00  21999.10    482.56      0.00      0.00      0.00      0.00 12:16:50 AM        lo     20.00     20.00      3.25      3.25      0.00      0.00      0.00      0.00 12:16:50 AM   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00 ^C

使用這個工具是可以檢測網絡接口的吞吐：rxkB/s 和 txkB/s，作為收發數據負載的度量，也是檢測是否達到收發極限。在上面這個例子中，eth0  接收數據達到 22 M 字節/秒，也就是 176 Mbit/秒(網卡的上限是 1 Gbit/秒)。

這個版本的工具還有一個統計字段: %ifutil，用于統計設備利用率(全雙工雙向最大值)，這個利用率也可以使用 Brendan 的 nicstat  工具來測量統計。在這個例子中 0.00 這種情況就似乎就是沒有統計，這個和 nicstat 一樣，這個值是比較難統計正確的。

9. sar -n TCP,ETCP 1

$ sar -n TCP,ETCP 1 Linux 3.13.0-49-generic (titanclusters-xxxxx)  07/14/2015    _x86_64_    (32 CPU)  12:17:19 AM  active/s passive/s    iseg/s    oseg/s 12:17:20 AM      1.00      0.00  10233.00  18846.00  12:17:19 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:20 AM      0.00      0.00      0.00      0.00      0.00  12:17:20 AM  active/s passive/s    iseg/s    oseg/s 12:17:21 AM      1.00      0.00   8359.00   6039.00  12:17:20 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s 12:17:21 AM      0.00      0.00      0.00      0.00      0.00 ^C

這是對 TCP 關鍵指標的統計，它包含了以下內容：

1. active/s：每秒本地發起的 TCP 連接數(例如通過 connect() 發起的連接)。

2. passive/s：每秒遠程發起的連接數(例如通過 accept() 接受的連接)。

3. retrans/s：每秒TCP重傳數。

這種主動和被動統計數通常用作對系統負載的粗略估計：新接受連接數(被動)，下游連接數(主動)?？梢园阎鲃涌醋魇峭獠康?，被動的是內部，但是這個通常也不是非常準確(例如：當有本地到本地的連接時)。

重傳是網絡或者服務器有問題的一個信號;可能是一個不可靠的網絡(例如：公網)，或者可能是因為服務器過載了開始丟包。上面這個例子可以看出是每秒新建一個 TCP  連接。

10. top

$ top top - 00:15:40 up 21:56,  1 user,  load average: 31.09, 29.87, 29.92 Tasks: 871 total,   1 running, 868 sleeping,   0 stopped,   2 zombie %Cpu(s): 96.8 us,  0.4 sy,  0.0 ni,  2.7 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st KiB Mem:  25190241+total, 24921688 used, 22698073+free,    60448 buffers KiB Swap:        0 total,        0 used,        0 free.   554208 cached Mem     PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND  20248 root      20   0  0.227t 0.012t  18748 S  3090  5.2  29812:58 java   4213 root      20   0 2722544  64640  44232 S  23.5  0.0 233:35.37 mesos-slave  66128 titancl+  20   0   24344   2332   1172 R   1.0  0.0   0:00.07 top   5235 root      20   0 38.227g 547004  49996 S   0.7  0.2   2:02.74 java   4299 root      20   0 20.015g 2.682g  16836 S   0.3  1.1  33:14.42 java      1 root      20   0   33620   2920   1496 S   0.0  0.0   0:03.82 init      2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd      3 root      20   0       0      0      0 S   0.0  0.0   0:05.35 ksoftirqd/0      5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H      6 root      20   0       0      0      0 S   0.0  0.0   0:06.94 kworker/u256:0      8 root      20   0       0      0      0 S   0.0  0.0   2:38.05 rcu_sched

top 命令包含了很多我們前面提到的指標。這個命令可以很容易看出指標的變化表示負載的變化，這個看起來和前面的命令有很大不同。

top 的一個缺陷也比較明顯，很難看出變化趨勢，其它像 vmstat 和 pidstat  這樣的工具就會很清晰，它們是以滾動的方式輸出統計信息。所以如果你在看到有問題的信息時沒有及時的暫停下來(Ctrl-S 是暫停, Ctrl-Q  是繼續)，那么這些有用的信息就會被清屏。

Follow-on Analysis

還有很多可以使用來深挖系統問題的命令和技術，可以看看 Brendan 在 2015 年講的 Linux 性能工具介紹 ，這里面講述了 40  多個命令，涵蓋了可觀測性，基準測試，調優，靜態性能調優，分析和跟蹤等多個方面。

看完上述內容，你們對如何進行Linux的性能分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。