如何快速分析出現效能問題的Linux伺服器

Brendan Gregg曾經分享過當遇到一個系統效能問題時，如何利用登入的前60秒對系統的效能情況做一個快速探索和分析，主要包括如下10個工具，這是一個非常有用且有效工具列表。本文將詳細介紹這些命令及其擴充選項的意義，及其在實踐中的作用。並利用一個實際出現問題的例子，來驗證這些套路是不是可行，下面工具的螢幕輸出結果都來自這個出現問題的系統。

# 系統負載概覽
uptime

# 系統日誌
dmesg | tail

# CPU
vmstat 1
mpstat -P ALL 1
pidstat 1

# Disk
iostat -xz 1

# 記憶體
free -m

# 網路
sar -n DEV 1
sar -n TCP,ETCP 1

# 系統概覽
top

上面的工具都基於核心提供給使用者態的統計，並以計數器形式展示，是快速排查時的利器。對於應用和系統的進一步跟蹤(tracing)，則需要利用strace和systemtap等工具，不在本文的範疇。

 

注意：

• 如上基於CPU, 記憶體，I/O，網路等的分類只是基於工具預設選項的分類，比如pidstat，預設展示進程的CPU統計，但是利用-d參數可以展示進程的I/O統計。又比如vmstat，雖然名稱是查看虛擬記憶體的工具，但預設展示了負載，記憶體，I/O，系統，CPU等多方面的資訊。
• 部分工具需要安裝sysstat包。

 

1. uptime

[root@nginx1 ~]# uptime 15:38:10 up 43 days,  3:54,  1 user,  load average: 1.13, 0.41, 0.18

uptime是快速查看load average的方法，在Linux中load average包括處於runnable和uninterruptable狀態的進程總數，runnable狀態包括在CPU上啟動並執行進程和在run queue裡waiting for run time等待CPU的進程；uninterruptable狀態的進程是在等待一些I/O訪問，比如等待disk的返回。Load average沒有根據系統的CPU數量做格式化，所以load average 1表示單CPU系統在對應時間段內(1分鐘, 5分鐘, 15分鐘)一直負載飽和，而在4 CPU的系統中，load average 1表示有75%的時間在idle。

 

Load average體現了一個high level的負載概覽，但是可能需要和別的工具一起來使用以瞭解更多資訊，比如處於runable和uninterruptable的即時進程數量分別是多少，可以用下面將介紹到的vmstat來查看。1分鐘，5分鐘，15分鐘的負載平均值同時能體現系統負載的變化情況。例如，如果你要檢查一個問題伺服器，當你看到1分鐘的平均負載值已經遠小於15分鐘的平均負載值，則意味這也許你登入晚了點，錯過了現場。用top或者w命令，也可以看到load average資訊。

 

上面樣本中最近1分鐘內的負載比15分鐘內的負載高了不少 (因為是個測試的例子，1.13可以看作明顯大於0.18，但是在生產系統上這不能說明什麼)。

 

2. dmesg | tail

[root@nginx1 ~]# dmesg | tail[3128052.929139] device eth0 left promiscuous mode[3128104.794514] device eth0 entered promiscuous mode[3128526.750271] device eth0 left promiscuous mode[3537292.096991] device eth0 entered promiscuous mode[3537295.941952] device eth0 left promiscuous mode[3537306.450497] device eth0 entered promiscuous mode[3537307.884028] device eth0 left promiscuous mode[3668025.020351] bash (8290): drop_caches: 1[3674191.126305] bash (8290): drop_caches: 2[3675304.139734] bash (8290): drop_caches: 1

dmesg用於查看核心緩衝區存放的系統資訊。另外查看/var/log/messages也可能查看出伺服器系統方面的某些問題。

 

上面樣本中的dmesg沒有特別的值得注意的錯誤。

 

3. vmstat 1 

vmstat簡介：

