當你登錄到一臺存在性能問題的Linux服務器上時，在頭一分鐘，你會檢查什么？

我們看看Netflix的性能工程師是怎么做的。

Netflix大量使用EC2 Linux服務器，很多時候是用一些較為高層的工具做云或實例層次的分析。不過有時仍然需要登錄到某個實例上，運行一些標準的Linux性能工具。

在最開始的一分鐘內，可以先利用手頭的標準Linux工具大致了解性能狀況。借助如下10條命令（有些命令需要安裝sysstat包），了解系統(tǒng)資源使用狀況和正在運行的進程。先檢查錯誤（errors）和飽和度（saturation），再檢查資源利用率（resource utilization）。飽和度指的是負載已經超過處理能力，像請求隊列的長度，等待時間等。

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

這里要提一下定位性能瓶頸的USE方法。在Brendan Gregg的《System Performance: Enterprise and the Cloud》(中譯本：《性能之巔：洞悉系統(tǒng)、企業(yè)與云計算》)一書中有具體的描述。

如果手頭有這本書的中譯本，可以看一下36頁：

USE方法（utilization、utilization、errors）應用于性能研究，用來識別系統(tǒng)瓶頸。一言以蔽之，就是：

對于所有的資源，查看它的使用率、飽和度和錯誤。

這些術語定義如下。

• 資源：所有服務器物理元器件（CPU、總線……）。某些軟件資源也能算在內，提供有用的指標。

• 使用率：在規(guī)定的時間間隔內，資源用于服務工作的時間百分比。雖然資源繁忙，但是資源還有能力接受更多的工作，不能接受更多工作的程度被視為飽和度。

• 飽和度：資源不能再服務更多額外工作的程度，通常有等待隊列。

• 錯誤：錯誤事件的個數(shù)。

……

USE方法會將分析引導到一定數(shù)量的關鍵指標上，這樣可以盡快地核實所有的系統(tǒng)資源。在此之后，如果還沒有找到問題，那么可以考慮采用其他的方法。

下面具體看一下這10條命令。

1. uptime

快速查看平均負載（任務對CPU資源的需求）。輸出中的“l(fā)oad average:”后面的三個數(shù)字，是系統(tǒng)在1分鐘、5分鐘和15分鐘內的平均負載。表示負載隨時間的變化情況。

它給出的只是一個較為高層的情況，往往需要借助其他工具進一步確認性能問題，有時候需要通過其他一些指標來了解CPU負載，例如vmstat或mpstat。

2. dmesg | tail

查看最后10條系統(tǒng)消息。查找可能會引發(fā)性能問題的錯誤。千萬不要漏掉這一步。

3. vmstat 1

統(tǒng)計虛擬內存信息。參數(shù)1指的是打印1秒內的統(tǒng)計信息。

要檢查的列：

• r：運行隊列的長度（這個參數(shù)的解釋，建議參考《性能之巔》一書）?？梢愿玫卮_定CPU的飽和度。“r”值大于CPU數(shù)則為飽和。

• free：以kb為單位的空閑內存。如果這個值很大，說明有足夠的空閑內存。下面將介紹的第7條命令——“free -m”，可以更好地解釋空閑內存的狀態(tài)。

• si, so：換入的內存和換出的內存。如果它們不為0，說明內存已經耗盡。

• us, sy, id, wa, st：CPU時間的不同組成部分，是所有CPU的平均數(shù)。分別表示用戶態(tài)時間、系統(tǒng)態(tài)時間（內核）、空閑、等待I/O以及竊取時間（stolen time，虛擬化環(huán)境下，CPU在其他租戶上的開銷）。

將用戶態(tài)時間和系統(tǒng)態(tài)時間相加，可以判斷CPU是否忙碌。如果一直有等待I/O，表明存在磁盤瓶頸。因為任務阻塞等待磁盤I/O，此時CPU是空閑的?？梢詫⒌却?/span>I/O看作另一種形式的CPU空閑。

I/O處理一定會消耗系統(tǒng)態(tài)時間。如果系統(tǒng)時間平均占比很高，比如說超過20%，或許可以深入研究一下：可能是內核處理I/O的效率不高。

