1寫在前面
- 今天和小夥伴們分享通過USE方法對系統進行性能分析和性能調整
- 博文内容涉及： 什麼是USE方法，以及USE的使用建議具體的USE名額采集分析
- 食用方式: 需要Linux基礎知識
- 了解不足小夥伴幫忙指正
傍晚時分，你坐在屋檐下，看着天慢慢地黑下去，心裡寂寞而凄涼，感到自己的生命被剝奪了。當時我是個年輕人，但我害怕這樣生活下去，衰老下去。在我看來，這是比死亡更可怕的事。--------王小波
如果說希望通過USE做一些調優的工作，我覺得還是需要一定的能力的，但是我們可以通過USE來定位機器的性能瓶頸，做一些排故工作。比如機器上的應用發生某些已知的未知故障，比如客戶感覺卡頓，工單流轉，編排，排程任務等特别慢的情況，希望确認是機器性能問題，還是應用程式問題，這個時候，使用USE方法是一個很好的政策。
2USE方法
USE方法(utilization、saturation、errors)可以用于性能研究，用來識别系統瓶頸,同時有感覺故障，可以定位問題。
關于什麼是USE？即圍繞伺服器實體元器件(CPU、記憶體等資源)，某些軟體資源也能算在内，通過使用率、飽和度和錯誤三個名額的采集分析，對系統進行性能研究，在故障發生前發現系統瓶頸。
- 使用率 ：在規定的時間間隔内，資源用于服務工作的時間百分比。雖然資源繁忙，但是資源還有能力接受更多的工作，不能接受更多工作的程度被視為飽和度。
- 飽和度 ：資源不能再服務更多額外工作的程度，通常有等待隊列。
- 錯誤 ：錯誤事件的個數。
這裡需要注意的是：某些資源類型，比如記憶體，磁盤使用率指的是資源所用的容量。這與基于時間的定義是不同的，比如CUP等,一旦資源的容量達到100%的使用率，就無法接受更多的工作，資源或者會把工作進行排隊(飽和)，或者會傳回錯誤，用USE方法也可以予以鑒别。錯誤需要調查，因為它們會損害性能`，如果故障模式是可恢複的，有對應的容災政策，錯誤可能難以立即察覺。這包括操作失敗重試，還有備援裝置池中的裝置故障。
通過上面的方法辨識出的很可能是系統瓶頸問題。不過，一個系統可能不隻面臨一個性能問題，可能一開始就能找到問題，但所找到的問題并非你關心的那個。在根據需要傳回USE方法周遊其他資源之前，每個發現可以用更多的方法進行調查,z需要查閱相關的資料。
當然有那種很明顯的情況。由客戶感覺或者名額監控發現 ,通過全局的觀測工具可以很快定位問題的那種，往往不需要通過USE流程方法：
如上面的這個圖檔。我們可以看到明顯的問題，top 指令中，mysql程序CUP相關名額明顯異常，從三個地方可以看到：
- 系統平均負載：最上面的CUP負載，load average：27.28，,26.88,27.19 為CPU最近1/5/15分鐘的平均負載，負載平均數超過了CPU數量通常代表CPU飽和。目前核數為16核，即CPU不足以服務線程.
平均負載表示了對CPU資源的需求，一個有64顆CPU的系統的平均負載為128。這意味着平均每個CPU上有一個線程在運作，還有一個線程在等待。而同樣的系統，如果平均負載為10，則代表還有很大的餘量，在所有CPU跑滿前還可以運作54個CPU消耗型線程。但是Linux平均負載除了CPU還把不可中斷狀态執行磁盤I/O的任務也計入平均負載。
- 單個CPU飽和：top指令+1 展示每個cup的負載情況，us項為使用者程序消耗CUP使用率，sy為系統程序消耗，id為目前CPU的空閑，從us和id項可以看出，目前多個CUP飽和，空閑率為0
- 程序CPU使用率近飽和：top的程序清單可以看到，目前 mysqld 的程序，主記憶體(%MEM)占比為9.6，CPU占比(%CPU)為1576(16c為1600m),占比近100%，成飽和狀态，而且TIME值也不太正常，程序虛拟記憶體使用總量(VIRT)為45.274g(包括了應用程式配置設定到但未使用的全部記憶體)，共享記憶體(SHR)為2.012g，應用程式實際使用的實體記憶體總量(RES)為0.012t(12.288g)。總記憶體為126g，是以應該不是記憶體方面的問題，不存在洩露之類的情況
$ free -h
total used free shared buff/cache available
Mem: 126G 44G 25G 2.5G 57G 79G
Swap: 6.0G 851M 5.2G
$
通過上面的簡單名額檢視，可以推斷mysqld程序異常，多個CPU呈現飽和狀态，可能存在着類似死循環的操作，不斷的建立線程，導緻CUP飽和。進而我們可以排查mysqld服務的程序資訊 show processlist;。後排查發現确實存在。kill掉對應的外挂，mysqld恢複正常,然後排查外挂的問題。
名額表述
USE方法的名額通常如下。
- 使用率：一定時間間隔内的百分比值(例如，“單個CPU運作在90%的使用率上”)。
- 飽和度：等待隊列的長度(例如，“CPU的平均運作隊列長度是4”)。
- 錯誤：報告出的錯誤數目(例如，“這個網絡接口發生了50次滞後沖突”)。
即便整體的使用率在很長一段時間都處于較低水準，一次高使用率的瞬時沖擊還是能導緻飽和與性能問題的。某些監控工具彙報的使用率是超過5分鐘的均值。是以名額監控要
舉個例子，每秒的CPU使用率可以變動得非常劇烈，是以5分鐘時長的均值可能會掩蓋短時間内100%的使用率，甚至是飽和的情況。
想象一下高速公路的收費站。使用率就相當于有多少收費站在忙于收費。使用率100%意味着你找不到一個空的收費站，必須排在别人的後面(飽和的情況)。如果我說一整天收費站的使用率是40%，你能判斷當天是否有車在某一時間排過隊嗎？很可能在高峰時候确實排過隊，那時的使用率是100%，但是這在一天的均值上是看不出的。
資源清單
USE方法的第一步是要建一張資源清單，要盡可能完整。下面是一張伺服器通常的資源清單，配有相應的例子。
- CPU：插槽、核、硬體線程(虛拟CPU)
- 記憶體：DRAM
- 網絡接口：以太網端口
- 儲存設備：磁盤
......
每個元件通常作為一類資源類型。例如，記憶體是一種容量資源，網絡接口是一類I/O資源(IOPS或吞吐量)。有些元件展現出多種資源類型：例如，儲存設備既是I/O資源也是容量資源。這時需要考慮到所有的類型都能夠造成性能瓶頸，同時，也要知道I/O資源可以進一步被當作排隊系統來研究，将請求排隊并被服務。
某些實體資源，諸如硬體緩存(如CPU緩存)，可能不在清單中。USE方法是處理在高使用率或飽和狀态下性能下降的資源最有效的方法，當然還有其他的檢測方法。如果你不确定清單是否該包括一項資源，那就包括它，看看在實際名額中是什麼樣的情況。
名額
一旦你掌握了資源的清單，就可以考慮這三類名額：使用率、飽和度，以及錯誤。表2.5列舉了一些資源和名額類型，以及一些可能的名額(針對一般性的OS)。這些名額要麼是一定時間間隔的均值，要麼是累計數目。
資源 類型 名額 CPU 使用率 CPU使用率(單CPU使用率或系統級均值) CPU 飽和度 配置設定隊列長度(又名運作隊列長度) 記憶體 使用率 可用空閑記憶體(系統級) 記憶體 飽和度 匿名換頁或線程換出(頁面掃描是另一個名額)，或者OOM事件 網絡接口 使用率 接收吞吐量/最大帶寬，傳輸吞吐量/最大帶寬儲存設備/O使用率裝置繁忙百分比儲存設備/O飽和度等待隊列長度 儲存設備/O 錯誤 裝置錯誤(“硬錯誤”、“軟錯誤”)
重複所有的組合，包括擷取每個名額的步驟，記錄下目前無法獲得的名額，那些是已知的未知。最終你得到一個大約30項的名額清單，有些名額難以測量，有些根本測不了。所幸的是，常見的問題用較簡單的名額就能發現(例如，CPU飽和度、記憶體容量飽和度、網絡接口使用率、磁盤使用率)，是以這些名額要首先測量。
一些較難的組合示例可見下表
資源 類型 名額 CPU 錯誤 例如，可修正的CPU緩存ECC事件，或者可修正的CPU故障(如果作業系統加上硬體支援) 記憶體 錯誤 例如，失敗的malloc()(雖然這通常是由于虛拟記憶體耗盡，并非實體記憶體) 網絡 飽和度 與飽和度相關的網絡接口或作業系統錯誤，例如，Linux的overrun和Solaris的nocanput 存儲控制器 使用率 取決于控制器，針對目前活動可能有最大IOPS或吞吐量可供檢查 CPU互聯 使用率 每個端口的吞吐量/最大帶寬(CPU性能計數器) 記憶體互聯 飽和度 記憶體停滞周期數，偏高的平均指令周期數(CPU性能計數器) I/O互聯 使用率 總線吞吐量/最大帶寬(可能你的硬體上有性能計數器，例如，Intel的“非核心”事件)
上述的某些名額可能用作業系統的标準工具是無法獲得的，可能需要使用動态跟蹤或者用到CPU性能計數工具。
使用建議
對于使用上述這些名額類型，這裡有一些總體的建議。
- 使用率 ：100%的使用率通常是瓶頸的信号(檢查飽和度并确認其影響)。使用率超過60%可能會是問題，基于以下理由： 時間間隔的均值，可能掩蓋了100%使用率的短期爆發一些資源，諸如硬碟(不是CPU)，通常在操作期間是不能被中斷的，即使做的是優先級較高的工作。随着使用率的上升，排隊延時會變得更頻繁和明顯。
關于為什麼是60%使用率，基于排隊理論，随着使用率的增加，資源的響應時間成本增加，類似于幂函數 y=x^2
使用率超過60%，平均響應時間會變成兩倍。在80%時，平均響應時間變成了三倍。 磁盤I/0延時通常是應用程式的資源限制，兩倍或更多的平均延時增加會給應用程式帶來顯著的負面影響。
排隊系統内的請求是不能被打斷的(通常而言)，必須等到輪到自己，這就是磁盤使用率在達到100%之前就會變成的問題的原因。CPU資源與之不同，更高優先級的任務是可以搶占CPU的。
- 飽和度 ：任何程度的飽和都是問題(非零)。飽和程度可以用排隊長度或者排隊所花的時間來度量。
- 錯誤 ：錯誤都是值得研究的，尤其是随着錯誤增加性能會變差的那些錯誤。
低使用率、無飽和、無錯誤：這樣的反例研究起來容易。這點要比看起來還有用縮小研究的範圍能幫你快速地将精力集中在出問題的地方，判斷其不是某一個資源的問題，這是一個排除法的過程。
下面為上面提到的資源和對應名額檢視工具Demo，隻是涉及部分
3CPU 使用率
CPU使用率通過測量一段時間内CPU執行個體忙于執行工作的時間比例獲得，以百分比表示。也可以通過測量CPU未運作核心空閑線程的時間得出，這段時間内CPU可能在運作一些使用者态應用程式線程，或者其他的核心線程，或者在進行中斷。高CPU使用率并不一定代表着問題，僅僅表示系統正在工作。
CPU在高使用率的情況下，性能并不會出現顯著下降，因為核心支援了優先級、搶占和分時共享。這些概念加起來讓核心決定了什麼線程的優先級更高，并保證它優先運作。
CPU使用率通常被分成核心時間(%sys)和使用者時間(%usr)兩個名額。
- 計算密集型的CPU使用者/核心時間比可達到99/1,
- I/O密集型的CPU使用者/核心時間比可達到70/30,
每個CPU
mpstat -P ALL檢視每個CPU的使用率，%idle指CPU的空閑率,通過檢查單個熱點(繁忙)CPU，挑出一個可能的線程擴充性問題。(不太懂，先記下來)
┌──[[email protected]]-[~]
└─$ mpstat -P ALL
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月05日 _x86_64_ (6 CPU)
22時59分30秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
22時59分30秒 all 5.44 0.00 7.91 0.51 0.00 0.30 0.00 0.00 0.00 85.85
22時59分30秒 0 5.65 0.00 7.43 0.60 0.00 0.29 0.00 0.00 0.00 86.02
22時59分30秒 1 5.34 0.00 9.01 0.47 0.00 0.33 0.00 0.00 0.00 84.85
22時59分30秒 2 5.80 0.00 7.12 0.40 0.00 0.36 0.00 0.00 0.00 86.32
22時59分30秒 3 5.68 0.00 7.74 0.50 0.00 0.30 0.00 0.00 0.00 85.77
22時59分30秒 4 3.84 0.00 6.08 0.23 0.00 0.23 0.00 0.00 0.00 89.62
22時59分30秒 5 6.30 0.00 10.04 0.86 0.00 0.27 0.00 0.00 0.00 82.54
┌──[[email protected]]-[~]
└─$
也可用通過 sar -P ALL的指令來檢視，sar可以擷取平均資料，%idle指CPU的空閑率,反過來即為使用率
┌──[[email protected]]-[~]
└─$ sar -P ALL
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月05日 _x86_64_ (6 CPU)
22時56分20秒 LINUX RESTART
23時00分01秒 CPU %user %nice %system %iowait %steal %idle
23時10分01秒 all 0.21 0.00 0.39 0.01 0.00 99.39
23時10分01秒 0 0.20 0.00 0.42 0.01 0.00 99.36
23時10分01秒 1 0.33 0.00 0.60 0.01 0.00 99.06
23時10分01秒 2 0.30 0.00 0.45 0.01 0.00 99.24
23時10分01秒 3 0.14 0.00 0.25 0.01 0.00 99.61
23時10分01秒 4 0.19 0.00 0.33 0.01 0.00 99.48
23時10分01秒 5 0.12 0.00 0.27 0.02 0.00 99.60
平均時間: CPU %user %nice %system %iowait %steal %idle
平均時間: all 0.21 0.00 0.39 0.01 0.00 99.39
平均時間: 0 0.20 0.00 0.42 0.01 0.00 99.36
平均時間: 1 0.33 0.00 0.60 0.01 0.00 99.06
平均時間: 2 0.30 0.00 0.45 0.01 0.00 99.24
平均時間: 3 0.14 0.00 0.25 0.01 0.00 99.61
平均時間: 4 0.19 0.00 0.33 0.01 0.00 99.48
平均時間: 5 0.12 0.00 0.27 0.02 0.00 99.60
┌──[[email protected]]-[~]
系統範圍
vmstat 1 1檢視所有的CPU使用率，id列為系統空閑消耗的總CPU時間的百分比,當等于0的時候，即沒有空閑
可以每秒運作vmstat，然後檢查空閑列，看看還有多少餘量。少于10%可能相關程序存在問題
┌──[[email protected]]-[~]
└─$ vmstat 1 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 23268840 3104 849968 0 0 168 26 239 296 2 3 96 0 0
sar -u的方式，%idle指CPU的空閑率，擷取啟動以來的平均資料
┌──[[email protected]]-[~]
└─$ sar -u
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月05日 _x86_64_ (6 CPU)
22時56分20秒 LINUX RESTART
23時00分01秒 CPU %user %nice %system %iowait %steal %idle
23時10分01秒 all 0.21 0.00 0.39 0.01 0.00 99.39
平均時間: all 0.21 0.00 0.39 0.01 0.00 99.39
dstat 工具，需要單獨裝包，idl:指CPU的空閑率
┌──[[email protected]]-[~]
└─$ dstat -c 1 2
----total-cpu-usage----
usr sys idl wai hiq siq
1 2 97 0 0 0
0 0 99 0 0 0
0 0 100 0 0 0
┌──[[email protected]]-[~]
└─$
每個程序
top指令，%CPU：CPU消耗, 預設會按照CPU用量排序
- 最上面會顯示目前系統平均負載，以及CUP相關的平局值%Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
- 每個程序的CPU用量通過TIME+和%CPU清單示，TIME列顯示了程序自從建立開始消耗的CPU總時間(使用者态+系統态)，格式為“小時：分鐘：秒”。
- Linux上，CPU列顯示了在前一秒内所有CPU上的CPU用量之和。一個單線程的CPU型程序會報告100%。而一個雙線程的CPU型程序則會報告200%。
top - 23:15:42 up 19 min, 1 user, load average: 0.01, 0.05, 0.10
Tasks: 279 total, 1 running, 278 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.2 us, 0.2 sy, 0.0 ni, 99.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 32927488 total, 22911768 free, 8894024 used, 1121696 buff/cache
KiB Swap: 11534328 total, 11534328 free, 0 used. 23608488 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
935 etcd 20 0 10.7g 26756 11124 S 1.3 0.1 0:15.74 etcd
8108 chrony 20 0 863480 578404 9964 S 1.3 1.8 0:30.36 bundle
8112 992 20 0 541256 93800 12008 S 1.3 0.3 0:08.27 prometheus
955 root 20 0 1256580 50788 19868 S 0.3 0.2 0:02.40 containerd
4686 tom 20 0 12.6g 2.9g 26428 S 0.3 9.4 0:49.63 java
8113 chrony 20 0 583592 24052 6168 S 0.3 0.1 0:01.47 gitaly
8121 nginx 20 0 41636 12160 1600 S 0.3 0.0 0:05.71 redis-server
8214 chrony 20 0 2756524 65824 8124 S 0.3 0.2 0:04.84 ruby
。。。。。。。。。。。。。。。。
也可以使用 htop工具
或者 ps ：%CPU
┌──[[email protected]]-[~]
└─$ ps -o pcpu,cmd
%CPU CMD
0.0 /bin/bash /assets/wrapper
0.0 runsvdir -P /opt/gitlab/service log: ................................................................
0.0 /bin/bash /opt/gitlab/bin/gitlab-ctl tail
0.0 /opt/gitlab/embedded/bin/ruby /opt/gitlab/embedded/bin/omnibus-ctl gitlab /opt/gitlab/embedded/servic
0.0 sh -c find /var/log/gitlab -type f -not -path */sasl/* | grep -E -v '(config|lock|@|gzip|tgz|gz)' | x
0.0 xargs tail --follow=name --retry
0.0 tail --follow=name --retry /var/log/gitlab/sshd/current /var/log/gitlab/gitlab-shell/gitlab-shell.log
0.0 -bash
0.0 ps -o pcpu,cmd
pidstat 1 1指令會按照程序列印CPU的用量，包括使用者态和系統态時間的分解，
- %CPU：程序占用cpu的百分比
- CPU：處理程序的cpu編号
┌──[[email protected]]-[~]
└─$ pidstat 1 1
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月05日 _x86_64_ (6 CPU)
23時20分54秒 UID PID %usr %system %guest %CPU CPU Command
23時20分55秒 996 935 0.00 0.99 0.00 0.99 0 etcd
23時20分55秒 998 8108 0.00 0.99 0.00 0.99 2 bundle
23時20分55秒 998 8211 0.99 0.00 0.00 0.99 4 ruby
23時20分55秒 0 11670 0.00 0.99 0.00 0.99 2 pidstat
平均時間: UID PID %usr %system %guest %CPU CPU Command
平均時間: 996 935 0.00 0.99 0.00 0.99 - etcd
平均時間: 998 8108 0.00 0.99 0.00 0.99 - bundle
平均時間: 998 8211 0.99 0.00 0.00 0.99 - ruby
平均時間: 0 11670 0.00 0.99 0.00 0.99 - pidstat
┌──[[email protected]]-[~]
└─$
4CUP 飽和度
一個100%使用率的CPU被稱為是飽和的，線程在這種情況下會碰上排程器延時，因為它們需要等待才能在CPU上運作，降低了總體性能。這個延時是線程花在等待CPU運作隊列或者其他管理線程的資料結構上的時間。
另一個CPU飽和度的形式則和CPU資源控制有關，這個控制會在雲計算環境下發生。盡管CPU并沒有100%地被使用，但已經達到了控制的上限，是以可運作的線程就必須等待輪到它們的機會。這個過程對使用者的可見度取決于使用的虛拟化技術，
一個飽和運作的CPU不像其他類型資源那樣問題重重，因為更高優先級的工作可以搶占目前線程。但往往持續的飽和是存在問題的
系統範圍
vmstat 1 2 虛拟記憶體統計指令，最後的幾列會列印全局範圍的CUP平均負載， 當r > CUP數量即為飽和狀态，列r報告了那些正在等待以及正在CPU上運作的線程。
- r：目前可運作的程序數(運作隊列的長度)。這些程序沒有等待I/0，而是已經準備好運作。理想狀态下，可運作程序數應與可用CPU的數量相等
- b：等待1/0完成的被阻塞程序數
- us：使用者态時間。
- sy：系統态時間(核心)。
- id：空閑。
- wa：等待I/O，即線程被阻塞等待磁盤I/O時的CPU空閑時間。
- st：偷取(未在輸出裡顯示)，CPU在虛拟化的環境下在其他租戶上的開銷。
┌──[[email protected]]-[~]
└─$ vmstat 1 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 22877932 3104 1122588 0 0 74 35 173 246 1 1 98 0 0
0 0 0 22878064 3104 1122592 0 0 0 25 663 1094 0 0 100 0 0
sar -q 系統活動報告器，-q 參數展示包括運作隊列長度列runq-sz(等待數加上運作數，與vmstat的r列相同)和平均負載ldavg-1 ldavg-5 ldavg-15 。當 runq-sz > CUP數量時CPU飽和
┌──[[email protected]]-[~]
└─$ sar -q
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月05日 _x86_64_ (6 CPU)
22時56分20秒 LINUX RESTART
23時00分01秒 runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked
23時10分01秒 1 665 0.11 0.09 0.12 0
23時20分01秒 0 667 0.00 0.03 0.08 0
平均時間: 0 666 0.06 0.06 0.10 0
dstat -p 1 2指令，當run > CPU 數量時，CPU飽和
┌──[[email protected]]-[~]
└─$ dstat -p 1 2
---procs---
run blk new
0 0 7.0
0 0 1.0
0 0 4.0
5記憶體容量使用率
主記憶體的使用率可由已占用的記憶體除以總記憶體得出。檔案系統緩存占用的記憶體可當作未使用，因為它可以被應用程式重用,也可以通過修改核心參數來調整緩存和緩沖區。通過cgroup可以對記憶體資源進行限制。
關于記憶體使用率，前面的建議可得，100%的使用率通常是瓶頸的信号(檢查飽和度并确認其影響)。使用率超過60%可能會是問題，是以對于記憶體平均使用率盡量保持到70%以内，超過70%,考慮擴容。
一般情況下，處于性能考慮，生産環境往往會禁用交換分區，或者通過修改核心參數調整交換頻率，交換分區的意義是為了應付記憶體不足的情況。
是以如果設定了交換分區，往往記憶體不足的一個信号即系統開始使用交換分區，如果記憶體使用率低，是不會使用交換分區的。Linux系統的記憶體使用率高并不一定是壞事，Linux會盡可能的對使用記憶體，提高系統IO的處理效率，一個運作了很久機器，你會發現的buff/cache會占據記憶體很大的一部分。
Linux永遠不會存在因為記憶體不夠而挂調的情況，除非你修改了OOM Killer相關的核心參數，預設情況下，系統的會在記憶體不夠的時候，自動的根據打分殺掉有可能存在記憶體洩露的程序，具體的日志可以通過 /var/log/message 日志檢視。
通過對系統記憶體使用率的檢視，可以在系統資源瓶頸時提早擴容，通過系統記憶體推斷是否存在異常程序
系統範圍
free 指令不多講
┌──[[email protected]]-[~]
└─$ free -m
total used free shared buff/cache available
Mem: 32155 9465 21113 21 1576 22275
Swap: 11263 0 11263
vmstat 指令
- swpd：交換出的記憶體量。
- free：空閑的可用記憶體。
- buff：用于緩沖緩存的記憶體。
- cache：用于頁緩存的記憶體。
- si：換入的記憶體(換頁)。
- so：換出的記憶體(換頁)。
┌──[[email protected]]-[~]
└─$ vmstat 1 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 21617868 3104 1611636 0 0 1 10 7 5 0 0 99 0 0
0 0 0 21617704 3104 1611636 0 0 0 0 718 1068 0 2 98 0 0
如果si和so列一直非0，那麼系統正存在記憶體壓力并換頁到交換裝置或檔案
通過sar -r 可以檢視系統範圍的記憶體使用率
- -B：換頁統計資訊
- -H：大頁面統計資訊
- -r：記憶體使用率
- -R：記憶體統計資訊
- -s：交換空間統計資訊
- -W：交換統計資訊
┌──[[email protected]]-[~]
└─$ sar -r | head -5
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月07日 _x86_64_ (6 CPU)
00時00分01秒 kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
00時10分01秒 21838132 11089356 33.68 3104 1301088 7212724 16.22 9695476 573536 116
00時20分01秒 22002248 10925240 33.18 3104 1251500 7208136 16.21 9575496 531188 60
┌──[[email protected]]-[~]
└─$
- kbmemfree 空閑存儲器/千位元組
- kbmemused 占用存儲器(不包括核心)/千位元組
- kbbuffers 緩沖高速緩存尺寸/千位元組
- kbcached 頁面高速緩存尺寸/千位元組
- kbcommit 送出的主存儲器：服務目前工作負載需要量的估計/千位元組：保證目前系統所需要的記憶體,即為了確定不溢出而需要的記憶體(RAM+swap).
- %commit 為目前工作負載送出的主存儲器，估計值/百分比
- kbactive 活動清單存儲器尺寸/千位元組
- kbinact 非活動清單存儲器尺寸/千位元組
也可以通過dstat 指令來檢視，更直覺一點
┌──[[email protected]]-[~]
└─$ dstat -m 1 2
------memory-usage-----
used buff cach free
9707M 3104k 1338M 20.6G
9707M 3104k 1338M 20.6G
9707M 3104k 1338M 20.6G
┌──[[email protected]]-[~]
└─$
檢查核心程序相關的記憶體資訊 kmem slab使用情況,一般用不到，我現在也看不懂
┌──[[email protected]]-[~]
└─$ slabtop -s c
每個程序
top 指令可以直覺的看到每個程序的記憶體使用，也可以使用靜态的 ps 指令不多講
- %MEM：主存使用(實體記憶體、RSS)占總記憶體的百分比。
- RES：常駐集合大小(KB)。目前使用的記憶體大小
- VIRT：虛拟記憶體大小(KB)：申請的記憶體，包括使用了和沒有使用的
┌──[[email protected]]-[~]
└─$ top
可以看到，第一個程序為etcd，目前申請的虛機記憶體為10.9g，已經使用28384KB的記憶體，共享記憶體為11220KB
也可以通過htop工具來檢視，htop指令會直覺的顯示啟動指令，使用top的需要進去鍵入c鍵
┌──[[email protected]]-[~]
└─$ htop
6記憶體容量飽和度
對記憶體的需求超過了主存的情況被稱作主存飽和。這時作業系統會使用換頁、交換或者在Linux中用O0M終結者來釋放記憶體。以上任一操作都标志着主存飽和。
系統範圍
si so 列出現數值時，以為系統進行交換，記憶體達到飽和
┌──[[email protected]]-[~]
└─$ vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 21614748 3104 1612480 0 0 1 10 8 6 0 0 99 0 0
0 0 0 21614424 3104 1612484 0 0 0 9 930 1522 0 0 100 0 0
1 0 0 21613436 3104 1612484 0 0 0 0 999 1517 0 1 99 0 0
┌──[[email protected]]-[~]
└─$
sar -B 報告的資訊為核心與磁盤之間交換的塊數。此外，對v2.5之後的核心版本，該項報告的資訊為缺頁數量: 這裡沒找到對應的資料。
- pgscank/s:每秒被kswapd掃描的頁個數
- pgscand/s:每秒直接被掃描的頁個數
┌──[[email protected]]-[~]
└─$ sar -B |head -5
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月07日 _x86_64_ (6 CPU)
00時00分01秒 pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
00時10分01秒 0.00 50.77 620.39 0.00 381.90 0.00 0.00 0.00 0.00
00時20分01秒 0.00 68.26 5369.35 0.00 2179.92 0.00 0.00 0.00 0.00
┌──[[email protected]]-[~]
└─$
sar -W報告系統交換的頁數:當有數值時意味系統使用了交換分區
┌──[[email protected]]-[~]
└─$ sar -W | head -5
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月07日 _x86_64_ (6 CPU)
00時00分01秒 pswpin/s pswpout/s
00時10分01秒 0.00 0.00
00時20分01秒 0.00 0.00
┌──[[email protected]]-[~]
└─$
每個程序
如果目前程序存在内記憶體飽和，影響到系統，會觸發記憶體殺手 OOM Killer。可以通過下面的指令檢視日志
┌──[[email protected]]-[~]
└─$ dmesg | grep killed
/proc/PID/stat中第10項(min_flt)7533，可以得次要缺頁中斷的次數，即無需從磁盤加載記憶體頁. 比如COW和匿名頁(這個不懂,先記錄)
┌──[[email protected]]-[~]
└─$ cat /proc/956/stat
956 (etcd) S 1 956 956 0 -1 1077944576 7533 421 90 1 776 68808 0 0 20 0 21 0 881 11699159040 6577 18446744073709551615 94319632281600 94319648442868 140733854974784 140733854974152 94319638032483 0 1006254592 0 2143420159 18446744073709551615 0 0 17 5 0 0 6 0 0 94319650541736 94319659761249 94319676428288 140733854977417 140733854977553 140733854977553 140733854978026 0
- pid： 程序ID.
- comm: task_struct結構體的程序名
- state: 程序狀态, 此處為S
- ppid: 父程序ID (父程序是指通過fork方式，通過clone并非父程序)
- pgrp：程序組ID
- session：程序會話組ID
- tty_nr：目前程序的tty終點裝置号
- tpgid：控制程序終端的前台程序号
- flags：程序辨別位，定義在include/linux/sched.h中的PF_*,
- minflt： 次要缺頁中斷的次數，即無需從磁盤加載記憶體頁. 比如COW和匿名頁
- cminflt：目前程序等待子程序的minflt
- majflt：主要缺頁中斷的次數，需要從磁盤加載記憶體頁. 比如map檔案
- majflt：目前程序等待子程序的majflt
- utime: 該程序處于使用者态的時間，機關jiffies，
- stime: 該程序處于核心态的時間，機關jiffies，
- cutime：目前程序等待子程序的utime
- cstime: 目前程序等待子程序的utime
- priority: 程序優先級, .
- nice: nice值，取值範圍[19, -20]，
- num_threads: 線程個數,
- itrealvalue: 該字段已廢棄，恒等于0
- starttime：自系統啟動後的程序建立時間，機關jiffies，
- vsize：程序的虛拟記憶體大小，機關為bytes
- rss: 程序獨占記憶體+共享庫，機關pages，
- rsslim: rss大小上限
記憶體容量錯誤
OOM killer 也可以直接看日志
┌──[[email protected]]-[~]
└─$ tail -n 5 /var/log/messages
Sep 9 12:18:14 liruilongs kernel: e1000: ens32 NIC Link is Down
Sep 9 12:18:20 liruilongs kernel: e1000: ens32 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Sep 9 12:18:22 liruilongs kernel: e1000: ens32 NIC Link is Down
Sep 9 12:18:26 liruilongs kernel: e1000: ens32 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Sep 9 12:20:01 liruilongs systemd: Started Session 8 of user root.
┌──[[email protected]]-[~]
└─$ dmesg | tail -n 5
[ 45.978294] hrtimer: interrupt took 3043780 ns
[ 3399.493638] e1000: ens32 NIC Link is Down
[ 3405.505696] e1000: ens32 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 3407.509927] e1000: ens32 NIC Link is Down
[ 3411.522461] e1000: ens32 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
┌──[[email protected]]-[~]
└─$
7網絡接口使用率
ip -s link: 使用率計算為：RX/TX: 吞吐量除以最大帶寬，RX代表接收，TX代表發送。檢視最大帶寬的方式:帶寬為 Speed: 1000Mb/s 千兆
┌──[[email protected]]-[~/ansible]
└─$ethtool ens32
Settings for ens32:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
ip -s link部分字段說明
列 說明 bytes 發送或接收的位元組數 packets 發送或接收的資料包數 errors 發送或接收時發生的錯誤數 dropped 由于網卡缺少資源，導緻未發送或接收的資料包數 overruns 網絡沒有足夠的緩沖區空間來發送或接收更多資料包的次數 mcast 已接收的多點傳播資料包的數量 carrier 由于鍊路媒體故障(如故障電纜)而丢棄的資料包數量 collsns 傳送時裝置發生的沖突次數。當多個裝置試圖同時使用網絡時就會發生沖突
┌──[[email protected]]-[/proc]
└─$ ip -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
763056 14652 0 0 0 0
TX: bytes packets errors dropped carrier collsns
763056 14652 0 0 0 0
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:9f:48:81 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
3734602 6125 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2793821 2982 0 0 0 0
。。。。。。。。。。。。
也可以使用sar指令檢視，使用率為： rx/tx kB/s 除以最大帶寬
列 說明 rxpck/s 資料包接收速率 txpck/s 資料包發送速率 rxkB/s kb接收速率 txkB/s kb發送速率 rxcmp/s 壓縮包接收速率 txcmp/s 壓縮包發送速率 rxmcst/s 多點傳播包接收速率
┌──[[email protected]]-[/proc]
└─$ sar -n DEV
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
22時20分01秒 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
22時30分01秒 vethe257c0b 0.01 0.01 0.00 0.00 0.00 0.00 0.00
22時30分01秒 br-4b3da203747c 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22時30分01秒 ens32 0.02 0.02 0.00 0.00 0.00 0.00 0.00
。。。。。。。
平均時間: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
平均時間: vethe257c0b 0.01 0.01 0.00 0.00 0.00 0.00 0.00
平均時間: br-4b3da203747c 0.00 0.00 0.00 0.00 0.00 0.00 0.00
平均時間: ens32 0.55 0.73 0.04 1.00 0.00 0.00 0.00
平均時間: br-0e0cdf9c70b0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
平均時間: vethcb79321 0.00 0.00 0.00 0.00 0.00 0.00 0.00
平均時間: lo 0.13 0.13 0.01 0.01 0.00 0.00 0.00
平均時間: docker0 0.01 0.01 0.00 0.00 0.00 0.00 0.00
┌──[[email protected]]-[/proc]
└─$
檢視核心問題的方式，/proc/net/dev，Receive/Transmit 吞吐量位元組數除以最大值,不知道這裡的最大值什麼?
┌──[[email protected]]-[/proc]
└─$ cat /proc/net/dev | head -n 5
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
vethe257c0b: 74504 1362 0 0 0 0 0 0 3321668 1387 0 0 0 0 0 0
br-4b3da203747c: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ens32: 3749200 6320 0 0 0 0 0 0 2823625 3102 0 0 0 0 0 0
┌──[[email protected]]-[/proc]
└─$
8網絡接口飽和度
網絡接口飽和度通過下面兩項排查，當有值時，說明存在網絡接口飽和
- overruns 網絡沒有足夠的緩沖區空間來發送或接收更多資料包的次數
- dropped發送或接收時丢棄的資料包數
┌──[[email protected]]-[/proc]
└─$ ifconfig ens32
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.26.55 netmask 255.255.255.0 broadcast 192.168.26.255
inet6 fe80::20c:29ff:fe9f:4881 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:9f:48:81 txqueuelen 1000 (Ethernet)
RX packets 6414 bytes 3756184 (3.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3157 bytes 2834195 (2.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
或者通過netstat -s的方式查詢，這個對應名額值不太清楚
┌──[[email protected]]-[/proc]
└─$ netstat -s
Ip:
19334 total packets received
545 forwarded
0 incoming packets discarded
18786 incoming packets delivered
17742 requests sent out
4 dropped because of missing route
。。。。。
9網絡接口錯誤
ifconfig ens32 : errors項，dropped項檢視錯包和丢包的情況
┌──[[email protected]]-[/proc]
└─$ ifconfig ens32
ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.26.55 netmask 255.255.255.0 broadcast 192.168.26.255
inet6 fe80::20c:29ff:fe9f:4881 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:9f:48:81 txqueuelen 1000 (Ethernet)
RX packets 6709 bytes 3778697 (3.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3327 bytes 2860201 (2.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
RX-ERR/TX-ERR
┌──[[email protected]]-[/proc]
└─$ netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
br-0e0cdf9c70b0 1500 6728 0 0 0 3339 0 0 0 BMU
br-4b3da203747c 1500 1368 0 0 0 1393 0 0 0 BMU
docker0 1500 1368 0 0 0 1388 0 0 0 BMRU
ens32 1500 6728 0 0 0 3339 0 0 0 BMRU
lo 65536 14760 0 0 0 14760 0 0 0 LRU
vethcb79321 1500 0 0 0 0 11 0 0 0 BMRU
vethe257c0b 1500 1368 0 0 0 1393 0 0 0 BMRU
errors dropped
┌──[[email protected]]-[/proc]
└─$ ip -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
768880 14764 0 0 0 0
TX: bytes packets errors dropped carrier collsns
768880 14764 0 0 0 0
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:9f:48:81 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
3787251 6822 0 0 0 0
TX: bytes packets errors dropped carrier collsns
2868359 3393 0 0 0 0
..............
sar -n EDEV :顯示每個網卡的發送和接收錯誤資訊
┌──[[email protected]]-[/proc]
└─$ sar -n EDEV | head -n 5
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
22時20分01秒 IFACE rxerr/s txerr/s coll/s rxdrop/s txdrop/s txcarr/s rxfram/s rxfifo/s txfifo/s
22時30分01秒 vethe257c0b 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22時30分01秒 br-4b3da203747c 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
通過核心檔案/proc/net/dev中的errs，drop項可以檢視錯誤的和丢棄的包
┌──[[email protected]]-[/proc]
└─$ cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
vethe257c0b: 74662 1365 0 0 0 0 0 0 3321806 1390 0 0 0 0 0 0
br-4b3da203747c: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ens32: 3773382 6641 0 0 0 0 0 0 2850239 3284 0 0 0 0 0 0
br-0e0cdf9c70b0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
vethcb79321: 0 0 0 0 0 0 0 0 878 11 0 0 0 0 0 0
lo: 767008 14728 0 0 0 0 0 0 767008 14728 0 0 0 0 0 0
docker0: 55552 1365 0 0 0 0 0 0 3321416 1385 0 0 0 0 0 0
10磁盤IO使用率
系統範圍
通過 iostat的檢視磁盤統計資訊
一般%util 使用率 大于70%,I/O壓力就比較大，讀取速度有較多的wait。
┌──[[email protected]]-[/proc]
└─$ iostat -xz 1 1
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.18 0.00 0.39 0.01 0.00 99.41
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.17 0.49 2.01 7.53 57.35 51.85 0.00 1.68 5.02 0.86 0.54 0.13
┌──[[email protected]]-[/proc]
└─$
統計資料 說明 rrqm/s 在送出給磁盤前，被合并的讀請求的數量 wrqm/s 在送出給磁盤前，被合并的寫請求的數量 r/s 每秒送出給磁盤的讀請求數量 w/s 每秒送出給磁盤的寫請求數量 rsec/s 每秒讀取的磁盤扇區數 wsec/s 每秒寫入的磁盤扇區數 rkB/s 每秒從磁盤讀取了多少KB的資料 wkB/s 每秒向磁盤寫入了多少KB的資料 avgrq-sz 磁盤請求的平均大小(按扇區計) avgqu-sz 磁盤請求隊列的平均大小。 await 完成對一個請求的服務所需的平均時間(按毫秒計),該平均時間為請求在磁盤隊列中等待的時間加上磁盤對其服務所需的時間 svctm 送出到磁盤的請求的平均服務時間(按毫秒計)。該項表明磁盤完成一個請求所花費的平均時間。與await不同，該項不包含在隊列中等待的時間 %util 使用率
┌──[[email protected]]-[/proc]
└─$ sar -d
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
22時20分01秒 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
22時30分01秒 dev8-0 2.34 0.03 149.81 64.13 0.00 1.56 0.54 0.13
22時40分01秒 dev8-0 2.44 5.65 146.44 62.38 0.00 1.60 0.56 0.14
22時50分01秒 dev8-0 2.39 0.00 152.13 63.70 0.00 0.86 0.45 0.11
23時00分01秒 dev8-0 2.36 2.28 141.90 61.01 0.00 0.91 0.49 0.12
23時10分01秒 dev8-0 2.31 2.89 135.45 59.94 0.00 1.39 0.57 0.13
平均時間: dev8-0 2.37 2.17 145.15 62.24 0.00 1.27 0.52 0.12
┌──[[email protected]]-[/proc]
└─$
每個程序
檢視每個程序的磁盤使用率可以通過iotop指令來檢視
前兩行READ和WRITE為讀寫速率總計
程序清單的含義：
- tid：線程id，按p可轉換程序pid
- PRIO：優先級
- DISK READ：磁盤讀取速率
- DISK WRITE：磁盤寫取速率
- SWAPIN：用了多少交換分區
- IO>：IO等待所占用百分比(該程序占磁盤使用率的百分比)
- COMMAND：線程/程序詳細資訊(TID對應的程序名稱)
也可以檢視運作生成核心參數/proc/956/sched,但是這裡并沒有找到書裡講的核心參數值，可能是版本的問題
┌──[[email protected]]-[/proc]
└─$ cat /proc/956/sched
etcd (956, #threads: 22)
-------------------------------------------------------------------
se.exec_start : 13685.700041
se.vruntime : 43.362799
se.sum_exec_runtime : 258.986765
se.nr_migrations : 65
nr_switches : 368
nr_voluntary_switches : 227
nr_involuntary_switches : 141
se.load.weight : 1024
policy : 0
prio : 120
clock-delta : 116
mm->numa_scan_seq : 0
numa_migrations, 0
numa_faults_memory, 0, 0, 1, 0, -1
numa_faults_memory, 1, 0, 0, 0, -1
┌──[[email protected]]-[/proc]
└─$
11磁盤IO飽和度
當avgqu-sz的值特别大的時候，且請求等待時間await遠遠高于請求服務svctm所花費時間，且使用率%util為100%的時候，表明該磁盤處于飽和狀态。産生的I/O請求太多,I/O系統已經滿負載,I/O隊列太長
iostat可以顯示每個盤的名額值
┌──[[email protected]]-[/proc]
└─$ iostat -xNz 1 1
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.18 0.00 0.39 0.01 0.00 99.41
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.17 0.54 2.01 8.58 57.83 52.07 0.00 1.65 4.61 0.86 0.53 0.14
sar -d的方式顯示目前系統所有盤的資料彙總
┌──[[email protected]]-[/proc]
└─$ sar -d
Linux 3.10.0-1160.71.1.el7.x86_64 (liruilongs.github.io) 2022年09月13日 _x86_64_ (6 CPU)
22時20分01秒 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
22時30分01秒 dev8-0 2.34 0.03 149.81 64.13 0.00 1.56 0.54 0.13
22時40分01秒 dev8-0 2.44 5.65 146.44 62.38 0.00 1.60 0.56 0.14
22時50分01秒 dev8-0 2.39 0.00 152.13 63.70 0.00 0.86 0.45 0.11
23時00分01秒 dev8-0 2.36 2.28 141.90 61.01 0.00 0.91 0.49 0.12
23時10分01秒 dev8-0 2.31 2.89 135.45 59.94 0.00 1.39 0.57 0.13
23時20分01秒 dev8-0 2.09 0.24 130.58 62.59 0.00 0.89 0.53 0.11
23時30分01秒 dev8-0 11.65 410.73 281.56 59.40 0.01 0.70 0.33 0.38
平均時間: dev8-0 3.65 60.26 162.55 60.98 0.00 0.98 0.43 0.16
┌──[[email protected]]-[/proc]
└─$
關于 Linux 性能檢視，USE方法就和小夥伴們分享到這，這裡隻展示了部分可以查到名額查找方式，大部分名額沒有展示。
12博文内容參考
《Linux性能優化》 (美)菲利普G.伊佐特 著；賀蓮 龔奕利 譯
《性能之巅：洞悉系統、企業與雲計算》(美)格雷格(Gregg，B.)著；徐章甯，吳寒思，陳磊 譯
Linux常用監控指令:https://www.cnblogs.com/chuyiwang/p/7111522.html
/proc/stat解析:https://blog.csdn.net/houzhizhen/article/details/119948608
在 Linux 中如何使用 iotop 和 iostat 監控磁盤 I/O 活動？:https://linux.cn/article-10815-1.html