• vmstat是virtual memory stat的簡寫，能夠列印processes, memory, paging, block IO, traps, disks and cpu的相關資訊。
• vmstat的格式：vmstat [options] [delay [count]]。在輸入中的1是延遲。第一行列印的是機器啟動到現在的平均值，後面列印的則是根據deley間隔的取樣結果，也就是即時的結果。

 

結果中列的含義：

Procs(進程)

r: The number of runnable processes (running or waiting for run time).
b: The number of processes in uninterruptible sleep.

注釋：r表示在CPU上啟動並執行進程和ready等待啟動並執行進程總數，相比load average, 這個值更能判斷CPU是否飽和(saturation)，因為它沒有包括I/O。如果r的值大於CPU數目，即達到飽和。

Memory

swpd: the amount of virtual memory used.
free: the amount of idle memory.
buff: the amount of memory used as buffers.
cache: the amount of memory used as cache.

Swap

si: Amount of memory swapped in from disk (/s).
so: Amount of memory swapped to disk (/s).

注釋：swap-in和swap-out的記憶體。如果是非零，說明主存中的記憶體耗盡。

IO

bi: Blocks received from a block device (blocks/s).
bo: Blocks sent to a block device (blocks/s).

System (中斷和進程環境切換)

in: The number of interrupts per second, including the clock.
cs: The number of context switches per second.

CPU

These are percentages of total CPU time.
us: Time spent running non-kernel code. (user time, including nice time)
sy: Time spent running kernel code. (system time)
id: Time spent idle. Prior to Linux 2.5.41, this includes IO-wait time.
wa: Time spent waiting for IO. Prior to Linux 2.5.41, included in idle.
st: Time stolen from a virtual machine. Prior to Linux 2.6.11, unknown.

 

根據user+system時間，可以判斷CPUs是否繁忙。如果wait I/O一直維持一定程度，說明disk有瓶頸，這時CPUs是"idle"的，因為任務都被block在等待disk I/O中。wait I/O可以被視為另一種形式的CPU idle，並且說明idle的原因就是在等待disk I/O的完成。

 

處理I/O需要花費system time，在將I/O提交到disk driver之前可能要經過remap, split和merge等操作，並被I/O scheduler調度到request queue。如果處理I/O時平均system time比較高，超過20%，則要進一步分析下，是不是核心處理I/O時的效率有問題。

 

如果使用者空間的CPU使用率接近100%，不一定就代表有問題，可以結合r列的進程總數量看下CPU的飽和程度。 

 

上面樣本可以看到在CPU方面有一個明顯的問題。user+system的CPU一直維持在50%左右，並且system消耗了大部分的CPU。

 

4. mpstat -P ALL 1

 mpstat可以列印按照CPU的分解，可以用來檢查不不均衡的情況。

 

上面樣本結果可以印證vmstat中觀察到的結論，並且可以看到伺服器有2個CPU，其中CPU 1的使用率一直維持在100%，而CPU 0並沒有什麼負載。CPU 1的消耗主要在核心空間，而非使用者空間。

 

5. pidstat 1

預設pidstat類似於top按照進程的列印方式，不過是以滾動列印的方式，和top的清屏方式不同。利用-p可以打出指定進程的資訊，-p ALL可以打出所有進程的資訊。如果沒有指定任何進程預設相當於-p ALL，但是只列印活動進程的資訊(統計非0的資料)。

 

pidstat不只可以列印進程的CPU資訊，還可以列印記憶體，I/O等方面的資訊，如下是比較有用的資訊：

• pidstat -d 1：看哪些進程有讀寫。
• pidstat -r 1：看進程的page fault和記憶體使用量。沒有發生page fault的進程預設不會被列印出來，可以指定-p和進程號來列印查看記憶體。
• pidstat -t： 利用-t查看線程資訊，可以快速查看線程和期相關線程的關係。
• pidstat -w：利用-w查看進程的context switch情況。輸出：
  • cswch/s: 每秒發生的voluntary context switch數目 (voluntary cs：當進程被block在擷取不到的資源時，主動發生的context switch)
  • nvcswch/s: 每秒發生的non voluntary context switch數目 (non vloluntary cs：進程執行一段時間用完了CPU分配的time slice，被強制從CPU上調度下來，這時發生的context switch)

 

