性能分析之Linux系統平均負載案例分析

前言

準備工作

測試環境

工具介紹

工具安裝

其它工作

前言

準備工作

測試環境

工具介紹

工具安裝

其它工作

案例分析

場景一：CPU密集型進程

場景二：I/O 密集型進程場景

場景三：大量進程

小結

前言

在上文性能基礎之理解linux系統平均負載和CPU使用率中，我們詳細介紹了 Linux 系統平均負載的相關概念，本文我們來做幾個案例分析，以達到加深理解。

準備工作

測試環境

操作系統：CentOS 7.2 雙核

監控工具：iotop、htop、top、uptime、sysstat

壓測工具：stress

# 獲得物理cpu核心的數量 [zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | wc -l 2 # 獲取邏輯cpu數量(包括超線程邏輯cpu數量) [zzw@7dgroup2 ~]$ lscpu -p | egrep -v '^#' | sort -u -t, -k 2,4 | wc -l 1

工具介紹

iotop 是一個用來監視磁盤 I/O 使用狀況的 top 類工具

htop 是一款運行于 Linux 系統監控與進程管理軟件，用于取代 Linux 下傳統的 top。與 top 只提供最消耗資源的進程列表不同，htop 提供所有進程的列表，并且使用彩色標識出處理器、swap 和內存狀態。

stress 是一個 Linux 系統壓力測試工具，一個 Posix 系統下生成Cpu/Menory/IO/Disk 負載的工具。

sysstat 包含了常用的 Linux 性能工具，用來監控和分析系統命令。

工具安裝

# 安裝stress sudo yum install -y epel-release sudo yum install -y stress # 安裝iotop sudo yum install -y iotop # 安裝htop sudo yum install -y htop # 安裝sysstat sudo yum install -y sysstat

其它工作

我們打開五個終端，登錄到同一臺 Linux 機器中。

終端一：stress 模擬 Linux 壓測場景

終端二：top 監控進程狀況

終端三：iotop 監控進程 I/O 使用狀況

終端四：htop 監控進程詳細狀況

終端五：mpstat 監控系統 iowait 詳細狀況

案例分析

上面所有準備工作都已經完成了，我們首先使用 uptime 命令看下當前 Linux 的平均負載情況

[zzw@7dgroup2 ~]$ uptime 20:12:34 up 148 days, 3:09, 7 users, load average: 0.06, 0.10, 0.13

場景一：CPU密集型進程

首先，我們在終端一運行 stress 命令，模擬一個 CPU 使用率 100% 的場景。

# 模擬一個CPU使用率100%的場景。 [zzw@7dgroup2 ~]$ stress --cpu 1 --timeout 600 stress: info: [2395] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

在終端二查看當前 CPU 使用率及平均負載情況，我們可以看到1分鐘的平均負載已經慢慢增加到 1.11，而其中一個CPU1 User使用率已到達 72%。

在終端五我們發現系統的 iowait 幾乎為 0。這說明，平均負載的升高正是由于 CPU User使用率升高導致的。這個罪魁禍首正是 PID 為 9717 的 stress 進程。

在終端四上通過 htop 我們也可以很直觀了解當前的負載情況，此處我們看到 CPU User使用率顏色是綠色偏高。

場景二：I/O 密集型進程場景

我們繼續在終端一運行 stress 命令，模擬 I/O 壓力，即不停的執行 sync

# 模擬 I/O 壓力，不停的執行 sync [zzw@7dgroup2 ~]$ stress -i 1 --timeout 600 stress: info: [11041] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

在終端二查看當前 CPU 使用率及平均負載情況，我們可以看到1分鐘的平均負載已經慢慢增加到 1.25，而CPU0 System使用率為 68%

在終端五，我們發現兩個CPU 都出現了 iowait。這說明，系統平均負載升高是由于 iowait 升高造成的。

那么到底是哪個進程？在終端三上我們通過 iotop 發現有兩個進程在大量執行 IO 寫操作，結合 top S列（進程狀態代碼）使用情況（R和D，即可運行狀態和不可中斷狀態）我們可以發現還是 PID 為 19241 的 stress 進程引起的。

如下圖，當我們停止 stress 進程后的狀況。

通過終端四的 htop 我們也可以很直觀了解當前的負載情況，此處我們看到 CPU 使用率顏色是紅色偏高。

場景三：大量進程

當系統中運行的進程數超過 CPU 運行能力時，就會出現等待 CPU 的進程。此處，我們還是使用 stress 模擬 4 個進程。

[zzw@7dgroup2 ~]$ stress -c 4 --timeout 600 stress: info: [13473] dispatching hogs: 4 cpu, 0 io, 0 vm, 0 hdd

由于系統只有 2 個 CPU，明顯比 4 個進程要少得多，因此系統 CPU 處于嚴重過載狀態，平均負載高達

4.30

進一步查看運行隊列的長度（等待運行的進程數），可以看出，stress 進程們在瘋狂的爭奪 2 個CPU，這就導致出現運行隊列過大，這些超出 CPU 計算能力的進程，最終導致系統過載。

以下是使用 vmstat 命令。

在終端四上通過 htop 我們也可以很直觀了解當前的負載情況，此處我們看到 CPU User使用率顏色是綠色偏高。

小結

平均負載提供了一個快速查看系統整體性能的手段，反映了系統的整體負載狀況。但并不能跟CPU使用率并不一定完全對應。比如：

CPU 密集型進程，使用大量 CPU 會導致平均負載升高，這時候兩者是一致的。

I/O 密集型進程，等待 I/O 也會導致平均負載升高，但 CPU 使用率不一定很高。

大量等待 CPU 的進程調度也會導致平均負載很高，此時的 CPU 使用率也會比較高

另外，htop 根據不同類型的負載加以顏色區別（F2可以自定義）。比如 CPU 密集應用，它的負載顏色是綠色偏高，iowait 的操作，它的顏色是紅色偏高。

最后附一張經典性能分析思路圖：

簡單概況,即操作系統（CPU/IO/Mem/Net)->進程->線程->堆棧->代碼，如果 CPU 和 I/O 同時出現高的情況，先看 I/O。

IoT Linux 云性能測試服務 CPTS 任務調度

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。