投稿
  1. 簡單一點首頁
  2. 投稿

看懂電腦cpu型號參數及性能「cpu性能怎麼看好壞」

投稿專員 • • 投稿

大家好，上一期給大家介紹了如何使用lttng以及log可以更好地分析ceph的運作模式，今天再給大家介紹一下如何使用性能分析工具觀察cpu性能指標~

平均負載

前言：為了更好配置分散式儲存集群的運行參數，使用性能分析工具觀察業務環境是一種必要的手段。

top或者uptime


02:34:03//當前時間
up 2 days,20:14//系統運行時間
1 user                //正在登錄用戶數


load average:0.63,0.83,0.88
依次則是過去1分鐘、5分鐘、15分鐘的平均負載（LoadAverage）

平均負載是指單位時間內，系統處於可運行狀態和不可中斷狀態的平均進程數，也就是平均活躍進程數，它和CPU使用率並沒有直接關係，所以，它不僅包括了正在使用CPU的進程，還包括等待CPU和等待I/O的進程。

如何使用性能分析工具觀察cpu性能指標

可運行狀態

可運行狀態的進程，是指正在使用CPU或者正在等待CPU的進程，也就是我們常用ps命令看到的，處於R狀態（Running或Runnable）的進程。

可中斷的睡眠狀態的進程會睡眠直到某個條件變為真，如產生一個硬體中斷、釋放進程正在等待的系統資源或是傳遞一個信號都可以是喚醒進程的條件。

不可中斷狀態

不可中斷狀態的進程則是正處於內核態關鍵流程中的進程，並且這些流程是不可打斷的。

那就是把信號傳遞到這種睡眠狀態的進程不能改變它的狀態，也就是說它不響應信號的喚醒。

比如，當一個進程向磁碟讀寫數據時，為了保證數據的一致性，在得到磁碟回復前，它是不能被其他進程或者中斷打斷的，這個時候的進程就處於不可中斷狀態。如果此時的進程被打斷了，就容易出現磁碟數據與進程數據不一致的問題。所以，不可中斷狀態實際上是系統對進程和硬體設備的一種保護機制。

既然平均的是活躍進程數，那麼最理想的，就是每個CPU上都剛好運行著一個進程，這樣每個 CPU 都得到了充分利用。

比如當平均負載為2時，意味著什麼呢？

  • 在只有2個CPU的系統上，意味著所有的CPU都剛好被完全佔用。
  • 在4個CPU的系統上，意味著CPU有50%的空閑。
  • 而在只有1個CPU的系統中，則意味著有一半的進程競爭不到CPU。====》 （平均負載比cpu個數大，過載）

所以，平均負載最理想的情況是等於CPU個數。

grep 'model name'/proc/cpuinfo | wc -l //可查看cpu數目

12//12核

如何觀察數值


//假設單核情況
root@xxxx:~# uptime
09:28:31 up 1 day, 10:31,  2 users,  load average: 1.96, 1.29, 1.59

假設是單核情況下，1分鐘下來有96%超載，5分鐘下來有29%超載，15分鐘下來有59%超載。

  • 當三者相差不大，說明系統的平均負載穩定。
  • 當前1分鐘比後兩者小的時候，說明系統趨於降低。
  • 如果1分鐘的值遠大於15分鐘的值，就說明最近1分鐘的負載在增加。

經驗值之談，一旦平均負載達到CPU數量的前後75%左右，需要排查負載高的問題。

平均負載與 CPU 使用率區別

CPU使用率，是單位時間內CPU繁忙情況的統計，跟平均負載並不一定完全對應；

CPU使用率：單位時間內cpu繁忙情況的統計。

  • 情況1：CPU密集型進程，CPU使用率和平均負載基本一致。
  • 情況2：IO密集型進程，平均負載升高，CPU使用率不一定升高。
  • 情況3：大量等待CPU的進程調度，平均負載升高，CPU使用率也升高。

場景模擬

借用iostat mpstat pidstat可以分析出平均負載升高的原因。

模擬一下使用場景：


root@xxxx:~# apt install sysstat //常用的 Linux 性能工具，用來監控和分析系統的性能,包含兩個命令 mpstat 和 pidsta
root@xxxx:~# apt install stress //一個 Linux 系統壓力測試工具

前提環境：

機器配置：4 CPU，8GB 內存。



root@xxxx:~# uptime
11:36:37 up 13 days,29 min,3 users,  load average:0.06,0.06,0.01
  • CPU 的用戶層（%usr）使用率；
  • CPU 的系統層（%sys）使用率；
  • CPU 的 I/0 – 等待（%iowait）；
  • CPU 的空閑率（%idle);

首先，我們在第一個終端運行stress命令，模擬一個CPU使用率100%的CPU密集型進程場景：