上面樣本中可以明確得看到是nc這個進程在消耗CPU 1 100%的CPU。因為測試系統裡消耗CPU的進程比較少，所以一目瞭然，在生產系統中pidstat應該能輸出更多正在消耗CPU的進程情況。

 

6. iostat -zx 1

瞭解塊裝置(block device, 這裡是disk)負載和效能的工具。主要看如下指標：

• r/s, w/s, rkB/s, wkB/s：每秒完成的讀請求次數(read requests, after merges)，每秒完成的寫請求次數(write requests completed, after merges)，每秒讀取的KB數，每秒寫入的KB數。這些指標可以看出disk的負載情況。一個效能問題可能僅僅是因為disk的負載過大。
• await：每個I/O平均所需的時間，單位為毫秒。await不僅包括硬碟裝置處理I/O的時間，還包括了在kernel隊列中等待的時間。要精確地知道塊裝置service一個I/O請求地時間，可供iostat讀取地核心統計並沒有體現，需要用如blktrace這樣地跟蹤工具來跟蹤。對於blktrace來說，D2C的時間間隔代表硬體塊裝置地service time，Q2C代表整個I/O請求所消耗的時間，即iostat的await。
• avgqu-sz：隊列裡的平均I/O請求數量 (更恰當的理解應該是平均未完成的I/O請求數量）。如果該值大於1，則有飽和的趨勢 (當然裝置可以並發地處理請求，特別是一個front對多個backend disk的虛擬設備)。
• %util：裝置在處理I/O的時間佔總時間的百分比。表示該裝置有I/O（即非空閑）的時間比率，不考慮I/O有多少，只考慮有沒有。通常該指標達到60%即可能引起效能問題 (可以根據await指標進一步求證)。如果指標接近100%，通常就說明出現了飽和。

 

如果存放裝置是一個對應多個後端磁碟的邏輯磁碟，那麼100%使用率可能僅僅表示一些I/O在處理時間佔比達到100%，其他後端磁碟不一定也到達了飽和。請注意磁碟I/O的效能問題並不一定會造成應用的問題，很多技術都是使用非同步I/O操作，所以應用不一定會被block或者直接受到延遲的影響。

 

7. free -m

# free -mtotal used free shared buff/cache availableMem: 7822 129 214 0 7478 7371Swap: 0 0 0

查看記憶體使用量情況。倒數第二列：

• buffers: buffer cache，用於block device I/O。
• cached: page cache, 用於檔案系統。

Linux用free memory來做cache, 當應用需要時，這些cache可以被回收。比如kswapd核心進程做頁面回收時可能回收cache；另外手動寫/proc/sys/vm/drop_caches也會導致cache回收。

 

上面樣本中free的記憶體只有129M，大部分memory被cache佔用。但是系統並沒有問題。

 

8. sar -n DEV 1

輸出指標的含義如下：

• rxpck/s: Total number of packets received per second.
• txpck/s: Total number of packets transmitted per second.
• rxkB/s: Total number of kilobytes received per second.
• txkB/s: Total number of kilobytes transmitted per second.
• rxcmp/s: Number of compressed packets received per second (for cslip etc.).
• txcmp/s: Number of compressed packets transmitted per second.
• rxmcst/s: Number of multicast packets received per second.
• %ifutil: Utilization percentage of the network interface. For half-duplex interfaces, utilization is calculated using the sum of rxkB/s and txkB/s as a percentage of the interface speed.
• For full-duplex, this is the greater of rxkB/S or txkB/s.

這個工具可以查看網路介面的輸送量，特別是上面藍色高亮的rxkB/s和txkB/s，這是網路負載，也可以看是否達到了limit。

 

9. sar -n TCP,ETCP 1

輸出指標的含義如下：

• active/s: The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state per second [tcpActiveOpens].
• passive/s: The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state per second [tcpPassiveOpens].
• iseg/s: The total number of segments received per second, including those received in error [tcpInSegs]. This count includes segments received on currently established connections.
• oseg/s: The total number of segments sent per second, including those on current connections but excluding those containing only retransmitted octets [tcpOutSegs].
• atmptf/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times per second TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state [tcpAttemptFails].
• estres/s: The number of times per second TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state [tcpEstabResets].
• retrans/s: The total number of segments retransmitted per second - that is, the number of TCP segments transmitted containing one or more previously transmitted octets [tcpRetransSegs].
• isegerr/s: The total number of segments received in error (e.g., bad TCP checksums) per second [tcpInErrs].
• orsts/s: The number of TCP segments sent per second containing the RST flag [tcpOutRsts].

 

上述藍色高亮的3個指標：active/s, passive/s和retrans/s是比較有代表性的指標。

• active/s和passive/s分別是本地發起的每秒建立TCP串連數和遠程發起的TCP建立串連數。這兩個指標可以粗略地判斷伺服器的負載。可以用active衡量出站發向，用passive衡量入站方向，但也不是完全準確(比如，考慮localhost到localhost的串連)。
• retrans是網路或者伺服器發生問題的象徵。有可能問題是網路不穩定，比如Internet網路問題，或者伺服器過載丟包。

 

10. top

# top
Tasks:  79 total,   2 running,  77 sleeping,   0 stopped,   0 zombie%Cpu(s):  6.0 us, 44.1 sy,  0.0 ni, 49.6 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 stKiB Mem :  8010456 total,  7326348 free,   132296 used,   551812 buff/cacheKiB Swap:        0 total,        0 free,        0 used.  7625940 avail Mem  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 4617 root      20   0   44064   2076   1544 R 100.0  0.0  16:27.23 nc13634 nginx     20   0  121192   3864   1208 S   0.3  0.0  17:59.85 nginx    1 root      20   0  125372   3740   2428 S   0.0  0.0   6:11.53 systemd    2 root      20   0       0      0      0 S   0.0  0.0   0:00.60 kthreadd    3 root      20   0       0      0      0 S   0.0  0.0   0:17.92 ksoftirqd/0    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H    7 root      rt   0       0      0      0 S   0.0  0.0   0:03.21 migration/0    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh    9 root      20   0       0      0      0 S   0.0  0.0  31:47.62 rcu_sched   10 root      rt   0       0      0      0 S   0.0  0.0   0:10.00 watchdog/0

top是一個常用的命令，包括了多方面的指標。缺點是沒有滾動輸出(rolling output)，不可複現問題發生時不容易保留資訊。對於資訊保留，用vmstat或者pidstat等能夠提供滾動輸出的工具會更好。

 

樣本的問題？

在上面利用工具排查的過程中，我們可以在非常短的時間內快速得到如下結論：

• 2個CPU，nc這個進程消耗了CPU 1 100%的時間，並且時間消耗在system核心態。其他進程基本沒有在消耗CPU。
• 記憶體free比較少，大部分在cache中 (並不是問題)。
• Disk I/O非常低，平均讀寫請求小於1個。
• 收到報文在個位元KB/s層級，每秒有15個被動建立的TCP串連，沒有明顯異常。

整個排查過程把系統的問題定位到了進程層級，並且排除一些可能性 (Disk I/O和記憶體)。接下來就是進一步到進程層級的排查，不屬於本文的覆蓋範圍，有時間再進一步示範。

 

參考

1. Linux Performance Analysis in 60,000 Milliseconds
2. Linux Performance Analysis in 60s (video)