如果你的 Linux 服務器突然負載暴增，告警短信快發爆你的手機，如何在最短時間內找出 Linux 性能問題所在？來看 Netflix 性能工程團隊的這篇博文，看它們通過十條命令在一分鐘內對機器性能問題進行診斷。
概述
通過執行以下命令，可以在 1 分鐘內對系統資源使用情況有個大致的瞭解。
- 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 包，有一些由 procps 包提供。這些命令的輸出，有助於快速定位性能瓶頸，檢查出所有資源（CPU、內存、磁盤 IO 等）的利用率（utilization）、飽和度（saturation）和錯誤（error）度量，也就是所謂的 USE 方法。
下面我們來逐一介紹下這些命令，有關這些命令更多的參數和說明，請參照命令的手冊。
uptime
$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
這個命令可以快速查看機器的負載情況。在 Linux 系統中，這些數據表示等待 CPU 資源的進程和阻塞在不可中斷 IO 進程（進程狀態爲 D）的數量。這些數據可以讓我們對系統資源使用有一個宏觀的瞭解。
命令的輸出分別表示 1 分鐘、5 分鐘、15 分鐘的平均負載情況。通過這三個數據，可以瞭解服務器負載是在趨於緊張還是區域緩解。如果 1 分鐘平均負載很高，而 15 分鐘平均負載很低，說明服務器正在命令高負載情況，需要進一步排查 CPU 資源都消耗在了哪裏。反之，如果 15 分鐘平均負載很高，1 分鐘平均負載較低，則有可能是 CPU 資源緊張時刻已經過去。
上面例子中的輸出，可以看見最近 1 分鐘的平均負載非常高，且遠高於最近 15 分鐘負載，因此我們需要繼續排查當前系統中有什麼進程消耗了大量的資源。可以通過下文將會介紹的 vmstat、mpstat 等命令進一步排查。
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 kill 和一次 TCP 丟包。這些日誌可以幫助排查性能問題。千萬不要忘了這一步。
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(8) 命令，每行會輸出一些系統核心指標，這些指標可以讓我們更詳細的瞭解系統狀態。後面跟的參數 1，表示每秒輸出一次統計信息，表頭提示了每一列的含義，這幾介紹一些和性能調優相關的列：
- r：等待在 CPU 資源的進程數。這個數據比平均負載更加能夠體現 CPU 負載情況，數據中不包含等待 IO 的進程。如果這個數值大於機器 CPU 核數，那麼機器的 CPU 資源已經飽和。
- free：系統可用內存數（以千字節爲單位），如果剩餘內存不足，也會導致系統性能問題。下文介紹到的 free 命令，可以更詳細的瞭解系統內存的使用情況。
- si, so：交換區寫入和讀取的數量。如果這個數據不爲 0，說明系統已經在使用交換區（swap），機器物理內存已經不足。
- us, sy, id, wa, st：這些都代表了 CPU 時間的消耗，它們分別表示用戶時間（user）、系統（內核）時間（sys）、空閒時間（idle）、IO 等待時間（wait）和被偷走的時間（stolen，一般被其他虛擬機消耗）。
上述這些 CPU 時間，可以讓我們很快了解 CPU 是否出於繁忙狀態。一般情況下，如果用戶時間和系統時間相加非常大，CPU 出於忙於執行指令。如果 IO 等待時間很長，那麼系統的瓶頸可能在磁盤 IO。
示例命令的輸出可以看見，大量 CPU 時間消耗在用戶態，也就是用戶應用程序消耗了 CPU 時間。這不一定是性能問題，需要結合 r 隊列，一起分析。
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 佔用率特別高，那麼有可能是一個單線程應用程序引起的。
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 命令輸出進程的 CPU 佔用率，該命令會持續輸出，並且不會覆蓋之前的數據，可以方便觀察系統動態。如上的輸出，可以看見兩個 JAVA 進程佔用了將近 1600% 的 CPU 時間，既消耗了大約 16 個 CPU 核心的運算資源。
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
iostat 命令主要用於查看機器磁盤 IO 情況。該命令輸出的列，主要含義是：
- r/s, w/s, rkB/s, wkB/s：分別表示每秒讀寫次數和每秒讀寫數據量（千字節）。讀寫量過大，可能會引起性能問題。
- await：IO 操作的平均等待時間，單位是毫秒。這是應用程序在和磁盤交互時，需要消耗的時間，包括 IO 等待和實際操作的耗時。如果這個數值過大，可能是硬件設備遇到了瓶頸或者出現故障。
- avgqu-sz：向設備發出的請求平均數量。如果這個數值大於 1，可能是硬件設備已經飽和（部分前端硬件設備支持並行寫入）。
- %util：設備利用率。這個數值表示設備的繁忙程度，經驗值是如果超過 60，可能會影響 IO 性能（可以參照 IO 操作平均等待時間）。如果到達 100%，說明硬件設備已經飽和。
如果顯示的是邏輯設備的數據，那麼設備利用率不代表後端實際的硬件設備已經飽和。值得注意的是，即使 IO 性能不理想，也不一定意味這應用程序性能會不好，可以利用諸如預讀取、寫緩存等策略提升應用性能。
free –m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
free 命令可以查看系統內存的使用情況，-m 參數表示按照兆字節展示。最後兩列分別表示用於 IO 緩存的內存數，和用於文件系統頁緩存的內存數。需要注意的是，第二行 -/+ buffers/cache，看上去緩存佔用了大量內存空間。這是 Linux 系統的內存使用策略，儘可能的利用內存，如果應用程序需要內存，這部分內存會立即被回收並分配給應用程序。因此，這部分內存一般也被當成是可用內存。
如果可用內存非常少，系統可能會動用交換區（如果配置了的話），這樣會增加 IO 開銷（可以在 iostat 命令中提現），降低系統性能。
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