26. 60s快速定位服務(wù)器性能問題-曬酷學院

60s迅速發(fā)現(xiàn)性能問題

  • 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

1轧葛、uptime

$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02

這是一種用來快速查看系統(tǒng)平均負載的方法搂抒,它表明了系統(tǒng)中有多少要運行的任務(wù)(進程)。在 Linux 系統(tǒng)中尿扯,這些數(shù)字包含了需要在 CPU 中運行的進程以及正在等待 I/O(通常是磁盤 I/O)的進程求晶。它僅僅是對系統(tǒng)負載的一個粗略展示,稍微看下即可衷笋。你還需要其他工具來進一步了解具體情況芳杏。

這三個數(shù)字展示的是一分鐘、五分鐘和十五分鐘內(nèi)系統(tǒng)的負載總量平均值按照指數(shù)比例壓縮得到的結(jié)果辟宗。從中我們可以看到系統(tǒng)的負載是如何隨時間變化的爵赵。比方你在檢查一個問題,然后看到 1 分鐘對應(yīng)的值遠小于 15 分鐘的值泊脐,那么可能說明這個問題已經(jīng)過去了亚再,你沒能及時觀察到。

在上面這個例子中晨抡,系統(tǒng)負載在隨著時間增加,因為最近一分鐘的負載值超過了 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 counters.

這條命令顯式了最近的 10 條系統(tǒng)消息士袄,如果它們存在的話。查找能夠?qū)е滦阅軉栴}的錯誤谎僻。上面的例子包含了 oom-killer娄柳,以及 TCP 丟棄一個請求。千萬不要錯過這一步艘绍!dmesg 命令永遠值得一試赤拒。

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

vmstat(8) 是虛擬內(nèi)存統(tǒng)計的簡稱诱鞠,其是一個常用工具(幾十年前為了 BSD 所創(chuàng)建)挎挖。其在每行打印一條關(guān)鍵的服務(wù)器的統(tǒng)計摘要。

vmstat 命令指定一個參數(shù) 1 運行航夺,來打印每一秒的統(tǒng)計摘要蕉朵。(這個版本的 vmstat)輸出的第一行的那些列,顯式的是開機以來的平均值阳掐,而不是前一秒的值∈夹疲現(xiàn)在冷蚂,我們跳過第一行,除非你想要了解并記住每一列觅闽。

檢查這些列:

  • r:CPU 中正在運行和等待運行的進程的數(shù)量帝雇。其提供了一個比平均負載更好的信號來確定 CPU 是否飽和,因為其不包含 I/O蛉拙。解釋:“r”的值大于了 CPU 的數(shù)量就表示已經(jīng)飽和了尸闸。

  • free:以 kb 為單位顯式的空閑內(nèi)存。如果數(shù)字位數(shù)很多孕锄,說明你有足夠的空閑內(nèi)存吮廉。“free -m” 命令畸肆,是下面的第七個命令宦芦,其可以更好的說明空閑內(nèi)存的狀態(tài)。

  • si, so:Swap-ins 和 swap-outs轴脐。如果它們不是零调卑,則代表你的內(nèi)存不足了。

  • us, sy, id, wa, st:這些都是平均了所有 CPU 的 CPU 分解時間大咱。它們分別是用戶時間(user)恬涧、系統(tǒng)時間(內(nèi)核)(system)、空閑(idle)碴巾、等待 I/O(wait)溯捆、以及占用時間(stolen)(被其他訪客,或使用 Xen厦瓢,訪客自己獨立的驅(qū)動域)提揍。

CPU 分解時間將會通過用戶時間加系統(tǒng)時間確認 CPU 是否為忙碌狀態(tài)。等待 I/O 的時間一直不變則表明了一個磁盤瓶頸煮仇;這就是 CPU 的閑置劳跃,因為任務(wù)都阻塞在等待掛起磁盤 I/O 上了。你可以把等待 I/O 當成是 CPU 閑置的另一種形式欺抗,其給出了為什么 CPU 閑置的一個線索售碳。

對于 I/O 處理來說,系統(tǒng)時間是很重要的绞呈。一個高于 20% 的平均系統(tǒng)時間贸人,可以值得進一步的探討:也許內(nèi)核在處理 I/O 時效率太低了。

在上面的例子中佃声,CPU 時間幾乎完全花在了用戶級艺智,表明應(yīng)用程序占用了太多 CPU 時間。而 CPU 的平均使用率也在 90% 以上圾亏。這不一定是一個問題十拣;檢查一下“r”列中的飽和度封拧。

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 很忙碌則代表了正在運行一個單線程的應(yīng)用程序。

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 命令對每個進程的統(tǒng)計摘要捧杉,但循環(huán)打印一個滾動的統(tǒng)計摘要來代替 top 的刷屏。其可用于實時查看秘血,同時也可將你所看到的東西(復(fù)制粘貼)到你的調(diào)查記錄中味抖。

