60,000 毫秒內對 Linux 的性能診斷

當你為了解決一個性能問題登錄到一臺 Linux 服務器：在第一分鐘你應該檢查些什么？

在 Netflix，我們有一個巨大的 EC2 Linux 云，以及大量的性能分析工具來監控和診斷其性能。其中包括用于云監控的 Atlas，以及用于按需實例分析的 Vector。雖然這些工具可以幫助我們解決大多數問題，但我們有時仍需要登錄到一個服務器實例，并運行一些標準 Linux 性能工具。

在這篇文章中，Netflix Performance Engineering 團隊將會向你講解在命令行中進行一次最佳的性能分析的前 60 秒要做的事，使用的是你應該可以得到的標準 Linux 工具。

前六十秒：總覽

通過運行下面十個命令，你就能在六十秒內粗略地了解系統正在運行的進程及資源使用情況。通過查看這些命令輸出的錯誤信息和資源飽和度（它們都很容易看懂），你可以接下來對資源進行優化。飽和是指某個資源的負載超出了其能夠處理的限度。一旦出現飽和，它通常會在請求隊列的長度或等待時間上暴露出來。

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 方法（一種用于定位性能瓶頸的方法），比如檢查各種資源（如 CPU、內存、磁盤等）的使用率、飽和度和錯誤信息。另外在定位問題的過程中，你可以通過使用這些命令來排除某些導致問題的可能性，幫助你縮小檢查范圍，為下一步檢查指明方向。

下面的章節將以在一個生產環境上執行這些命令作為例子，簡單介紹這些命令。若想詳細了解這些工具的使用方法，請參考它們的 man 文檔。

1. uptime

這是一種用來快速查看系統平均負載的方法，它表明了系統中有多少要運行的任務（進程）。在 Linux 系統中，這些數字包含了需要在 CPU 中運行的進程以及正在等待 I/O（通常是磁盤 I/O）的進程。它僅僅是對系統負載的一個粗略展示，稍微看下即可。你還需要其他工具來進一步了解具體情況。

這三個數字展示的是一分鐘、五分鐘和十五分鐘內系統的負載總量平均值按照指數比例壓縮得到的結果。從中我們可以看到系統的負載是如何隨時間變化的。比方你在檢查一個問題，然后看到 1 分鐘對應的值遠小于 15 分鐘的值，那么可能說明這個問題已經過去了，你沒能及時觀察到。

在上面這個例子中，系統負載在隨著時間增加，因為最近一分鐘的負載值超過了 30，而 15 分鐘的平均負載則只有 19。這樣顯著的差距包含了很多含義，比方 CPU 負載。若要進一步確認的話，則要運行 vmstat 或 mpstat 命令，這兩個命令請參考后面的第 3 和第 4 章節。

2. dmesg | tail

這條命令顯式了最近的 10 條系統消息，如果它們存在的話。查找能夠導致性能問題的錯誤。上面的例子包含了 oom-killer，以及 TCP 丟棄一個請求。

千萬不要錯過這一步！dmesg 命令永遠值得一試。

3. vmstat 1

vmstat(8) 是虛擬內存統計的簡稱，其是一個常用工具（幾十年前為了 BSD 所創建）。其在每行打印一條關鍵的服務器的統計摘要。

vmstat 命令指定一個參數 1 運行，來打印每一秒的統計摘要。（這個版本的 vmstat）輸出的第一行的那些列，顯式的是開機以來的平均值，而不是前一秒的值?，F在，我們跳過第一行，除非你想要了解并記住每一列。

檢查這些列：

r：CPU 中正在運行和等待運行的進程的數量。其提供了一個比平均負載更好的信號來確定 CPU 是否飽和，因為其不包含 I/O。解釋：“r”的值大于了 CPU 的數量就表示已經飽和了。

free：以 kb 為單位顯式的空閑內存。如果數字位數很多，說明你有足夠的空閑內存。“free -m” 命令，是下面的第七個命令，其可以更好的說明空閑內存的狀態。

si, so：Swap-ins 和 swap-outs。如果它們不是零，則代表你的內存不足了。

us, sy, id, wa, st：這些都是平均了所有 CPU 的 CPU 分解時間。它們分別是用戶時間（user）、系統時間（內核）（system）、空閑（idle）、等待 I/O（wait）、以及占用時間（stolen）（被其他訪客，或使用 Xen，訪客自己獨立的驅動域）。

CPU 分解時間將會通過用戶時間加系統時間確認 CPU 是否為忙碌狀態。等待 I/O 的時間一直不變則表明了一個磁盤瓶頸；這就是 CPU 的閑置，因為任務都阻塞在等待掛起磁盤 I/O 上了。你可以把等待 I/O 當成是 CPU 閑置的另一種形式，其給出了為什么 CPU 閑置的一個線索。

對于 I/O 處理來說，系統時間是很重要的。一個高于 20% 的平均系統時間，可以值得進一步的探討：也許內核在處理 I/O 時效率太低了。

在上面的例子中，CPU 時間幾乎完全花在了用戶級，表明應用程序占用了太多 CPU 時間。而 CPU 的平均使用率也在 90% 以上。這不一定是一個問題；檢查一下“r”列中的飽和度。

4. mpstat -P ALL 1

