如何在 60 秒內去分析和定位問題？

導讀	在這篇文章裡，Netflix 效能工程團隊會介紹一些我們使用的標準的    行工具，在發現問題的前 60 秒內去分析和定位問題。

當你發現 Linux 伺服器上的系統效能問題，在最開始的 1 分鐘時間裡，你會檢視哪些系統指標呢?

Netflix 在 AWS 上有著大規模的 EC2 叢集，以及各種各樣的效能分析和監控工具。比如我們使用 Atlas 來監控整個平臺，用 Vector 實時分析 EC2 例項的效能。這些工具已經能夠幫助我們解決大部分的問題，但是有時候我們還是要登入進機器內部，用一些標準的 Linux 效能分析工具來定位問題。

在這些指標裡面，我們先關注和錯誤、以及和資源飽和率相關的指標，然後再看資源使用率。相對來講，錯誤和資源飽和率比較容易理解。飽和的意思是指一個資源(CPU，記憶體，磁碟)上的負載超過了它能夠處理的能力，這時候我們觀察到的現象就是請求佇列開始堆積，或者請求等待的時間變長。

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）、資源飽和度（Satuation）、錯誤（Error），這三個方面對所有的資源進行分析（CPU，記憶體，磁碟等等）。

在這個分析的過程中，我們也要時刻注意我們已經排除過的資源問題，以便縮小我們定位的範圍，給下一步的定位提供更明確的方向。

下面的章節對每個命令列做了一個說明，並且使用了我們在生產環境的資料作為例子。對這些命令列更詳細的描述，請檢視相應的幫助文件。

$ uptime

這個命令能很快地檢查系統平均負載，你可以認為這個負載的值顯示的是有多少任務在等待執行。在 Linux 系統裡，這包含了想要或者正在使用 CPU 的任務，以及在 io 上被阻塞的任務。這個命令能使我們對系統的全域性狀態有一個大致的瞭解，但是我們依然需要使用其它工具獲取更多的資訊。

這三個值是系統計算的 1 分鐘、5 分鐘、15 分鐘的指數加權的動態平均值，可以簡單地認為就是這個時間段內的平均值。根據這三個值，我們可以瞭解系統負載隨時間的變化。比如，假設現在系統出了問題，你去檢視這三個值，發現 1 分鐘的負載值比 15 分鐘的負載值要小很多，那麼你很有可能已經錯過了系統出問題的時間點。

在上面這個例子裡面，負載的平均值顯示 1 分鐘為 30，比 15 分鐘的 19 相比增長較多。有很多原因會導致負載的增加，也許是 CPU 不夠用了;vmstat 或者 mpstat 可以進一步確認問題在哪裡。

$ 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 count

這個命令顯示了最新的幾條系統日誌。這裡我們主要找一下有沒有一些系統錯誤會導致效能的問題。上面的例子包含了 oom-killer 以及 TCP 丟包。

不要略過這一步!dmesg 永遠值得看一看。

$ 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 展示了虛擬記憶體、CPU 的一些情況。上面這個例子裡命令列的 1 表示每隔 1 秒鐘顯示一次。在這個版本的 vmstat 裡，第一行表示了這一次啟動以來的各項指標，我們可以暫時忽略掉第一行。

需要檢視的指標：

• r ： 處在 runnable 狀態的任務，包括正在執行的任務和等待執行的任務。這個值比平均負載能更好地看出 CPU 是否飽和。這個值不包含等待 io 相關的任務。當 r 的值比當前 CPU 個數要大的時候，系統就處於飽和狀態了。
• free ： 以 KB 計算的空閒記憶體大小。
• si，so ： 換入換出的記憶體頁。如果這兩個值非零，表示記憶體不夠了。
• us，sy，id，wa，st ： CPU 時間的各項指標（對所有 CPU 取均值），分別表示：使用者態時間，核心態時間，空閒時間，等待 io，偷取時間（在虛擬化環境下系統在其它租戶上的開銷）

把使用者態 CPU 時間（us）和核心態 CPU 時間（sy）加起來，我們可以進一步確認 CPU 是否繁忙。等待 IO 的時間（wa）高的話，表示磁碟是瓶頸；注意，這個也被包含在空閒時間裡面(id)， CPU 這個時候也是空閒的，任務此時阻塞在磁碟 IO 上了。你可以把等待 IO 的時間(wa)看做另一種形式的 CPU 空閒，它可以告訴你 CPU 為什麼是空閒的。

系統處理 IO 的時候，肯定是會消耗核心態時間(sy)的。如果核心態時間較多的話，比如超過 20%，我們需要進一步分析，也許核心對 IO 的處理效率不高。