上面的例子表明兩個 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    5.62   1.78   0.03
[...]
^C

這是用于查看塊設(shè)備(磁盤)情況的一個很棒的工具粘舟,無論是對工作負載還是性能表現(xiàn)來說熔脂。查看個列:

  • r/s, w/s, rkB/s, wkB/s:這些分別代表該設(shè)備每秒的讀次數(shù)、寫次數(shù)柑肴、讀取 kb 數(shù)锤悄,和寫入 kb 數(shù)。這些用于描述工作負載嘉抒。性能問題可能僅僅是由于施加了過大的負載。

  • await:以毫秒為單位的 I/O 平均消耗時間袍暴。這是應(yīng)用程序消耗的實際時間些侍,因為它包括了排隊時間和處理時間。比預(yù)期更大的平均時間可能意味著設(shè)備的飽和政模,或設(shè)備出了問題岗宣。

  • avgqu-sz:向設(shè)備發(fā)出的請求的平均數(shù)量。值大于 1 說明已經(jīng)飽和了(雖說設(shè)備可以并行處理請求淋样,尤其是由多個磁盤組成的虛擬設(shè)備耗式。)

  • %util:設(shè)備利用率。這個值是一個顯示出該設(shè)備在工作時每秒處于忙碌狀態(tài)的百分比趁猴。若值大于 60%刊咳,通常表明性能不佳(可以從 await 中看出),雖然它取決于設(shè)備本身儡司。值接近 100% 通常意味著已飽和娱挨。

如果該存儲設(shè)備是一個面向很多后端磁盤的邏輯磁盤設(shè)備,則 100% 利用率可能只是意味著當前正在處理某些 I/O 占用捕犬,然而跷坝,后端磁盤可能遠未飽和酵镜,并且可能能夠處理更多的工作。

請記住柴钻,磁盤 I/O 性能較差不一定是程序的問題淮韭。許多技術(shù)通常是異步 I/O,使應(yīng)用程序不會被阻塞并遭受延遲(例如贴届,預(yù)讀靠粪,以及寫緩沖)。

7粱腻、 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

右邊的兩列顯式:

  • buffers:用于塊設(shè)備 I/O 的緩沖區(qū)緩存庇配。

  • cached:用于文件系統(tǒng)的頁面緩存。

我們只是想要檢查這些不接近零的大小绍些,其可能會導(dǎo)致更高磁盤 I/O(使用 iostat 確認)捞慌,和更糟糕的性能。上面的例子看起來還不錯柬批,每一列均有很多 M 個大小啸澡。

比起第一行,-/+ buffers/cache 提供的內(nèi)存使用量會更加準確些氮帐。Linux 會把暫時用不上的內(nèi)存用作緩存嗅虏,一旦應(yīng)用需要的時候就立刻重新分配給它。所以部分被用作緩存的內(nèi)存其實也算是空閑的內(nèi)存上沐。為了解釋這一點皮服, 甚至有人專門建了個網(wǎng)站: linuxatemyram。

如果你在 Linux 上安裝了 ZFS参咙,這一點會變得更加困惑龄广,因為 ZFS 它自己的文件系統(tǒng)緩存不算入free -m。有時候發(fā)現(xiàn)系統(tǒng)已經(jīng)沒有多少空閑內(nèi)存可用了蕴侧,其實內(nèi)存卻都待在 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

這個工具可以被用來檢查網(wǎng)絡(luò)接口的吞吐量:rxkB/s 和 txkB/s净宵,以及是否達到限額敲才。上面的例子中,eth0 接收的流量達到 22Mbytes/s择葡,也即 176Mbits/sec(限額是 1Gbit/sec)

我們用的版本中還提供了 %ifutil 作為設(shè)備使用率(接收和發(fā)送的最大值)的指標紧武。我們也可以用 Brendan 的 nicstat 工具計量這個值。一如 nicstat敏储,sar 顯示的這個值是很難精確取得的脏里,在這個例子里面,它就沒在正常的工作(0.00)虹曙。

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

這是一些關(guān)鍵的 TCP 指標的匯總視圖番舆。這些包括:

  • active/s:每秒本地發(fā)起 TCP 連接數(shù)(例如,通過 connect())矾踱。

  • passive/s:每秒遠程發(fā)起的 TCP 連接數(shù)(例如恨狈,通過 accept())。

  • retrans/s:每秒重傳 TCP 次數(shù)呛讲。