這個命令打印每個 CPU 的 CPU 分解時間，其可用于對一個不均衡的使用情況進行檢查。一個單獨 CPU 很忙碌則代表了正在運行一個單線程的應用程序。

5. pidstat 1

pidstat 命令有點像 top 命令對每個進程的統計摘要，但循環打印一個滾動的統計摘要來代替 top 的刷屏。其可用于實時查看，同時也可將你所看到的東西（復制粘貼）到你的調查記錄中。

上面的例子表明兩個 Java 進程正在消耗 CPU。%CPU 這列是所有 CPU 合計的；1591% 表示這個 Java 進程消耗了將近 16 個 CPU。

這是用于查看塊設備（磁盤）情況的一個很棒的工具，無論是對工作負載還是性能表現來說。查看個列：

r/s, w/s, rkB/s, wkB/s：這些分別代表該設備每秒的讀次數、寫次數、讀取 kb 數，和寫入 kb 數。這些用于描述工作負載。性能問題可能僅僅是由于施加了過大的負載。

await：以毫秒為單位的 I/O 平均消耗時間。這是應用程序消耗的實際時間，因為它包括了排隊時間和處理時間。比預期更大的平均時間可能意味著設備的飽和，或設備出了問題。

avgqu-sz：向設備發出的請求的平均數量。值大于 1 說明已經飽和了（雖說設備可以并行處理請求，尤其是由多個磁盤組成的虛擬設備。）

%util：設備利用率。這個值是一個顯示出該設備在工作時每秒處于忙碌狀態的百分比。若值大于 60％，通常表明性能不佳（可以從 await 中看出），雖然它取決于設備本身。值接近 100% 通常意味著已飽和。

如果該存儲設備是一個面向很多后端磁盤的邏輯磁盤設備，則 100% 利用率可能只是意味著當前正在處理某些 I/O 占用，然而，后端磁盤可能遠未飽和，并且可能能夠處理更多的工作。

請記住，磁盤 I/O 性能較差不一定是程序的問題。許多技術通常是異步 I/O，使應用程序不會被阻塞并遭受延遲（例如，預讀，以及寫緩沖）。

7. free -m

右邊的兩列顯式：

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

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

我們只是想要檢查這些不接近零的大小，其可能會導致更高磁盤 I/O（使用 iostat 確認），和更糟糕的性能。上面的例子看起來還不錯，每一列均有很多 M 個大小。

比起第一行，-/+ buffers/cache 提供的內存使用量會更加準確些。Linux 會把暫時用不上的內存用作緩存，一旦應用需要的時候就立刻重新分配給它。所以部分被用作緩存的內存其實也算是空閑的內存。為了解釋這一點， 甚至有人專門建了個網站： linuxatemyram。

如果你在 Linux 上安裝了 ZFS，這一點會變得更加困惑，因為 ZFS 它自己的文件系統緩存不算入free -m。有時候發現系統已經沒有多少空閑內存可用了，其實內存卻都待在 ZFS 的緩存里。

8. sar -n DEV 1

這個工具可以被用來檢查網絡接口的吞吐量：rxkB/s 和 txkB/s，以及是否達到限額。上面的例子中，eth0 接收的流量達到 22Mbytes/s，也即 176Mbits/sec（限額是 1Gbit/sec）

我們用的版本中還提供了 %ifutil 作為設備使用率（接收和發送的最大值）的指標。我們也可以用 Brendan 的 nicstat 工具計量這個值。一如 nicstat，sar 顯示的這個值是很難精確取得的，在這個例子里面，它就沒在正常的工作（0.00）。

9. sar -n TCP,ETCP 1

這是一些關鍵的 TCP 指標的匯總視圖。這些包括：

active/s：每秒本地發起 TCP 連接數（例如，通過 connect()）。

passive/s：每秒遠程發起的 TCP 連接數（例如，通過 accept()）。

retrans/s：每秒重傳 TCP 次數。

active 和 passive 的連接數往往對于描述一個粗略衡量服務器負載是非常有用的：新接受的連接數（passive），下行連接數（active）?？梢岳斫鉃?active 連接是對外的，而 passive 連接是對內的，雖然嚴格來說并不完全正確（例如，一個 localhost 到 localhost 的連接）。

重傳是出現一個網絡和服務器問題的一個征兆。其可能是由于一個不可靠的網絡（例如，公網）造成的，或許也有可能是由于服務器過載并丟包。上面的例子顯示了每秒只有一個新的 TCP 連接。

10. top

top 命令包含了很多我們之前已經檢查過的指標?？梢苑奖愕膱绦兴鼇聿榭聪啾扔谥暗拿钶敵龅慕Y果有很大不同，這表明負載是可變的。

top 的一個缺點是，很難看到數據隨時間變動的趨勢。vmstat 和 pidstat 提供的滾動輸出會更清楚一些。如果你不以足夠快的速度暫停輸出（Ctrl-S 暫停，Ctrl-Q 繼續），一些間歇性問題的線索也可能由于被清屏而丟失。

后續的分析

還有更多命令和方法可以用于更深入的分析。查看 Brendan 在 Velocity 2015 大會上的 Linux 性能工具教程，其中包含了超過 40 個命令，涵蓋了可觀測性、標桿管理、調優、靜態性能調優、分析，和跟蹤等方面。