<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          Linux入門必看:如何在60秒內(nèi)分析Linux性能?

          共 11414字,需瀏覽 23分鐘

           ·

          2021-09-12 23:07


          導(dǎo)語 | 當(dāng)你登陸一臺Linux服務(wù)器之后,因為一個問題要做性能分析時,你會在第1分鐘內(nèi)做哪些檢測呢?本文將詳細(xì)為你介紹在最開始的60秒,如何在命令行模式下,使用已有的Linux標(biāo)準(zhǔn)工具來進行性能優(yōu)化檢測。


          (本文譯自Linux文獻:Linux Performance Analysis in 60,000 Milliseconds.

          原文:https://netflixtechblog.com/linux-performance-analysis-in-60-000-milliseconds-accc10403c55)



          在Netflix,我們有很多EC2的Linux機器,并且也需要很多性能分析工具來監(jiān)控和檢查它們的性能。包括有針對云上的監(jiān)控工具Atlas和按需要進行實例分析的Vector。雖然這些工具能幫助我們解決大多數(shù)問題,但是我們有時候還需要登陸機器實例去運行一些標(biāo)準(zhǔn)的Linux性能分析工具。



          一、最開始的60秒:摘要


          在60秒內(nèi)只需要通過運行下面的10個命令就可以對系統(tǒng)資源使用和運行進程有一個很高程度的了解。尋找錯誤信息和飽和度指標(biāo),并且可以顯示為請求隊列的長度,或者等待時長。因為它們都很容易理解,然后就是資源利用率。飽和度是指一個資源已經(jīng)超過了它自己的負(fù)荷能力。


          uptimedmesg | tailvmstat 1mpstat -P ALL 1pidstat 1iostat -xz 1free -msar -n DEV 1sar -n TCP,ETCP 1top


          有些命令需要安裝sysstat工具包。這些命令展示的指標(biāo)會幫助你完成一些USE(Utilization,Saturation,Errors)方法:定位性能瓶頸的方法論。包括了檢查使用率(Utilization),飽和度(Saturation),所有資源(比如CPU,內(nèi)存,磁盤等)的錯誤指標(biāo)(Errors)。同樣也要關(guān)注你什么時候檢查和排除一個資源問題,因為通過排除可以縮小分析范圍,同時也指導(dǎo)了任何后續(xù)的檢查。


          下面的章節(jié)將會通過一個生產(chǎn)系統(tǒng)中的例子來介紹這些命令。要了解更多這些工具的信息,也可以查看它們的幫助手冊。



          (一)uptime


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


          這是一個快速展示系統(tǒng)平均負(fù)載的方法,這也指出了等待運行進程的數(shù)量。在Linux系統(tǒng)中,這些數(shù)字包括等待CPU運行的進程數(shù),也包括了被不可中斷I/O(通常是磁盤I/O)阻塞的進程。這給出了資源負(fù)載的很直接的展示,可以在沒有其它工具的幫助下更好的理解這些數(shù)據(jù)。它是唯一快捷的查看系統(tǒng)負(fù)載的方式。


          這三個數(shù)字是以遞減的方式統(tǒng)計了過去1分鐘,5分鐘和15分鐘常數(shù)的平均數(shù)。這三個數(shù)字給我們直觀展示了隨著時間的變化系統(tǒng)負(fù)載如何變化。例如,如果你被叫去查看一個有問題的服務(wù)器,并且1分鐘的所代表的值比15分鐘的值低很多,那么你可能由于太遲登陸機器而錯過了問題發(fā)生的時間點。


          在上面的例子中,平均負(fù)載顯示是在不斷增加的,1分鐘的值是30,相比15分鐘的值19來說是增加了。這個數(shù)字這么大就意味著有事情發(fā)生了:可能是CPU需求;vmstat或者mpstat會幫助確認(rèn)到底是什么,這些命令會在本系列的第3和第4個命令中介紹。



          (二)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)消息日志,如果系統(tǒng)消息沒有就不會展示。主要是看由于性能問題導(dǎo)致的錯誤。上面這個例子中包含了殺死OOM問題的進程,丟棄TCP請求的問題。


          所以要記得使用這個命令,dmesg命令值得一用。



          (三)vmstat 1


          $ vmstat 1procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu----- r  b swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st34  0    0 200889792  73708 591828    0    0     0     5    6   10 96  1  3  0  032  0    0 200889920  73708 591860    0    0     0   592 13284 4282 98  1  1  0  032  0    0 200890112  73708 591860    0    0     0     0 9501 2154 99  1  0  0  032  0    0 200889568  73712 591856    0    0     0    48 11900 2459 99  0  0  0  032  0    0 200890208  73712 591860    0    0     0     0 15898 4840 98  1  1  0  0^C


          對虛擬內(nèi)存統(tǒng)計的簡短展示,vmstat是一個常用工具(最早是幾十年前為BSD創(chuàng)建的)。它每一行打印關(guān)鍵的服務(wù)信息統(tǒng)計摘要。


          vmstat使用參數(shù)1來運行的時候,是每1秒打印一條統(tǒng)計信息。在這個版本的vmstat中,輸出的第一行展示的是自從啟動后的平均值,而不是前一秒的統(tǒng)計。所以現(xiàn)在,可以跳過第一行,除非你要看一下抬頭的字段含義。


          每列含義說明:


          1. r: CPU上的等待運行的可運行進程數(shù)。這個指標(biāo)提供了判斷CPU飽和度的數(shù)據(jù),因為它不包含I/O等待的進程??山忉尀椋骸皉” 的值比CPU數(shù)大的時候就是飽和的。

          2. free:空閑內(nèi)存,單位是k。如果這個數(shù)比較大,就說明你還有充足的空閑內(nèi)存?!癴ree -m” 和下面第7個命令,可以更詳細(xì)的分析空閑內(nèi)存的狀態(tài)。

          3. si,so:交換進來和交換出去的數(shù)據(jù)量,如果這兩個值為非0值,那么就說明沒有內(nèi)存了。

          4. us,sy,id,wa,st:這些是CPU時間的分解,是所有CPU的平均值。它們是用戶時間,系統(tǒng)時間(內(nèi)核),空閑,等待I/O時間,和被偷的時間(這里主要指其它的客戶,或者使用Xen,這些客戶有自己獨立的操作域)。


          CPU時間的分解可以幫助確定CPU是不是非常忙(通過用戶時間和系統(tǒng)時間累加判斷)。持續(xù)的I/O等待則表明磁盤是瓶頸。這種情況下CPU是比較空閑的,因為任務(wù)都由于等待磁盤I/O而被阻塞。你可以把等待I/O看作是另外一種形式的CPU空閑,而這個命令給了為什么它們空閑的線索。


          系統(tǒng)時間對于I/O處理來說是必須的。比較高的平均系統(tǒng)時間消耗,比如超過了20%,就有必要進一步探索分析了:也有可能是內(nèi)核處理I/O效率不夠高導(dǎo)致。


          在上面的例子中,CPU時間幾乎都是用戶級別的,說明這是一個應(yīng)用級別的使用情況。如果CPU的使用率平均都超過了90%。這不一定問題;可以使用 “r” 列來檢查使用飽和度。



          (四)mpstat-P ALL 1


          $ mpstat -P ALL 1Linux 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 %idle07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.7807:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.9907:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.0007:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.0007: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的時間統(tǒng)計,可以看出整體CPU的使用是不是均衡的。有一個使用率明顯較高的CPU就可以明顯看出來這是一個單線程應(yīng)用。



          (五)pidstat 1


          $ pidstat 1Linux 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 Command07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/007:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java07: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 Command07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave07: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 java07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat^C


          pidstat命令有點像top命令中的為每個CPU統(tǒng)計信息功能,但是它是以不斷滾動更新的方式打印信息,而不是每次清屏打印。這個對于觀察隨時間變化的模式很有用,同時把你看到的信息(復(fù)制粘貼)記到你的調(diào)查記錄中。


          上面的例子可以看出是2個java進程在消耗CPU。%CPU列是所有CPU的使用率;1591%是說明這個java進程消耗了幾乎16個CPU核。



          (六)iostat -xz 1


          $ iostat -xz 1Linux 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 %utilxvda 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.09xvdb 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.25xvdc 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.26dm-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.04dm-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.00dm-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è)備(比如磁盤)很有用,展示了請求負(fù)載和性能數(shù)據(jù)。具體的數(shù)據(jù)看下面字段的解釋:


          1. r/s, w/s, rkB/s, wkB/s:這些表示設(shè)備上每秒鐘的讀寫次數(shù)和讀寫的字節(jié)數(shù)(單位是k字節(jié))。這些可以看出設(shè)備的負(fù)載情況。性能問題可能就是簡單的因為大量的文件加載請求。


          2. await:I/O等待的平均時間(單位是毫秒)。這是應(yīng)用程序所等待的時間,包含了等待隊列中的時間和被調(diào)度服務(wù)的時間。過大的平均等待時間就預(yù)示著設(shè)備超負(fù)荷了或者說設(shè)備有問題了。


          3. avgqu-sz:設(shè)備上請求的平均數(shù)。數(shù)值大于1可能表示設(shè)備飽和了(雖然設(shè)備通常都是可以支持并行請求的,特別是在背后掛了多個磁盤的虛擬設(shè)備)。


          4. %util:設(shè)備利用率。是使用率的百分?jǐn)?shù),展示每秒鐘設(shè)備工作的時間。這個數(shù)值大于60%則會導(dǎo)致性能很低(可以在await中看),當(dāng)然這也取決于設(shè)備特點。這個數(shù)值接近100%則表示設(shè)備飽和了。


          如果存儲設(shè)備是一個邏輯磁盤設(shè)備,后面掛載了多個磁盤,那么100%的利用率則只是表示有些I/O是在100%處理,然而后端的磁盤或許遠(yuǎn)遠(yuǎn)沒有飽和,還可以處理更多的請求。


          請記住,磁盤I/O性能低不一定是應(yīng)用程序的問題。許多技術(shù)通常都被用來實現(xiàn)異步執(zhí)行I/O,所以應(yīng)用程序不會直接阻塞和承受延時(比如:預(yù)讀取和寫緩沖技術(shù))。



          (七)free-m


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


          右面兩列展示的是:


          1. buffers:用于塊設(shè)備I/O緩沖的緩存。

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


          我們只想檢測這些緩存的數(shù)值是否接近0。不為0的可能導(dǎo)致較高的磁盤I/O(通過iostat命令來確認(rèn))和較差的性能問題。上面的例子看起來沒問題,都還有很多M字節(jié)。


          “-/+ buffers/cache” 這一行提供了對已使用和空閑內(nèi)存明確的統(tǒng)計。Linux用空閑內(nèi)存作為緩存,如果應(yīng)用程序需要,可以快速拿回去。所以應(yīng)該包含空閑內(nèi)存那一列,這里就是這么統(tǒng)計的。甚至有一個網(wǎng)站專門來介紹Linux內(nèi)存消耗的問題:linuxatemyram。


          如果在Linux上使用了ZFS文件系統(tǒng),則可能會更亂,因為當(dāng)我們在開發(fā)一些服務(wù)的時候,ZFS有它自己的文件系統(tǒng)緩存,而這部分內(nèi)存的消耗是不會在free-m這個命令中合理的反映的。顯示了系統(tǒng)內(nèi)存不足,但是ZFS的這部分緩存是可以被應(yīng)用程序使用的。



          (八)sar-n DEV 1


          $ sar -n DEV 1Linux 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 %ifutil12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.0012:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.0012: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 %ifutil12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.0012:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.0012: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,作為收發(fā)數(shù)據(jù)負(fù)載的度量,也是檢測是否達(dá)到收發(fā)極限。在上面這個例子中,eth0接收數(shù)據(jù)達(dá)到22M字節(jié)/秒,也就是176Mbit/秒(網(wǎng)卡的上限是1Gbit/秒)。


          這個版本的工具還有一個統(tǒng)計字段: %ifutil,用于統(tǒng)計設(shè)備利用率(全雙工雙向最大值),這個利用率也可以使用Brendan的nicstat工具來測量統(tǒng)計。在這個例子中0.00這種情況就似乎就是沒有統(tǒng)計,這個和nicstat一樣,這個值是比較難統(tǒng)計正確的。



          (九)sar-n TCP,ETCP 1

          $ sar -n TCP,ETCP 1Linux 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/s12:17:20 AM 1.00 0.00 10233.00 18846.00
          12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s12:17:20 AM 0.00 0.00 0.00 0.00 0.00
          12:17:20 AM active/s passive/s iseg/s oseg/s12:17:21 AM 1.00 0.00 8359.00 6039.00
          12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s12:17:21 AM 0.00 0.00 0.00 0.00 0.00^C


          這是對TCP關(guān)鍵指標(biāo)的統(tǒng)計,它包含了以下內(nèi)容:


          1. active/s:每秒本地發(fā)起的TCP連接數(shù)(例如通過connect()發(fā)起的連接)。


          2. passive/s:每秒遠(yuǎn)程發(fā)起的連接數(shù)(例如通過accept()接受的連接)。


          3. retrans/s:每秒TCP重傳數(shù)。


          負(fù)載的粗略估計:新接受連接數(shù)(被動),下游連接數(shù)(主動)。可以把主動看作是外部的,被動的是內(nèi)部,但是這個通常也不是非常準(zhǔn)確(例如:當(dāng)有本地到本地的連接時)。


          重傳是網(wǎng)絡(luò)或者服務(wù)器有問題的一個信號;可能是一個不可靠的網(wǎng)絡(luò)(例如:公網(wǎng)),或者可能是因為服務(wù)器過載了開始丟包。上面這個例子可以看出是每秒新建一個TCP連接。



          (十)top


          $ toptop - 00:15:40 up 21:56,  1 user,  load average: 31.09, 29.87, 29.92Tasks: 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 stKiB Mem:  25190241+total, 24921688 used, 22698073+free,    60448 buffersKiB Swap:        0 total,        0 used,        0 free.   554208 cached Mem
          PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/05 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:08 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched


          top命令包含了很多我們前面提到的指標(biāo)。這個命令可以很容易看出指標(biāo)的變化表示負(fù)載的變化,這個看起來和前面的命令有很大不同。


          top的一個缺陷也比較明顯,很難看出變化趨勢,其它像vmstat和pidstat這樣的工具就會很清晰,它們是以滾動的方式輸出統(tǒng)計信息。所以如果你在看到有問題的信息時沒有及時的暫停下來(Ctrl-S是暫停, Ctrl-Q是繼續(xù)),那么這些有用的信息就會被清屏。



          二、后續(xù)分析


          還有很多可以使用來深挖系統(tǒng)問題的命令和技術(shù),可以看看Brendan在 2015年講的Linux性能工具介紹 ,這里面講述了40多個命令,涵蓋了可觀測性,基準(zhǔn)測試,調(diào)優(yōu),靜態(tài)性能調(diào)優(yōu),分析和跟蹤等多個方面。



           譯者簡介


          許振文

          增值服務(wù)部/營銷基礎(chǔ)平臺中心,騰訊游戲Gcloud云原生服務(wù)開發(fā)平臺負(fù)責(zé)人

          許振文,增值服務(wù)部/營銷基礎(chǔ)平臺中心,騰訊游戲Gcloud云原生服務(wù)開發(fā)平臺負(fù)責(zé)人。同時也是Linux內(nèi)核之旅開源社區(qū)的負(fù)責(zé)人,Istio社區(qū)Member和Kubernetes社區(qū)Member,參與中國信息通信研究院主導(dǎo)的多個行業(yè)標(biāo)準(zhǔn)制定,個人主要關(guān)注大數(shù)據(jù)計算,DevOps,K8S,ServiceMesh技術(shù)等。



           推薦閱讀


          “Docker VS Kubernetes”是共生還是相愛相殺?

          揭秘!是什么能讓APP快速精準(zhǔn)定位?

          人機共生時代,分布式機器學(xué)習(xí)是如何加速的?

          手把手教你快速理解gRPC!





          瀏覽 71
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  99热高清在线观看 | 我要看国产一级黄片 | 亚洲久精| 亚洲欧美日本异类 | 男人的天堂青青草视频 |