active 和 passive 的連接數(shù)往往對于描述一個粗略衡量服務(wù)器負載是非常有用的:新接受的連接數(shù)(passive)禾怠,下行連接數(shù)(active)”锤椋可以理解為 active 連接是對外的吗氏,而 passive 連接是對內(nèi)的,雖然嚴格來說并不完全正確(例如雷逆,一個 localhost 到 localhost 的連接)弦讽。

重傳是出現(xiàn)一個網(wǎng)絡(luò)和服務(wù)器問題的一個征兆。其可能是由于一個不可靠的網(wǎng)絡(luò)(例如膀哲,公網(wǎng))造成的往产,或許也有可能是由于服務(wù)器過載并丟包。上面的例子顯示了每秒只有一個新的 TCP 連接某宪。

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 命令包含了很多我們之前已經(jīng)檢查過的指標⌒宋梗可以方便的執(zhí)行它來查看相比于之前的命令輸出的結(jié)果有很大不同蔼囊,這表明負載是可變的。

top 的一個缺點是衣迷,很難看到數(shù)據(jù)隨時間變動的趨勢压真。vmstat 和 pidstat 提供的滾動輸出會更清楚一些。如果你不以足夠快的速度暫停輸出(Ctrl-S 暫停蘑险,Ctrl-Q 繼續(xù)),一些間歇性問題的線索也可能由于被清屏而丟失岳悟。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末佃迄,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子贵少,更是在濱河造成了極大的恐慌呵俏,老刑警劉巖,帶你破解...
    沈念sama閱讀 207,248評論 6 481
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件滔灶,死亡現(xiàn)場離奇詭異普碎,居然都是意外死亡,警方通過查閱死者的電腦和手機录平,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,681評論 2 381
  • 文/潘曉璐 我一進店門麻车,熙熙樓的掌柜王于貴愁眉苦臉地迎上來缀皱,“玉大人,你說我怎么就攤上這事动猬∑《罚” “怎么了?”我有些...
    開封第一講書人閱讀 153,443評論 0 344
  • 文/不壞的土叔 我叫張陵赁咙,是天一觀的道長钮莲。 經(jīng)常有香客問我,道長彼水,這世上最難降的妖魔是什么崔拥? 我笑而不...
    開封第一講書人閱讀 55,475評論 1 279
  • 正文 為了忘掉前任,我火速辦了婚禮凤覆,結(jié)果婚禮上链瓦,老公的妹妹穿的比我還像新娘。我一直安慰自己叛赚,他們只是感情好澡绩,可當我...
    茶點故事閱讀 64,458評論 5 374
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著俺附,像睡著了一般肥卡。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上事镣,一...
    開封第一講書人閱讀 49,185評論 1 284
  • 那天步鉴,我揣著相機與錄音,去河邊找鬼璃哟。 笑死氛琢,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的随闪。 我是一名探鬼主播阳似,決...
    沈念sama閱讀 38,451評論 3 401
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼铐伴!你這毒婦竟也來了撮奏?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,112評論 0 261
  • 序言:老撾萬榮一對情侶失蹤当宴,失蹤者是張志新(化名)和其女友劉穎畜吊,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體户矢,經(jīng)...
    沈念sama閱讀 43,609評論 1 300
  • 正文 獨居荒郊野嶺守林人離奇死亡玲献,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,083評論 2 325
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片捌年。...
    茶點故事閱讀 38,163評論 1 334
  • 序言:一個原本活蹦亂跳的男人離奇死亡瓢娜,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出延窜,到底是詐尸還是另有隱情恋腕,我是刑警寧澤,帶...
    沈念sama閱讀 33,803評論 4 323
  • 正文 年R本政府宣布逆瑞,位于F島的核電站荠藤,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏获高。R本人自食惡果不足惜哈肖,卻給世界環(huán)境...
    茶點故事閱讀 39,357評論 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望念秧。 院中可真熱鬧淤井,春花似錦、人聲如沸摊趾。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,357評論 0 19
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽砾层。三九已至漩绵,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間肛炮,已是汗流浹背止吐。 一陣腳步聲響...
    開封第一講書人閱讀 31,590評論 1 261
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留侨糟,地道東北人碍扔。 一個月前我還...
    沈念sama閱讀 45,636評論 2 355
  • 正文 我出身青樓,卻偏偏與公主長得像秕重,于是被迫代替她去往敵國和親不同。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 42,925評論 2 344

推薦閱讀更多精彩內(nèi)容