如何 60 秒內(nèi)進行 Linux 性能分析
本文轉(zhuǎn)載自微信公眾號「 黑光技術(shù)」,轉(zhuǎn)載本文請聯(lián)系 黑光技術(shù)公眾號。
當你登陸一臺 Linux 服務器之后,因為一個問題要做性能分析時:你會在第 1 分鐘內(nèi)做哪些檢測呢?
在 Netflix,我們有很多 EC2 的 Linux 機器,并且也需要很多性能分析工具來監(jiān)控和檢查它們的性能。包括有針對云上的監(jiān)控工具 Atlas,和按需要進行實例分析的 Vector。雖然這些工具能幫助我們解決大多數(shù)問題,但是我們有時候還需要登陸機器實例去運行一些標準的 Linux 性能分析工具。
最開始的 60 秒:總結(jié)
在這篇文章中,Netflix 的性能分析工程師團隊會給你展示在最開始的 60 秒內(nèi),如何在命令行模式下使用已有的 Linux 標準工具進行性能優(yōu)化檢測。在 60 秒內(nèi)只需要通過運行下面的 10 個命令就可以對系統(tǒng)資源使用和運行進程有一個很高程度的了解。尋找錯誤信息和飽和度指標,并且可以顯示為請求隊列的長度,或者等待時長。因為它們都很容易理解,然后就是資源利用率。飽和度是指一個資源已經(jīng)超過了它自己的負荷能力。
- 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,內(nèi)存,磁盤等)的錯誤指標(Errors)。同樣也要關(guān)注你什么時候檢查和排除一個資源問題,因為通過排除可以縮小分析范圍,同時也指導了任何后續(xù)的檢查。
下面的章節(jié)將會通過一個生產(chǎn)系統(tǒng)中的例子來介紹這些命令。要了解更多這些工具的信息,也可以查看它們的幫助手冊。
1. uptime
- $ uptime
- 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
這是一個快速展示系統(tǒng)平均負載的方法,這也指出了等待運行進程的數(shù)量。在 Linux 系統(tǒng)中,這些數(shù)字包括等待 CPU 運行的進程數(shù),也包括了被不可中斷 I/O(通常是磁盤 I/O)阻塞的進程。這給出了資源負載的很直接的展示,可以在沒有其它工具的幫助下更好的理解這些數(shù)據(jù)。它是唯一快捷的查看系統(tǒng)負載的方式。
這三個數(shù)字是以遞減的方式統(tǒng)計了過去 1 分鐘,5 分鐘和 15 分鐘常數(shù)的平均數(shù)。這三個數(shù)字給我們直觀展示了隨著時間的變化系統(tǒng)負載如何變化。例如,如果你被叫去查看一個有問題的服務器,并且 1 分鐘的所代表的值比 15 分鐘的值低很多,那么你可能由于太遲登陸機器而錯過了問題發(fā)生的時間點。
在上面的例子中,平均負載顯示是在不斷增加的,1 分鐘的值是 30,相比 15 分鐘的值 19 來說是增加了。這個數(shù)字這么大就意味著有事情發(fā)生了:可能是 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 條系統(tǒng)消息日志,如果系統(tǒng)消息沒有就不會展示。主要是看由于性能問題導致的錯誤。上面這個例子中包含了殺死 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
對虛擬內(nèi)存統(tǒng)計的簡短展示,vmstat 是一個常用工具(最早是幾十年前為 BSD 創(chuàng)建的)。它每一行打印關(guān)鍵的服務信息統(tǒng)計摘要。
vmstat 使用參數(shù) 1 來運行的時候,是每 1 秒打印一條統(tǒng)計信息。在這個版本的 vmstat 中,輸出的第一行展示的是自從啟動后的平均值,而不是前一秒的統(tǒng)計。所以現(xiàn)在,可以跳過第一行,除非你要看一下抬頭的字段含義。
每列含義說明:
- r: CPU 上的等待運行的可運行進程數(shù)。這個指標提供了判斷 CPU 飽和度的數(shù)據(jù),因為它不包含 I/O 等待的進程。可解釋為:“r” 的值比 CPU 數(shù)大的時候就是飽和的。
- free:空閑內(nèi)存,單位是 k。如果這個數(shù)比較大,就說明你還有充足的空閑內(nèi)存。“free -m” 和下面第 7 個命令,可以更詳細的分析空閑內(nèi)存的狀態(tài)。
- si,so:交換進來和交換出去的數(shù)據(jù)量,如果這兩個值為非 0 值,那么就說明沒有內(nèi)存了。
- us,sy,id,wa,st:這些是 CPU 時間的分解,是所有 CPU 的平均值。它們是用戶時間,系統(tǒng)時間(內(nèi)核),空閑,等待 I/O 時間,和被偷的時間(這里主要指其它的客戶,或者使用 Xen,這些客戶有自己獨立的操作域)。
CPU 時間的分解可以幫助確定 CPU 是不是非常忙(通過用戶時間和系統(tǒng)時間累加判斷)。持續(xù)的 I/O 等待則表明磁盤是瓶頸。這種情況下 CPU 是比較空閑的,因為任務都由于等待磁盤 I/O 而被阻塞。你可以把等待 I/O 看作是另外一種形式的 CPU 空閑,而這個命令給了為什么它們空閑的線索。
系統(tǒng)時間對于 I/O 處理來說是必須的。比較高的平均系統(tǒng)時間消耗,比如超過了 20%,就有必要進一步探索分析了:也有可能是內(nèi)核處理 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 的時間統(tǒng)計,可以看出整體 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 統(tǒng)計信息功能,但是它是以不斷滾動更新的方式打印信息,而不是每次清屏打印。這個對于觀察隨時間變化的模式很有用,同時把你看到的信息(復制粘貼)記到你的調(diào)查記錄中。
上面的例子可以看出是 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
這個工具對于理解塊設備(比如磁盤)很有用,展示了請求負載和性能數(shù)據(jù)。具體的數(shù)據(jù)看下面字段的解釋:
- r/s, w/s, rkB/s, wkB/s:這些表示設備上每秒鐘的讀寫次數(shù)和讀寫的字節(jié)數(shù)(單位是k字節(jié))。這些可以看出設備的負載情況。性能問題可能就是簡單的因為大量的文件加載請求。
- await:I/O 等待的平均時間(單位是毫秒)。這是應用程序所等待的時間,包含了等待隊列中的時間和被調(diào)度服務的時間。過大的平均等待時間就預示著設備超負荷了或者說設備有問題了。
- avgqu-sz:設備上請求的平均數(shù)。數(shù)值大于 1 可能表示設備飽和了(雖然設備通常都是可以支持并行請求的,特別是在背后掛了多個磁盤的虛擬設備)。
- %util:設備利用率。是使用率的百分數(shù),展示每秒鐘設備工作的時間。這個數(shù)值大于 60% 則會導致性能很低(可以在 await 中看),當然這也取決于設備特點。這個數(shù)值接近 100% 則表示設備飽和了。
如果存儲設備是一個邏輯磁盤設備,后面掛載了多個磁盤,那么 100% 的利用率則只是表示有些 I/O 是在 100% 處理,然而后端的磁盤或許遠遠沒有飽和,還可以處理更多的請求。
請記住,磁盤 I/O 性能低不一定是應用程序的問題。許多技術(shù)通常都被用來實現(xiàn)異步執(zhí)行 I/O,所以應用程序不會直接阻塞和承受延時(比如:預讀取和寫緩沖技術(shù))。
7. free -m
- $ free -m
- total used free shared buffers cached
- Mem: 245998 24545 221453 83 59 541
- -/+ buffers/cache: 23944 222053
- Swap:
右面兩列展示的是:
- buffers:用于塊設備 I/O 緩沖的緩存。
- cached:用于文件系統(tǒng)的頁緩存。
我們只想檢測這些緩存的數(shù)值是否接近 0 。不為 0 的可能導致較高的磁盤 I/O(通過 iostat 命令來確認)和較差的性能問題。上面的例子看起來沒問題,都還有很多 M 字節(jié)。
“-/+ buffers/cache” 這一行提供了對已使用和空閑內(nèi)存明確的統(tǒng)計。Linux 用空閑內(nèi)存作為緩存,如果應用程序需要,可以快速拿回去。所以應該包含空閑內(nèi)存那一列,這里就是這么統(tǒng)計的。甚至有一個網(wǎng)站專門來介紹 Linux 內(nèi)存消耗的問題:linuxatemyram。
如果在 Linux 上使用了 ZFS 文件系統(tǒng),則可能會更亂,因為當我們在開發(fā)一些服務的時候,ZFS 有它自己的文件系統(tǒng)緩存,而這部分內(nèi)存的消耗是不會在 free -m 這個命令中合理的反映的。顯示了系統(tǒng)內(nèi)存不足,但是 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
使用這個工具是可以檢測網(wǎng)絡接口的吞吐:rxkB/s 和 txkB/s,作為收發(fā)數(shù)據(jù)負載的度量,也是檢測是否達到收發(fā)極限。在上面這個例子中,eth0 接收數(shù)據(jù)達到 22 M 字節(jié)/秒,也就是 176 Mbit/秒(網(wǎng)卡的上限是 1 Gbit/秒)。
這個版本的工具還有一個統(tǒng)計字段: %ifutil,用于統(tǒng)計設備利用率(全雙工雙向最大值),這個利用率也可以使用 Brendan 的 nicstat 工具來測量統(tǒng)計。在這個例子中 0.00 這種情況就似乎就是沒有統(tǒng)計,這個和 nicstat 一樣,這個值是比較難統(tǒng)計正確的。
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 關(guān)鍵指標的統(tǒng)計,它包含了以下內(nèi)容:
- active/s:每秒本地發(fā)起的 TCP 連接數(shù)(例如通過 connect() 發(fā)起的連接)。
- passive/s:每秒遠程發(fā)起的連接數(shù)(例如通過 accept() 接受的連接)。
- retrans/s:每秒TCP重傳數(shù)。
這種主動和被動統(tǒng)計數(shù)通常用作對系統(tǒng)負載的粗略估計:新接受連接數(shù)(被動),下游連接數(shù)(主動)。可以把主動看作是外部的,被動的是內(nèi)部,但是這個通常也不是非常準確(例如:當有本地到本地的連接時)。
重傳是網(wǎng)絡或者服務器有問題的一個信號;可能是一個不可靠的網(wǎng)絡(例如:公網(wǎng)),或者可能是因為服務器過載了開始丟包。上面這個例子可以看出是每秒新建一個 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 這樣的工具就會很清晰,它們是以滾動的方式輸出統(tǒng)計信息。所以如果你在看到有問題的信息時沒有及時的暫停下來(Ctrl-S 是暫停, Ctrl-Q 是繼續(xù)),那么這些有用的信息就會被清屏。
Follow-on Analysis
還有很多可以使用來深挖系統(tǒng)問題的命令和技術(shù),可以看看 Brendan 在 2015 年講的 Linux 性能工具介紹 ,這里面講述了 40 多個命令,涵蓋了可觀測性,基準測試,調(diào)優(yōu),靜態(tài)性能調(diào)優(yōu),分析和跟蹤等多個方面。
原文:https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55