4. mpstat -P ALL 1

打印每個CPU的狀況?？梢詸z查各CPU的負載是否均衡。比如，如果一個CPU很熱，可能是單線程應用造成的。

5. pidstat 1

pidstat按進程打印CPU的使用情況。循環(huán)輸出活動進程的信息?？捎糜谟^察模式隨時間的變化情況。用戶也可以把觀察到的信息記錄下來，以供分析研究。

像圖中的例子，可以看到有2個Java進程消耗了大部分CPU時間?！?span>%CPU”這一列是所有CPU的整體情況，“1591%”這個值表明這2個Java進程幾乎占用了16個CPU。

6. iostat -xz 1

這是了解塊設備的一個極佳工具，能看到實際負載和性能信息。

• r/s, w/s, rkB/s, wkB/s：分別表示每秒發(fā)給磁盤設備的讀請求數(shù)，每秒發(fā)給磁盤設備的寫請求數(shù)，每秒從磁盤設備讀取的KB數(shù)，每秒向磁盤設備寫入的KB數(shù)?？梢允褂盟鼈儽硎矩撦d特性。性能問題可能就是由過多的負載造成的。

• await：平均I/O響應時間，單位為毫秒。包括排隊時間和服務時間。如果它大于預期的平均時間，可能是設備已經飽和，也可能是設備存在問題。

• avgqu-sz：提交到設備的平均請求數(shù)。如果大于1，設備可能已經飽和。

• %util：設備使用率。設備忙于處理請求的百分比。如果大于60%，通常會導致較差的性能（可以在await中看出來），不過也與具體的設備有關。如果接近100%，通常意味著設備已經飽和。

如果存儲設備是后面有多塊磁盤支撐的邏輯磁盤，即使設備使用率是100%，后端磁盤也可能遠沒有飽和，而是還能處理更多工作。

7. free -m

主要看最右邊的兩列：

• buffers：用于塊設備I/O的緩沖區(qū)高速緩存的大小。

• cached：文件系統(tǒng)使用的頁緩存大小。

我們只需要檢查這兩個值，如果它們接近0，則會導致更高的磁盤I/O（可以使用iostat確認），性能更糟。圖中的例子，這個狀況看上去還不錯。

8. sar -n DEV 1

使用該工具檢查網絡接口的吞吐量，以rxkB/s和txkB/s為手段測量負載。

9. sar -n TCP,ETCP 1

這是一些關鍵TCP指標的總結。其中包括：

• active/s：每秒本地發(fā)起的TCP連接數(shù)（比如通過connect()）。

• passive/s：每秒遠端發(fā)起的TCP連接數(shù)（比如通過accept()）。

• retrans/s：每秒TCP重傳數(shù)。

active和passive連接數(shù)通常用于粗略地測量服務器負載。方便起見，可以把active看作向外的連接，把passive看作向內的連接；不過也有不嚴格之處，比如考慮從localhost到localhost的連接。

重傳數(shù)是網絡或服務器問題的一個信號：可能是網絡不可靠；也可能是服務器過載和丟包。像圖中的例子，每秒只有一個新的TCP連接。

10. top

top命令包含很多前面檢查過的指標?？梢杂脗€命令來檢查是不是有指標和之前命令的輸出差距很大。

top命令有個缺點，很難看出某個指標隨時間的變化模式，這種情況下用像vmstat和pidstat這樣的命令可能更清楚，它們能提供滾動輸出。間歇性問題的一些跡象，如果不能足夠快地暫停輸出（Ctrl-S暫停，Ctrl-Q繼續(xù)），可能會錯過。

后續(xù)分析

可以借助更多命令繼續(xù)深入挖掘。重點推薦Brendan Gregg的《性能之巔：洞悉系統(tǒng)、企業(yè)與云計算》)一書。

本文根據(jù)Netflix的技術博客編譯整理，結合自己讀書的一些心得寫就。更多細節(jié)，可以點擊閱讀原文，查看相關博客，或者閱讀《性能之巔》一書。