//一終端執行
root@xxxx:~# stress --cpu 4 --timeout 555
stress: info: [4563] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd
//另一終端
root@xxxx:~# watch -d uptime
Every 2.0s: uptime xxxx: Tue Dec 22 11:43:36 2020
 11:43:36 up 13 days, 36 min,  3 users,  load average:  4.13, 1.28, 0.46
// 另一終端2
//-P ALL 表示監控所有CPU，後面數字5表示間隔5秒後輸出一組數據
root@xxxx:~# mpstat -P ALL 5
11:45:26 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
11:45:31 AM  all   99.65    0.00    0.25    0.00    0.00    0.10    0.00    0.00    0.00    0.00
11:45:31 AM    0   99.40    0.00    0.40    0.00    0.00    0.20    0.00    0.00    0.00    0.00
11:45:31 AM    1   99.60    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00    0.00
11:45:31 AM    2   99.80    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00
11:45:31 AM    3   99.80    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00    0.00
//從這裡可以明顯看到，stress 進程的 CPU 使用率接近 100%。
root@xxxx:~# pidstat -u 5 1
Linux 4.15.0-66-generic (xxxx)     12/22/2020      _x86_64_        (4 CPU)
11:48:58 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
11:49:03 AM     0      2049    0.00    0.20    0.00    0.00    0.20     2  kworker/2:0
11:49:03 AM 64045      3358    0.60    0.20    0.00    0.00    0.80     3  ceph-mon
11:49:03 AM     0      4564   98.41    0.20    0.00    1.39   98.61     0  stress
11:49:03 AM     0      4565   98.81    0.00    0.00    0.99   98.81     1  stress
11:49:03 AM     0      4566   98.21    0.00    0.00    1.39   98.21     0  stress
11:49:03 AM     0      4567   99.20    0.00    0.00    0.60   99.20     2  stress
11:49:03 AM     0      5131    0.20    0.20    0.00    0.40    0.40     0  watch
11:49:03 AM     0      7419    0.20    0.40    0.00    0.00    0.60     3  pidstat
11:49:03 AM     0     26649    0.00    0.20    0.00    0.00    0.20     0  kworker/0:1
11:49:03 AM     0     26658    0.20    0.20    0.00    0.20    0.40     1  sshd
11:49:03 AM 64045     30555    0.60    0.00    0.00    0.00    0.60     1  ceph-osd
//

可以從load average: 4.13以及mpstat 的usr看得出負載場景基本符合CPU密集型進程，pidstat可以看得出是stress導致佔用率過高。

然後模擬一個I/O密集型進程：


//一終端執行
//root@xxxx:~# stress -i 1 --timeout 600  // 因為 stress 使用的sync系統調用，刷新緩衝區到磁碟。有可能因緩衝區數據量小無法看到io_wait明顯變化
root@xxxx:~# stress-ng -i 1 --hdd 1 --timeout 555
stress-ng: info:  [9211] dispatching hogs: 1 io, 1 hdd
//另一終端
root@xxxx:~# watch -d uptime
 16:46:09 up 13 days,  5:38,  3 users,  load average: 2.91, 2.56, 1.10
// 另一終端2
//-P ALL 表示監控所有CPU，後面數字5表示間隔5秒後輸出一組數據
root@xxxx:~# mpstat -P ALL 5
Linux 4.15.0-66-generic (ECSab169d)     12/22/2020      _x86_64_        (4 CPU)
04:44:02 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
04:44:07 PM  all    1.35    0.00   29.50   26.74    0.00    0.21    0.52    0.00    0.00   41.68
04:44:07 PM    0    2.05    0.00   30.12   26.23    0.00    0.20    0.61    0.00    0.00   40.78
04:44:07 PM    1    0.40    0.00   30.51   51.72    0.00    0.00    0.81    0.00    0.00   16.57
04:44:07 PM    2    0.84    0.00   19.29   19.08    0.00    0.00    0.42    0.00    0.00   60.38
04:44:07 PM    3    1.96    0.00   38.26    8.48    0.00    0.65    0.22    0.00    0.00   50.43
root@xxxx:~# pidstat -u 5 1
04:43:15 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
04:43:20 PM     0       388    0.00    0.20    0.00    0.00    0.20     0  kworker/0:1H
04:43:20 PM     0     11841    0.00    2.00    0.00    0.00    2.00     1  kworker/1:2
04:43:20 PM     0     12449    0.00    5.40    0.00    0.40    5.40     1  stress-ng-io
04:43:20 PM     0     12450    2.60   60.20    0.00    0.80   62.80     0  stress-ng-hdd
04:43:20 PM     0     22527    0.20    0.20    0.00    0.00    0.40     1  sshd
04:43:20 PM 64045     30555    0.20    0.40    0.00    0.00    0.60     1  ceph-osd

