60,000 毫秒內對 Linux 進行性能診斷
60,000 毫秒內對 Linux 進行性能診斷
當你發現 Linux 服務器上的系統性能問題，在最開始的 1 分鐘時間裏，你會查看哪些系統指標呢?java
Netflix 在 AWS 上有着大規模的 EC2 集羣，以及各類各樣的性能分析和監控工具。好比咱們使用 Atlas 來監控整個平臺，用 Vector 實時分析 EC2 實例的性能。這些工具已經可以幫助咱們解決大部分的問題，可是有時候咱們仍是要登陸進機器內部，用一些標準的 Linux 性能分析工具來定位問題。linux
最開始的 60 秒
在這篇文章裏，Netflix 性能工程團隊會介紹一些咱們使用的標準的 Linux 命令行工具，在發現問題的前 60 秒內去分析和定位問題。在這 60 秒內，你可使用下面這 10 個命令行了解系統總體的運行狀況，以及當前運行的進程對資源的使用狀況。在這些指標裏面，咱們先關注和錯誤、以及和資源飽和率相關的指標，而後再看資源使用率。相對來說，錯誤和資源飽和率比較容易理解。飽和的意思是指一個資源(CPU，內存，磁盤)上的負載超過了它可以處理的能力，這時候咱們觀察到的現象就是請求隊列開始堆積，或者請求等待的時間變長。ios
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，內存，磁盤等等)。在這個分析的過程當中，咱們也要時刻注意咱們已經排除過的資源問題，以便縮小咱們定位的範圍，給下一步的定位提供更明確的方向。docker
下面的章節對每一個命令行作了一個說明，而且使用了咱們在生產環境的數據做爲例子。對這些命令行更詳細的描述，請查看相應的幫助文檔。後端
1. uptime
$ uptime 23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
這個命令能很快地檢查系統平均負載，你能夠認爲這個負載的值顯示的是有多少任務在等待運行。在 Linux 系統裏，這包含了想要或者正在使用 CPU 的任務，以及在 io 上被阻塞的任務。這個命令能使咱們對系統的全局狀態有一個大體的瞭解，可是咱們依然須要使用其它工具獲取更多的信息。緩存
這三個值是系統計算的 1 分鐘、5 分鐘、15 分鐘的指數加權的動態平均值，能夠簡單地認爲就是這個時間段內的平均值。根據這三個值，咱們能夠了解系統負載隨時間的變化。好比，假設如今系統出了問題，你去查看這三個值，發現 1 分鐘的負載值比 15 分鐘的負載值要小不少，那麼你頗有可能已經錯過了系統出問題的時間點。服務器
在上面這個例子裏面，負載的平均值顯示 1 分鐘爲 30，比 15 分鐘的 19 相比增加較多。有不少緣由會致使負載的增長，也許是 CPU 不夠用了;vmstat 或者 mpstat 能夠進一步確認問題在哪裏。網絡
2. 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 count
這個命令顯示了最新的幾條系統日誌。這裏咱們主要找一下有沒有一些系統錯誤會致使性能的問題。上面的例子包含了 oom-killer 以及 TCP 丟包。異步
不要略過這一步!dmesg 永遠值得看一看。ide
3. 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 展現了虛擬內存、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 的飽和度。
4. 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 對任務的處理是否均勻。好比，若是某一單個 CPU 使用率很高的話，說明這是一個單線程應用。
5. 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 和 top 很像，不一樣的是它能夠每隔一個間隔打印一次，而不是像 top 那樣每次都清屏。這個命令能夠方便地查看進程可能存在的行爲模式，你也能夠直接 copy past，能夠方便地記錄隨着時間的變化，各個進程運行情況的變化。
上面的例子說明有 2 個 Java 進程消耗了大量 CPU。這裏的 %CPU 代表的是對全部 CPU 的值，好比 1591% 標識這個 Java 進程幾乎消耗了 16 個 CPU。
6. 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
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 延遲對自身的影響。
7. free -m
$ 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 會把暫時用不上的內存用做緩存，一旦應用須要的時候就馬上從新分配給它。因此部分被用做緩存的內存其實也算是空閒的內存。爲了解釋這一點， 甚至有人專門建了個網站： http://www.linuxatemyram.com/。
若是使用 ZFS 的話，可能會有點困惑。ZFS 有本身的文件系統緩存，在 free -m 裏面看不到;系統看起來空閒內存很少了，可是有可能 ZFS 有不少的緩存可用。
8. 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 ^C
這個工具能夠查看網絡接口的吞吐量：rxkB/s 和 txkB/s 能夠測量負載，也能夠看是否達到網絡流量限制了。在上面的例子裏，eth0 的吞吐量達到了大約 22 Mbytes/s，差很少 176 Mbits/sec ，比 1 Gbit/sec 還要少不少。
這個例子裏也有 %ifutil 標識設備利用率，咱們也用 Brenan 的 nicstat tool 測量。和 nicstat 同樣，這個設備利用率很難測量正確，上面的例子裏好像這個值還有點問題。
9. sar -n TCP,ETCP 1
$ 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 個新鏈接創建。
10. top
$ 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 6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0 8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
top 命令涵蓋了咱們前面講述的許多指標。咱們能夠用它來看和咱們以前查看的結果有沒有很大的不一樣，若是有的話，那表示系統的負載在變化。
top 的缺點就是你很難找到這些指標隨着時間的一些行爲模式，在這種狀況下，vmstat 或者 pidstat 這種能夠提供滾動輸出的命令是更好的方式。若是你不以足夠快的速度暫停輸出(Ctrl-S 暫停，Ctrl-Q 繼續)，一些間歇性問題的線索也可能因爲被清屏而丟失。
- 1. 60,000 毫秒內對 Linux 進行性能診斷
- 2. 60,000毫秒內對Linux的性能診斷效的方法
- 3. linux性能診斷-perf
- 4. Linux性能分析的前60000毫秒
- 5. linux和性能相關的命令及系統性能診斷
- 6. linux毫秒
- 7. C# http 性能優化500毫秒到 60 毫秒
- 8. Linux內存、性能診斷中vmstat命令的詳解
- 9. DB性能診斷優化
- 10. java性能診斷工具
- 更多相關文章...
- • 基於ARP協議進行掃描 - TCP/IP教程
- • traceroute命令進行路由跟蹤 - TCP/IP教程
- • JDK13 GA發佈：5大特性解讀
- • 爲了進字節跳動，我精選了29道Java經典算法題，帶詳細講解
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. js中 charCodeAt
- 2. Android中通過ViewHelper.setTranslationY實現View移動控制（NineOldAndroids開源項目）
- 3. 【Android】日常記錄：BottomNavigationView自定義樣式，修改點擊後圖片
- 4. maya 文件檢查 ui和數據分離 （一）
- 5. eclipse 修改項目的jdk版本
- 6. Android InputMethod設置
- 7. Simulink中Bus Selector出現很多? ? ?
- 8. 【Openfire筆記】啓動Mac版Openfire時提示「系統偏好設置錯誤」
- 9. AutoPLP在偏好標籤中的生產與應用
- 10. 數據庫關閉的四種方式