在上面這個例子裡，CPU 時間大部分都消耗在了使用者態，表明主要是應用層的程式碼在使用 CPU。CPU 利用率（us + sy）也超過了 90%，這不一定是一個問題;我們可以透過 r 和 CPU 個數確定 CPU 的飽和度。

$ 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 對任務的處理是否均勻。比如，如果某一單個 CPU 使用率很高的話，說明這是一個單執行緒應用。

$ 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 很像，不同的是它可以每隔一個間隔列印一次，而不是像 top 那樣每次都清屏。這個命令可以方便地檢視程式可能存在的行為模式，你也可以直接 copy past，可以方便地記錄隨著時間的變化，各個程式執行狀況的變化。

上面的例子說明有 2 個 Java 程式消耗了大量 CPU。這裡的 %CPU 表明的是對所有 CPU 的值，比如 1591% 標識這個 Java 程式幾乎消耗了 16 個 CPU。

$ 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

iostat 是理解塊裝置(磁碟)的當前負載和效能的重要工具。幾個指標的含義：

• r/s，w/s，rkB/s，wkB/s ： 系統發往裝置的每秒的讀次數、每秒寫次數、每秒讀的資料量、每秒寫的資料量。這幾個指標反映的是系統的工作負載。系統的效能問題很有可能就是負載太大。
• await ： 系統發往 IO 裝置的請求的平均響應時間。這包括請求排隊的時間，以及請求處理的時間。超過經驗值的平均響應時間表明裝置處於飽和狀態，或者裝置有問題。
• avgqu-sz ： 裝置請求佇列的平均長度。佇列長度大於 1 表示裝置處於飽和狀態。
• %util ： 裝置利用率。裝置繁忙的程度，表示每一秒之內，裝置處理 IO 的時間佔比。大於 60% 的利用率通常會導致效能問題(可以透過 await 看到)，但是每種裝置也會有所不同。接近 100% 的利用率表明磁碟處於飽和狀態。

如果這個塊裝置是一個邏輯塊裝置，這個邏輯快裝置後面有很多物理的磁碟的話，100% 利用率只能表明有些 IO 的處理時間達到了 100%;後端的物理磁碟可能遠遠沒有達到飽和狀態，可以處理更多的負載。

還有一點需要注意的是，較差的磁碟 IO 效能並不一定意味著應用程式會有問題。應用程式可以有許多方法執行非同步 IO，而不會阻塞在 IO 上面;應用程式也可以使用諸如預讀取，寫緩衝等技術降低 IO 延遲對自身的影響。

$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap:

右邊的兩列顯式：

• buffers： 用於塊裝置 I/O 的緩衝區快取。
• cached： 用於檔案系統的頁面快取。

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

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

如果使用 ZFS 的話，可能會有點困惑。ZFS 有自己的檔案系統快取，在 free -m 裡面看不到;系統看起來空閒記憶體不多了，但是有可能 ZFS 有很多的快取可用。

$ 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

這個工具可以檢視網路介面的吞吐量：rxkB/s 和 txkB/s 可以測量負載，也可以看是否達到網路流量限制了。在上面的例子裡，eth0 的吞吐量達到了大約 22 Mbytes/s，差不多 176 Mbits/sec ，比 1 Gbit/sec 還要少很多。

這個例子裡也有 %ifutil 標識裝置利用率，我們也用 Brenan 的 nicstat tool 測量。和 nicstat 一樣，這個裝置利用率很難測量正確，上面的例子裡好像這個值還有點問題。

$ 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 重要指標的一些概括，包括：

• active/s ： 每秒鐘本地主動開啟的 TCP 連線，也就是本地程式使用 connect() 系統呼叫
• passive/s ： 每秒鐘從源端發起的 TCP 連線，也就是本地程式使用 accept() 所接受的連線
• retrans/s ： 每秒鐘的 TCP 重傳次數
• atctive 和 passive 的數目通常可以用來衡量伺服器的負載： 接受連線的個數(passive)，下游連線的個數(active)。可以簡單認為 active 為出主機的連線，passive 為入主機的連線；但這個不是很嚴格的說法，比如 loalhost 和 localhost 之間的連線。

重傳表示網路或者伺服器的問題。也許是網路不穩定了，也許是伺服器負載過重開始丟包了。上面這個例子表示每秒只有 1 個新連線建立。

$ 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

top 命令涵蓋了我們前面講述的許多指標。我們可以用它來看和我們之前檢視的結果有沒有很大的不同，如果有的話，那表示系統的負載在變化。

top 的缺點就是你很難找到這些指標隨著時間的一些行為模式，在這種情況下，vmstat 或者 pidstat 這種可以提供滾動輸出的命令是更好的方式。如果你不以足夠快的速度暫停輸出(Ctrl-S 暫停，Ctrl-Q 繼續)，一些間歇性問題的線索也可能由於被清屏而丟失。

原文來自：