從這裡可以看到，1分鐘的平均負載會慢慢增加到2.91，其中一個CPU的系統CPU使用率升高到了30.51，而iowait高達51.72%。這說明，平均負載的升高是由於iowait的升高,pidstat定位到stress進程。

模擬一個大量進程場景：


//一終端執行
root@xxxx:~# stress -c 8 --timeout 555
17:00:26 up 13 days,  5:53,  3 users,  load average: 7.90, 4.95, 3.04
//另一終端
root@xxxx:~# watch -d uptime
17:00:49 up 13 days,  5:53,  3 users,  load average: 7.94, 5.20, 3.17
root@xxxx:~# pidstat -u 5 1
04:43:15 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
04:43:20 PM     0       388    0.00    0.20    0.00    0.00    0.20     0  kworker/0:1H
04:43:20 PM     0     11841    0.00    2.00    0.00    0.00    2.00     1  kworker/1:2
04:43:20 PM     0     12449    0.00    5.40    0.00    0.40    5.40     1  stress-ng-io
04:43:20 PM     0     12450    2.60   60.20    0.00    0.80   62.80     0  stress-ng-hdd
04:43:20 PM     0     22527    0.20    0.20    0.00    0.00    0.40     1  sshd
04:43:20 PM 64045     30555    0.20    0.40    0.00    0.00    0.60     1  ceph-osd
05:01:33 PM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
05:01:38 PM 64045      3358    0.40    0.20    0.00    0.00    0.60     3  ceph-mon
05:01:38 PM     0      5131    0.60    0.20    0.00    0.60    0.80     1  watch
05:01:38 PM     0      9303    0.00    0.20    0.00    0.00    0.20     2  kworker/u8:3
05:01:38 PM     0     13169    0.00    0.20    0.00    0.00    0.20     0  kworker/0:2
05:01:38 PM     0     18138   48.91    0.00    0.00   51.09   48.91     1  stress
05:01:38 PM     0     18139   49.11    0.00    0.00   50.70   49.11     2  stress
05:01:38 PM     0     18140   48.71    0.00    0.00   50.89   48.71     0  stress
05:01:38 PM     0     18141   50.10    0.00    0.00   49.50   50.10     3  stress
05:01:38 PM     0     18142   47.91    0.00    0.00   51.89   47.91     3  stress
05:01:38 PM     0     18143   49.11    0.00    0.00   51.09   49.11     1  stress
05:01:38 PM     0     18144   52.29    0.00    0.00   47.71   52.29     0  stress
05:01:38 PM     0     18145   49.30    0.00    0.00   50.70   49.30     2  stress
05:01:38 PM     0     20608    0.00    0.20    0.00    0.20    0.20     0  pidstat
05:01:38 PM     0     22527    0.00    0.20    0.00    0.00    0.20     2  sshd
05:01:38 PM 64045     30555    0.40    0.00    0.00    0.00    0.40     1  ceph-osd

可以看出，8個進程在爭搶4個CPU，每個進程等待CPU的時間（也就是代碼塊中的 %wait 列）高達50%。這些超出CPU計算能力的進程，最終導致CPU過載。

總結

  • CPU密集型進程: 查看mpstat是否存在某個CPU %usr 很高但是iowait很低 ， pidstat 定位具體進程（瓶頸不在io）；
  • IO密集型進程：mpstat 觀察是否有某個cpu的%iowait很高，同時%usr也較高， pidstat 定位具體進程；
  • 大量進程 ：觀察mpstat有可能iowait 很低， 但是從pidstat看出%wait很高，側面表現出進程出現競爭cpu。

用到命令

  • lscpu、grep 『model name』 /proc/cpuinfo | wc -l ：cpu核數；
  • watch -d uptime：持續觀察平均負載；
  • pidstat -u 5 1：監測進程對應負載狀態，進程性能分析工具；
  • mpstat -P ALL 5：cpu總體狀態 多核cpu性能分析工具，-P ALL監視所有cpu；
  • strees : -c 產生多個worker進程；—cpu-method 使用哪種演算法來運行壓力測試，包括pi, crc16, fft等等，all選擇全部；—sock 調用socket相關函數產生壓力; -t, —timeout 等待xx微秒後才開始運行；-i, —io N spawn N workers spinning on sync()。

以上就是本期使用lttng以及log可以更好地分析ceph的運作模式的全部內容，下一期將帶大家了解如何使用Vscode結合docker進行開發，敬請期待~

原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/250412.html

贊 (0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
投稿專員的頭像投稿專員
0 0
上一篇 2024-12-13 13:31
下一篇 2024-12-13 13:31

相關推薦

發表回復

登錄後才能評論