如何快速排查Linux伺服器效能問題
“如果你的Linux伺服器突然負載暴增,告警簡訊快發爆你的手機,如何在最短時間內找出Linux效能問題所在?來看Netflix效能工程團隊的這篇博文,看它們透過十條命令在一分鐘內對機器效能問題進行診斷。
概述
“透過執行以下命令,可以在1分鐘內對系統資源使用情況有個大致的瞭解。
- 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包,有一些由procps包提供。這些命令的輸出,有助於快速定位效能瓶頸,檢查出所有資源(CPU、記憶體、磁碟IO等)的利用率(utilization)、飽和度(saturation)和錯誤(error)度量,也就是所謂的USE方法。
“下面我們來逐一介紹下這些命令,有關這些命令更多的引數和說明,請參照命令的手冊。
uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
“這個命令可以快速檢視機器的負載情況。在Linux系統中,這些資料表示等待CPU資源的程式和阻塞在不可中斷IO程式(程式狀態為D)的數量。這些資料可以讓我們對系統資源使用有一個宏觀的瞭解。
“命令的輸出分別表示1分鐘、5分鐘、15分鐘的平均負載情況。透過這三個資料,可以瞭解伺服器負載是在趨於緊張還是區域緩解。如果1分鐘平均負載很高,而15分鐘平均負載很低,說明伺服器正在命令高負載情況,需要進一步排查CPU資源都消耗在了哪裡。反之,如果15分鐘平均負載很高,1分鐘平均負載較低,則有可能是CPU資源緊張時刻已經過去。
“上面例子中的輸出,可以看見最近1分鐘的平均負載非常高,且遠高於最近15分鐘負載,因此我們需要繼續排查當前系統中有什麼程式消耗了大量的資源。可以透過下文將會介紹的vmstat、mpstat等命令進一步排查。
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 counters.
“該命令會輸出系統日誌的最後10行。示例中的輸出,可以看見一次核心的oom kill和一次TCP丟包。這些日誌可以幫助排查效能問題。千萬不要忘了這一步。
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
“vmstat(8) 命令,每行會輸出一些系統核心指標,這些指標可以讓我們更詳細的瞭解系統狀態。後面跟的引數1,表示每秒輸出一次統計資訊,表頭提示了每一列的含義,這幾介紹一些和效能調優相關的列:
- r:等待在CPU資源的程式數。這個資料比平均負載更加能夠體現CPU負載情況,資料中不包含等待IO的程式。如果這個數值大於機器CPU核數,那麼機器的CPU資源已經飽和。
- free:系統可用記憶體數(以千位元組為單位),如果剩餘記憶體不足,也會導致系統效能問題。下文介紹到的free命令,可以更詳細的瞭解系統記憶體的使用情況。
- si, so:交換區寫入和讀取的數量。如果這個資料不為0,說明系統已經在使用交換區(swap),機器實體記憶體已經不足。
- us, sy, id, wa, st:這些都代表了CPU時間的消耗,它們分別表示使用者時間(user)、系統(核心)時間(sys)、空閒時間(idle)、IO等待時間(wait)和被偷走的時間(stolen,一般被其他虛擬機器消耗)。
“上述這些CPU時間,可以讓我們很快了解CPU是否出於繁忙狀態。一般情況下,如果使用者時間和系統時間相加非常大,CPU出於忙於執行指令。如果IO等待時間很長,那麼系統的瓶頸可能在磁碟IO。
“示例命令的輸出可以看見,大量CPU時間消耗在使用者態,也就是使用者應用程式消耗了CPU時間。這不一定是效能問題,需要結合r佇列,一起分析。
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佔用率特別高,那麼有可能是一個單執行緒應用程式引起的。
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 java07: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
“pidstat命令輸出程式的CPU佔用率,該命令會持續輸出,並且不會覆蓋之前的資料,可以方便觀察系統動態。如上的輸出,可以看見兩個JAVA程式佔用了將近1600%的CPU時間,既消耗了大約16個CPU核心的運算資源。
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 5.62 1.78 0.03
[...]
“iostat命令主要用於檢視機器磁碟IO情況。該命令輸出的列,主要含義是:
- r/s, w/s, rkB/s, wkB/s:分別表示每秒讀寫次數和每秒讀寫資料量(千位元組)。讀寫量過大,可能會引起效能問題。
- await:IO操作的平均等待時間,單位是毫秒。這是應用程式在和磁碟互動時,需要消耗的時間,包括IO等待和實際操作的耗時。如果這個數值過大,可能是硬體裝置遇到了瓶頸或者出現故障。
- avgqu-sz:向裝置發出的請求平均數量。如果這個數值大於1,可能是硬體裝置已經飽和(部分前端硬體裝置支援並行寫入)。
- %util:裝置利用率。這個數值表示裝置的繁忙程度,經驗值是如果超過60,可能會影響IO效能(可以參照IO操作平均等待時間)。如果到達100%,說明硬體裝置已經飽和。
“如果顯示的是邏輯裝置的資料,那麼裝置利用率不代表後端實際的硬體裝置已經飽和。值得注意的是,即使IO效能不理想,也不一定意味這應用程式效能會不好,可以利用諸如預讀取、寫快取等策略提升應用效能。
free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
“free命令可以檢視系統記憶體的使用情況,-m參數列示按照兆位元組展示。最後兩列分別表示用於IO快取的記憶體數,和用於檔案系統頁快取的記憶體數。需要注意的是,第二行-/+ buffers/cache,看上去快取佔用了大量記憶體空間。這是Linux系統的記憶體使用策略,儘可能的利用記憶體,如果應用程式需要記憶體,這部分記憶體會立即被回收並分配給應用程式。因此,這部分記憶體一般也被當成是可用記憶體。
“如果可用記憶體非常少,系統可能會動用交換區(如果配置了的話),這樣會增加IO開銷(可以在iostat命令中提現),降低系統效能。
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
“sar命令在這裡可以檢視網路裝置的吞吐率。在排查效能問題時,可以透過網路裝置的吞吐量,判斷網路裝置是否已經飽和。如示例輸出中,eth0網路卡裝置,吞吐率大概在22 Mbytes/s,既176 Mbits/sec,沒有達到1Gbit/sec的硬體上限。
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
“sar命令在這裡用於檢視TCP連線狀態,其中包括:
- active/s:每秒本地發起的TCP連線數,既透過connect呼叫建立的TCP連線;
- passive/s:每秒遠端發起的TCP連線數,即透過accept呼叫建立的TCP連線;
- retrans/s:每秒TCP重傳數量;
“TCP連線數可以用來判斷效能問題是否由於建立了過多的連線,進一步可以判斷是主動發起的連線,還是被動接受的連線。TCP重傳可能是因為網路環境惡劣,或者伺服器壓力過大導致丟包。
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命令包含了前面好幾個命令的檢查的內容。比如系統負載情況(uptime)、系統記憶體使用情況(free)、系統CPU使用情況(vmstat)等。因此透過這個命令,可以相對全面的檢視系統負載的來源。同時,top命令支援排序,可以按照不同的列排序,方便查詢出諸如記憶體佔用最多的程式、CPU佔用率最高的程式等。
“但是,top命令相對於前面一些命令,輸出是一個瞬間值,如果不持續盯著,可能會錯過一些線索。這時可能需要暫停top命令重新整理,來記錄和比對資料。
總結
“排查Linux伺服器效能問題還有很多工具,上面介紹的一些命令,可以幫助我們快速的定位問題。例如前面的示例輸出,多個證據證明有JAVA程式佔用了大量CPU資源,之後的效能調優就可以針對應用程式進行。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70023145/viewspace-2920036/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 無水乾貨-如何快速分析Linux伺服器的效能問題Linux伺服器
- 效能測試如何定位瓶頸?偶發超時?看高手如何快速排查問題
- 線上效能問題初步排查方法
- 伺服器問題 排查思路伺服器
- JAVA死鎖排查-效能測試問題排查思路Java
- Linux排查JVM問題LinuxJVM
- VictoriaMetrics常見效能問題排查
- sqlldr載入效能問題的排查SQL
- Linux 伺服器效能出問題,運維應該排查下這些引數指標!Linux伺服器運維指標
- 伺服器效能指標(三)——記憶體使用分析及問題排查伺服器指標記憶體
- 伺服器效能指標(一)——負載(Load)分析及問題排查伺服器指標負載
- 一次快取效能問題排查快取
- openresty使用火焰圖排查效能問題REST
- 如何排查linux伺服器被入侵Linux伺服器
- 技能篇:linux服務效能問題排查及jvm調優思路LinuxJVM
- 運維秘籍:10條命令1分鐘,如何快速分析 Linux效能問題?運維Linux
- 一次容器MySQL的效能問題排查MySql
- awr效能問題排查第一篇
- Redis效能問題排查解決手冊(七)Redis
- 快速搭建主從的指令碼和問題排查指令碼
- 雲伺服器ECS伺服器訪問異常問題排查指引伺服器
- java問題排查Java
- JVM 問題排查JVM
- 框架問題排查框架
- 微服務場景下效能問題排查神器之xrebel微服務
- job處理緩慢的效能問題排查與分析
- 如何提高Linux伺服器效能Linux伺服器
- Java 線上問題排查神器 Arthas 快速上手與原理淺談Java
- Java線上問題排查神器Arthas快速上手與原理淺談Java
- 排查和解決 CentOS 伺服器磁碟空間不足問題CentOS伺服器
- SDK與問題排查
- 線上FullGC問題排查實踐——手把手教你排查線上問題GC
- Linux系統及應用問題分析排查工具Linux
- Windows、Linux快速排查系統是否被黑WindowsLinux
- 不要再說你不會了——網路效能問題排查思路
- 如何分析報表效能問題
- Arthas實踐–快速排查SpringBoot應用404/401問題Spring Boot
- Java服務.問題排查.問題復現Java