linux效能監控(cpu 記憶體 磁碟IO 網路)
阿新 • • 發佈：2019-02-20
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
《Linux 系統和網路效能監測》
讀
書
筆
記
By:星星 from www.xnlinux.cn
0
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
1.0 效能監測簡介
效能調優是找出系統瓶頸並消除這些瓶頸的過程。 很多系統管理員認為效能調優僅僅是
調整一下核心的引數即可解決問題, 事實上情況並不是這樣。 效能調優是實現作業系統的各
個子系統之間的平衡性,這些子系統包括:
* CPU
* Memory
* IO
* Network
子系統之間相互依存,任何一個子系統的負載過度都能導致其他子系統出現問題,例如:
* 大量的 page-in IO 請求可能導致記憶體佇列被塞滿
* 網絡卡的巨量吞吐可能導致 CPU 資源耗盡
* 系統嘗試保持釋放記憶體佇列時可能耗盡 CPU 資源
* 來自記憶體的大量磁碟寫入請求可能導致 CPU 資源和 IO 通道耗盡
效能調優的前提是找出系統瓶頸之所在, 儘管問題看似由某個子系統所導致, 然而這很
可能是另外一個子系統的過載所引起的。
1.1 判定應用的型別
為了明白從何處開始著手調整效能瓶頸, 弄清被分析系統的效能表現是首要任務。 任何
系統的應用常可分為以下兩類:
* IO 限制型——一個 IO 限制型的應用需要大量的記憶體和基礎儲存裝置佔用。 因其需要
大量的資料讀寫請求,此類應用對 CPU 和網路需求不高(除非儲存系統在網路上) 。
IO 限制型應用使用 CPU 資源來進行 IO 操作且常進入睡眠狀態。 資料庫應用常被認為
屬於此類。
* CPU 限制型——一個 CPU 限制型應用需要大量的 CPU 資源,來進行批量的處理或
大量的計算。大容量 web 服務,mail 服務,以及任何型別的渲染服務都被歸到此類。 mail
1.2 判定基準資訊
系統的利用率因管理員的期望值和系統的引數值而異, 判斷一個系統是否有效能問題的
唯一途徑是弄清楚對系統的期望是神馬, 需求的效能是神馬, 應該得到的資料是神馬?而為
了建立這些資訊的唯一途徑是為系統建立一個基準。 在效能可接受的狀態下必須為系統建立
統計資訊,這樣就可以在效能不可接受時進行對比。
在下面的例子中,將對兩種狀態下的統計資訊進行對比:
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99
0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45
1
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100
0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80
0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75
1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72
0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96
2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0
3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0
2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0
2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0
2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0
2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0
2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0
2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0
只需要看代表 idle 時間的最後一列(id)就能發現問題,在基準資料中 CPU 空閒時間在
79%-100%之間,在高負荷狀態下系統利用率 100%且無空閒。需要考慮的是 CPU 這塊的問
題。
2.0 安裝監測工具
大多*nix 系統均自帶了很多標準監測命令,也有的是第三方工具:
工具名稱 描述 基礎安裝包 可選安裝包
多功能
vmstat Y Y
CPU 效能
mpstat N Y
多功能
sar N Y
磁碟效能
iostat N Y
網路效能
netstat Y Y
多功能 大多數
dstat N
流量監測
iptraf N Y
網路頻寬 大多數
netperf N
網絡卡監測
ethtool Y Y
網路頻寬
iperf N Y
資料包監測
tcptrace N Y
IO 監測
iotop N Y
2
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
3.0 CPU 介紹
CPU 利用率很大部分取決於試圖訪問它的資源,核心擁有一個管理兩種資源的排程器:
執行緒(單或多)和中斷。排程器給予不同資源以不同的優先順序,以下由優先順序從高到低:
* 中斷——裝置通知核心它們處理完成。例如網絡卡傳送一個數據包或硬碟驅動器提供
一次 IO 請求
* 核心(系統)程序——所有的核心程序都在此級別的優先順序進行處理
* 使用者程序——通常被稱為“使用者空間” ,所有應用軟體執行在使用者空間,擁有最低的
優先順序
為了弄明白核心是如何管理不同的資源的,幾個關鍵概念需要提及一下: context
switches,run queues,utilization。
3.1 Context Switches(上下文切換)
大多數處理器在同一時間只能處理一個程序或執行緒,多執行緒處理器可同時處理 n 個線
程。然而,linux 核心把多核處理器的各個核心當做獨立核心。例如,核心把一個雙核的處
理當做兩個獨立處理器。
一個標準的核心可同時處理 50 到 50000 個程序,在只有一顆 CPU 的情況下,核心必須排程
和平衡這些程序和執行緒。 每個執行緒在處理器上都擁有一個時間分配單元, 當一個執行緒超過自
己的時間單元或被更高優先順序的程式搶佔時, 此執行緒及被傳回佇列而此時更高優先順序的程式
將在處理器上執行。這種執行緒間的切換操作即是上下文切換。
3.2 執行佇列
每個 CPU 維持著一個執行緒的執行佇列,理論上,排程器應該是不斷地執行和執行執行緒。
執行緒要麼處於睡眠狀態,要麼處於可執行狀態。假如 CPU 子系統處於高負載狀態,那麼內
核排程器罷工是有可能的, 其結果將導致可執行狀態的程序開始阻塞執行佇列。 執行佇列越
大,執行程序所花費的時間也越長。
一個很流行的術語叫“load(負載) ”經常被用來描述執行佇列的狀態,系統負載是由正在
執行的程序和 CPU 執行佇列中的程序的結合,如果有 2 個執行緒正在一個雙核系統中執行且
4 個正在執行佇列中,那麼負載數即是 6,像 top 等工具可檢視過去 1,5,15 分鐘的負載均值。
3.3 CPU 利用率
CPU 利用率被定義為 CPU 使用的百分比, CPU 如何被利用是衡量一個系統的重要標準。
多數效能監測工具把 CPU 利用分為以下幾個型別:
* 使用者時間——CPU 花在執行使用者空間程序的時間百分比
CPU
* 系統時間——CPU 花在執行核心程序和中斷的時間百分比
CPU
* IO 等待——CPU 花在等待 IO 請求完成的時間百分比
CPU
IDLE——CPU 的空閒時間百分比
CPU
* IDLE
3
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
4.0 CPU 效能監測
理解 CPU 的效能狀態即是理解中斷,執行佇列和上下文切換的狀態。之前有提到過性
能與基準資訊有密切關係,但是有些常規的效能預期:
* 執行佇列——每個處理器上的執行佇列不應該有超過 1-3 個排隊的執行緒。例如,一個
雙核系統不應該有超過 6 個進行在執行佇列裡。
* CPU 利用率——假如一個 CPU 滿狀態負荷,那麼以下的平衡關係需要達到:
65%--70%
65%--70%的使用者時間
30%--35%
30%--35%的系統時間
0%--5%
0%--5%的空閒時間
* 上下文切換——上下文切換的數量與 CPU 的利用率有直接關係。如果 CPU 處於高
負荷狀態下那麼大量的上下文切換是正常的。
linux 系統裡有很多可以監測以上資料的工具,如 vmstat 和 top。
4.1 vmstat 工具的使用
vmstat 工具的低開銷使得它可以在一個高負載的系統上持續執行,它有兩種工作模式:
均值模式和取樣模式。取樣模式如下:
# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
每個區域的含義:
區域 描述
run queue 執行佇列中的程序數
r
blocked 等待 IO 請求完成的阻塞程序數
b
interrupts 正在處理的中斷數
in
context switches 正在發生的上下文切換數
cs
user 使用者 CPU 時間百分比
us
system 核心 CPU 時間百分比
sys
wait 可執行程序等待 IO 百分比
wa
idle CPU 空閒時間百分比
id
4.2 案例分析:CPU 持續性利用
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 0 206564 15092 80336 176080 0 0 0 0 718 26 81 19 0 0
2 0 206564 14772 80336 176120 0 0 0 0 758 23 96 4 0 0
4
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
1 0 206564 14208 80336 176136 0 0 0 0 820 20 96 4 0 0
1 0 206956 13884 79180 175964 0 412 0 2680 1008 80 93 7 0 0
2 0 207348 14448 78800 175576 0 412 0 412 763 70 84 16 0 0
2 0 207348 15756 78800 175424 0 0 0 0 874 25 89 11 0 0
1 0 207348 16368 78800 175596 0 0 0 0 940 24 86 14 0 0
1 0 207348 16600 78800 175604 0 0 0 0 929 27 95 3 0 2
3 0 207348 16976 78548 175876 0 0 0 2508 969 35 93 7 0 0
4 0 207348 16216 78548 175704 0 0 0 0 874 36 93 6 0 1
4 0 207348 16424 78548 175776 0 0 0 0 850 26 77 23 0 0
2 0 207348 17496 78556 175840 0 0 0 0 736 23 83 17 0 0
0 0 207348 17680 78556 175868 0 0 0 0 861 21 91 8 0 1
可從資料得到如下觀察結果:
* 其擁有很高的中斷數(in in
in)和很低的上下文切換數,這說明可能有單個程序在進行大
量的硬體資源請求。
* 使用者時間平均在 85% 85%以上,說明此程序一直停留在處理器中。
* 執行佇列數剛好達到可接受的上限值,且出現超過上限值的情況。
4.3 案例分析:超載排程
以下示例中核心排程器的上下文切換達到飽和:
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 2182 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 2219 2 7 91 0
4 2 207740 89240 90512 180984 0 0 880 520 443 907 22 10 67 0
5 3 207740 88056 91680 180984 0 0 1168 0 628 1248 12 11 77 0
4 2 207740 86852 92880 180984 0 0 1200 0 654 1505 6 7 87 0
6 1 207740 85736 93996 180984 0 0 1116 0 526 1512 5 10 85 0
0 1 207740 84844 94888 180984 0 0 892 0 438 1556 6 4 90 0
可從資料得到如下觀察結果:
* 上下文切換數高於中斷數,這表明核心必須花費相當數量的時間來處理上下文切換
程序。
* 大量的上下文切換引起 CPU 利用的不平衡,明顯的事實是大量的 IO 等待和使用者時
間的不足。
* 由於 CPU 受 IO 等待的限制,執行佇列開始阻塞。
4.4 mpstat 工具的使用
如果你的系統有多個處理器核心,你就可以使用 mpstat 工具來監測每個核心。linux 內
5
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
核把一個雙核處理器當做 2 個 CPU,所以一個擁有 2 顆雙核心的系統將被視為 4CPU。
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
4.5 案例分析:未過載狀態
下面的案例中有 4 個 CPU:
# top -d 1
top - 23:08:53 up 8:34, 3 users, load average: 0.91, 0.37, 0.13
Tasks: 190 total, 4 running, 186 sleeping, 0 stopped, 0 zombie
Cpu(s): 75.2% us, 0.2% sy, 0.0% ni, 24.5% id, 0.0% wa, 0.0% hi, 0.0%
si
Mem: 2074736k total, 448684k used, 1626052k free, 73756k buffers
Swap: 4192956k total, 0k used, 4192956k free, 259044k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15957 nobody 25 0 2776 280 224 R 100 20.5 0:25.48 php
15959 mysql 25 0 2256 280 224 R 100 38.2 0:17.78 mysqld
15960 apache 25 0 2416 280 224 R 100 15.7 0:11.20 httpd
15901 root 16 0 2780 1092 800 R 1 0.1 0:01.59 top
1 root 16 0 1780 660 572 S 0 0.0 0:00.64 init
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 81.52 0.00 18.48 21.17 130.58
05:17:32 PM 0 83.67 0.00 17.35 0.00 115.31
05:17:32 PM 1 80.61 0.00 19.39 0.00 13.27
05:17:32 PM 2 0.00 0.00 16.33 84.66 2.01
05:17:32 PM 3 79.59 0.00 21.43 0.00 0.00
05:17:32 PM CPU %user %nice %system %idle intr/s
05:17:33 PM all 85.86 0.00 14.14 25.00 116.49
05:17:33 PM 0 88.66 0.00 12.37 0.00 116.49
05:17:33 PM 1 80.41 0.00 19.59 0.00 0.00
05:17:33 PM 2 0.00 0.00 0.00 100.00 0.00
6
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
05:17:33 PM 3 83.51 0.00 16.49 0.00 0.00
05:17:33 PM CPU %user %nice %system %idle intr/s
05:17:34 PM all 82.74 0.00 17.26 25.00 115.31
05:17:34 PM 0 85.71 0.00 13.27 0.00 115.31
05:17:34 PM 1 78.57 0.00 21.43 0.00 0.00
05:17:34 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:34 PM 3 92.86 0.00 9.18 0.00 0.00
05:17:34 PM CPU %user %nice %system %idle intr/s
05:17:35 PM all 87.50 0.00 12.50 25.00 115.31
05:17:35 PM 0 91.84 0.00 8.16 0.00 114.29
05:17:35 PM 1 90.82 0.00 10.20 0.00 1.02
05:17:35 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:35 PM 3 81.63 0.00 15.31 0.00 0.00
你可以使用 ps 命令判定哪個程序執行在哪個 CPU 上:
# while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'mysqld'; sleep 1;
done
PID NI PRI %CPU PSR COMMAND
15775 0 15 86.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 94.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 96.6 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.8 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 99.3 3 mysqld
4.6 小結
CPU 的效能監測包含以下部分:
* 檢查系統執行佇列並確保每個核心上不超過 3 個可執行程序
* 確保 CPU 利用率的使用者時間和系統時間在 70/30 之間
* 當 CPU 花費更多的時間在 system mode 上時,更有可能是因過載而試圖重新排程優
先級
* 執行 CPU 限制型應用比 IO 限制型應用更易出現效能瓶頸
7
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
5.0 虛擬記憶體介紹
虛擬記憶體是使用磁碟作為 RAM 的擴充使得可用記憶體的有效大小得到相應增加。 核心會
將當前記憶體中未被使用的塊的內容寫入硬碟以此來騰出記憶體空間。 當上面的內容再次需要被
用到時,它們將被重新讀入記憶體。這些對使用者完全透明;在 linux 下執行的程式只會看到有
大量記憶體空間可用而不會去管它們的一部分時不時的從硬碟讀取。 當然, 硬碟的讀寫操作速
度比記憶體慢上千倍, 所以這個程式的執行速度也不會很快。 這個被用作虛擬記憶體的硬碟空間
唄稱作交換空間(swap space) 。
5.1 虛擬記憶體頁
虛擬記憶體被分成頁,在 X86 架構下的每個虛擬記憶體頁大小為 4KB,當核心由記憶體向磁
盤讀寫資料時,是以頁為單位。核心會把記憶體頁寫入 swap 空間和檔案系統。
5.2 核心記憶體分頁
記憶體分頁是一個常見的動作, 不能和記憶體交換相混淆。 記憶體分頁是在正常間隔下同步內
存中資訊至磁碟的過程。隨著時間的增長,應用會不斷耗盡記憶體,有時候核心必須掃描記憶體
並回收被分配給其他應用的空閒頁面。
5.3 頁幀回收演算法(PFRA)
PFRA 負責回收記憶體。PFRA 根據頁型別來判斷是否被回收,記憶體頁有以下型別:
* 不可被回收——locked,kernel,reserved 被鎖、核心、保留頁
* 可交換——無名記憶體頁
* 可同步——被磁碟同步的頁面
* 可丟棄——靜態頁,廢棄頁
除了不可被回收型別外其他均可被 PFRA 回收。PFRA 具有兩個主要功能,一個是 kswapd
核心程序,一個是“Low On Memory Reclaiming”功能。
5.4 kswapd
kswapd 守護程序負責確保記憶體保持可用空閒空間。它監測核心中的 pages_high 和
pages_low 標記,如果空閒記憶體空間值小於 pages_low 值,kswwapd 程序開始掃描並嘗試每
次回收 32 個頁面,如此重複直至空閒記憶體空間大於 pages_high 值。
kswapd 程序履行以下操作:
* 假如頁面未改變,它將該頁面放入 free list list。
* 假如頁面發生改變且被檔案系統回寫,它將頁面內容寫入磁碟。
* 假如頁面發生改變且未被檔案系統回寫(無名頁) ,它將頁面內容寫入 swap 裝置。
5.5 pdflush 核心分頁
pdflush 守護程序負責同步所有與檔案系統相關的頁面至磁碟,換句話說,就是當一個
檔案在記憶體中發生改變,pdflush 守護程序就將其回寫進磁碟。
8
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
當 內 存 中 的 髒 頁 面 數 量 超 過 10% 時 pdflush 守 護 進 程 開 始 回 寫 , 這 個 動 作 與 內 核的
vm.dirty_background_ratio 引數值有關。
# sysctl -n vm.dirty_background_ratio
10
多數情況下 pdflush 守護程序與 PFRA 之間是相互獨立的。除了常規的回收動作之外,
當核心呼叫 LMR 演算法時,LMR 將強制 pdflush 進行髒頁面回收。
5.6 案例分析:大規模寫入 I/O
vmstat 命令除了報告 CPU 的情況外還能檢視虛擬記憶體的使用情況,vmstat 輸出的以下
區域與虛擬記憶體有關:
區域 描述
當前使用的虛擬記憶體 KB 數
swapd
當前空閒的實體記憶體 KB 數
free
供 read()和 write()使用的實體記憶體緩衝大小
buff
對映到程序地址空間的實體記憶體數
cache
swap out 從記憶體到 swap 寫入的大小
so
swap in 從 swap 到記憶體寫入的大小
si
block out 從記憶體寫入磁碟的大小
bo
block in 從磁碟寫入記憶體你的大小
bi
以下資訊顯示一個 I/O 限制型應用執行時的狀態:
# vmstat 3
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
3 2 809192 261556 79760 886880 416 0 8244 751 426 863 17 3 6 75
0 3 809188 194916 79820 952900 307 0 21745 1005 1189 2590 34 6 12 48
0 3 809188 162212 79840 988920 95 0 12107 0 1801 2633 2 2 3 94
1 3 809268 88756 79924 1061424 260 28 18377 113 1142 1694 3 5 3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9 12 61
2 1 854780 17688 34140 1208980 1 9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31 4384 16524 27808 1490 1634 41 10 7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337 678 932 33 7 3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982 40 12 2 46
5 2 900472 17980 32440 1253884 24 4851 17521 4856 934 1730 48 12 13 26
1 1 904404 17620 32492 1258928 15 1316 7647 15804 919 978 49 9 17 25
4 1 911192 17944 32540 1266724 37 2263 12907 3547 834 1421 47 14 20 20
1 1 919292 17876 31824 1275832 1 2745 16327 2747 617 1421 52 11 23 14
5 0 925216 17812 25008 1289320 12 1975 12760 3181 772 1254 50 10 21 19
0 5 932860 17736 21760 1300280 8 2556 15469 3873 825 1258 49 13 24 15
通過以上資料可得出以下結果:
* 大量的資料從磁碟讀入記憶體(bi ,因 cache 值在不斷增長 bi
bi)
* 儘管資料正不斷消耗記憶體,空閒空間仍保持在 17M 左右
9
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
* buff 值正不斷減少,說明 kswapd 正不斷回收記憶體
* swpd 值不斷增大,說明 kswapd 正將髒頁面內容寫入交換空間(so so
so)
5.7 小結
虛擬記憶體的效能監測包括以下步驟:
* 當系統利用記憶體快取超過磁碟快取,系統反應速度更快
* 除在有大量持續的交換空間和磁碟讀入動作情況下外, 空閒記憶體空間很少說明 cache cache
得到了有效的利用
* 如果系統報告有持續的交換空間使用,說明記憶體不足
10
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
6.0 I/O 監測介紹
磁碟 IO 子系統是 linux 系統裡最慢的部分,這是由於其與 CPU 相比相去甚遠,且依賴
於物理式工作(轉動和檢索) 。如果將讀取磁碟和讀取記憶體所花費的時間轉換為分秒,那麼
他們之間的差距是 7 天和 7 分鐘,所以 linux 核心儘量少的進行磁碟操作是至關重要的。以
下部分將描述下核心處理資料從磁碟到記憶體和從記憶體到磁碟的不同方式。
6.1 資料讀寫——記憶體頁面
linux 核心將磁碟 IO 分為頁面進行操作,大多數 linux 系統中預設頁面大小為 4K,即以
4K 為單位進行磁碟和記憶體間的讀寫操作。我們可以使用 time 命令來查詢頁面大小:
# /usr/bin/time -v date
......
Page size (bytes): 4096
......
6.2 主要頁錯誤(Major Page Faults)和次要頁錯誤(Minor Page
Faults)
linux 和大多數 UNIX 系統一樣,使用虛擬記憶體層來對映實體地址空間,這種對映在某
種意義上是說當一個程序開始執行,核心僅僅對映其需要的那部分,核心首先會搜尋 CPU
快取和實體記憶體,如果沒有找到核心則開始一次 MPF,一次 MPF 即是一次對磁碟子系統的
請求,它將資料頁從磁碟和快取讀入 RAM。
一旦記憶體頁被對映到高速緩衝區,核心便會試圖使用這些頁,被稱作 MnPF,MnPF 通過重複
使用記憶體頁而縮短了核心時間。
在下面示例中,time 命令顯示了當一個程式啟動的時候產生了多少 MPF 和 MnPF,在第一
次啟動的時候產生了很多 MPF:
# /usr/bin/time -v evolution
......
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
......
第二次啟動的時候 MPF 消失因為程式已經在記憶體中:
# /usr/bin/time -v evolution
......
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
......
6.3 檔案緩衝區
檔案緩衝區可使核心減少對 MPFs 和 MnPFs 的使用,隨著系統不斷地 IO 操作,緩衝區
會隨之增大, 直至記憶體空閒空間不足並開始回收, 最終結果是系統管理員們開始關心這個事
11
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
實,但這只是系統正在很好的使用緩衝空間而已。
下面的輸入來自/proc/meminfo 檔案:
# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
......
以上顯示系統擁有 2G 記憶體, 當前有 52MB 空閒空間, 24MB 的 buffer 供應磁碟寫操作, 1.7GB
的 cache 由磁碟讀入記憶體。
核心通過 MnPF 機制來使用這些東東,光這些資料還不足以說明系統出現瓶頸。
6.4 記憶體頁面分類
在 linux 核心中有 3 種核心頁:
* 讀取頁面——從磁碟讀入(MPF MPF
MPF)的只讀頁面,這些頁面存在於緩衝區中包括不可
改變的靜態檔案,二進位制檔案和庫檔案。核心會因需求而不斷地將他們讀入記憶體,如
果記憶體變得不夠用,核心會將他們“竊取”至空閒列表,這將導致某個應用通過 MPF MPF
將它們重新載入至記憶體。
* 髒頁面——在記憶體中被核心修改的頁面,它們將被 pdflush 守護程序回寫至磁碟, 當
記憶體不夠用時,kswapd 程序也會和 pdflush 一道進行回寫以釋放更多記憶體空間。
kswapd
* 無名頁面——它們屬於某個程序,但是沒有任何檔案或後端儲存與之關聯,它們不
能被回寫進磁碟,當記憶體不夠用時 kswapd 守護程序會將它們寫入交換空間直至 RAM RAM
釋放出來。
6.5 資料頁面磁盤迴寫
應用可能直接呼叫 fsync()或 sync()系統呼叫將髒頁面回寫入磁碟, 這些系統呼叫會直接
請求至 I/O 排程器。如果一個應用不呼叫它們,則 pdflush 守護程序會時不時地進行頁面回
寫操作。
12
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
7.0 監測磁碟 I/O
在一定條件下系統會出現 I/O 瓶頸,可由很多監測工具監測到,如 top,vmstat,iostat,
sar 等。這些工具輸入的資訊大致一樣,也有不同之處,下面將討論出現 I/O 瓶頸的情況。
7.1 計算每秒 IO 量
每一次向磁碟的 IO 請求都會花費一定時間,這主要是因為磁碟必須旋轉,磁頭必須檢
索。磁碟的旋轉通常被稱為“旋轉延遲(rotational delay)” (RD),磁頭的移動杯稱為“磁碟
檢索(disk seek)” (DS) 。因此每次 IO 請求的時間由 DS 和 RD 計算得來,磁碟的 RD 由驅動
氣的轉速所固定,一 RD 被為磁碟一轉的一半,計算一塊 10000 轉磁碟的 RD 如下:
1. 算出每轉的秒數:60 秒/10000 轉 = 0.006 秒/轉
2. 轉換為毫秒: 0.006*1000 毫秒 = 6 毫秒
3. 算出 RD 值: 6/2 = 3 毫秒
4. 加上平均檢索時間:3+3 = 6 毫秒
5. 加上內部轉移等待時間: 6+2 = 8 毫秒
6. 算出一秒的 IO 數:1000 毫秒/8 毫秒 = 125 次/秒(IOPS)
在一塊萬轉硬碟上應用每請求一次 IO 需要 8 毫秒,每秒可提供 120 到 150 次操作。
7.2 隨機 IO 和有序 IO
每次 IO 的資料量與系統的工作負荷相關。系統的負荷分兩類:有序和隨機。
7.2.1 有序 IO
iostat 命令可提供 IOPS 值和每次 IO 的資料量, 有序負荷需要一次有序地讀取大量資料,
因此每次 IO 的資料量很大,其效能取決於短時間大資料量的執行能力。
13
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
計算 IOPS 能力的方式是用每秒讀寫資料量除以每秒讀寫次數:
53040/105 = 505 KB/IO
71152/102 = 697 KB/IO
7.2 隨機 IO
隨機負荷與資料大小關係不大,與磁碟的 IOPS 值有關,web 服務,mail 服務一般屬於
此類,IO 請求相對較少,其依賴於一次可執行多少次請求,因此磁碟的 IOPS 值非常關鍵。
此資料與剛才的資料相比每次 IO 寫入的資料量差異很大:
2640/102 = 23 KB/IO
3176/130 = 24 KB/IO
7.3 當虛擬記憶體終結 I/O 時
假如系統沒有足夠的記憶體供給所有的請求時,並開始使用交換空間,和檔案系統 IO 一
樣 swap 的寫入也很慢,假如記憶體嚴重的不足,那麼這可能導致大量的頁面湧向 swap,假如
這個 swap 空間與要寫入的檔案處於同一檔案系統下,此係統將進入 IO 爭搶,這將導致系
統效能直線下降。假如頁面無法讀或寫入磁碟,那麼它們將一直停留於記憶體中,核心會開始
嘗試釋放記憶體空間,問題是 IO 通道已經嚴重阻塞且無法做任何事情,這必將導致系統核心
出錯並崩潰。
下面的 vmstat 輸出展示了這種情況:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
17 0 1250 3248 45820 1488472 30 132 992 0 2437 7657 23 50 0 23
11 0 1376 3256 45820 1488888 57 245 416 0 2391 7173 10 90 0 0
12 0 1582 1688 45828 1490228 63 131 1348 76 2432 7315 10 90 0 10
12 2 3981 1848 45468 1489824 185 56 2300 68 2478 9149 15 12 0 73
14 2 10385 2400 44484 1489732 0 87 1112 20 2515 11620 0 12 0 88
14
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
14 2 12671 2280 43644 1488816 76 51 1812 204 2546 11407 20 45 0 35
以上資料顯示大量的讀入記憶體請求(bi) ,記憶體不夠,導致資料塊不停寫入(so)交換空間,
交換空間大小不斷增長(swpd) ,同樣也出現了大量的 IO 等待時間(wa) ,這表明 CPU 因
為 IO 請求的原因而開始變慢。
在上面的例子中,swap 裝置(/dev/sda1)和檔案系統(/dev/sda3)在爭搶 IO。
7.4 判定應用 IO 使用
iotop 命令顯示每個程序的 IO 使用情況,其輸出結果與 top 命令相似,可與 iostat 命令
結合來判斷產生 IO 瓶頸的應用。
在下面的示例中,在同一磁碟上(sda2)既有讀操作(r/s)又有寫操作(w/s):
# iostat –x 1
avg-cpu: %user %nice %system %iowait %steal %idle
7.14 0.00 35.71 57.14 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 123.47 25.51 987.76 21951.02 153.97 27.76 224.29 6.85 102.04
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 123.47 25.51 987.76 21951.02 153.97 27.76 224.29 6.85 102.04
#iotop -d 5 -P
Total DISK READ: 981.23 K/s | Total DISK WRITE: 21.43 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2574 be/4 root 967.01 K/s 0.00 B/s 0.00 % 39.05 % find /
64 be/3 root 0.00 B/s 19.94 M/s 0.00 % 13.09 % smbd -D
2533 be/4 dhoch 3.63 K/s 8.72 K/s 0.00 % 1.82 % [kjournald]
2442 be/4 root 0.00 B/s 2.91 K/s 0.00 % 0.46 % iostat -x 1
2217 be/4 dhoch 0.00 B/s 1488.57 B/s 0.00 % 0.00 % mono /usr~-ior-fd=25
1985 be/4 dhoch 0.00 B/s 255.12 K/s 0.00 % 0.00 % smbd -D
iotop 的 DISK READ 和 DISK WRITE 與 iostat 的 rsec/s 和 wsec/s 相對應。
15
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
7.5 小結
I/O 效能監測可總結如下:
* 任何時間出現 CPU 等待 IO IO,說明磁碟超載。
* 計算出你的磁碟可維持的 IOPS 值。
* 判定你的應用時屬於隨機磁碟訪問型還是有序型。
* 通過對比等待時間和服務時間即可判斷磁碟是否緩慢。
* 監測交換空間和檔案系統坐在分割槽並確保他們之間不存在爭搶 IO IO。
16
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
8.0 網路監測介紹
網路是所有子系統中最難監測的一個, 因為網路比較抽象, 在監測時有很多在系統可控
制之外的因素如延遲,衝突,擁塞和丟包等對監測產生影響。下面將討論的是乙太網、IP、
TCP 的效能監測。
8.1 乙太網配置設定
除非有明確的設定, 所有乙太網的速度都是自動協商的, 這很大程度上是由於歷史原因
造成的,早些時候一個網路裡經常有不同網速和雙工模式的網路裝置。
大多數企業乙太網是 100BaseTX 或 1000BaseTX,可以使用 ethtool 工具來判斷一個系統的
網速。
下面的示例中一個擁有 100BaseTX 網絡卡的機器工作在 10BaseTX 下:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
下面將其強制設定為 100BaseTX 模式:
# ethtool -s eth0 speed 100 duplex full autoneg off
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
17
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
8.2 網路吞吐量監測
監測網路吞吐量最好的辦法是在兩個系統之間傳送流量並統計其延遲和速度。
8.2.0 使用 iptraf 監測本地吞吐量
iptraf 工具可提供乙太網卡的吞吐量情況:
# iptraf -d eth0
上面的資料顯示被測試系統正以 61mbps(7.65M)頻率傳送資料,相比於 100mbps 網路這
有點低。
8.2.1 使用 netperf 監測遠端吞吐量
18
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
與 iptraf 的動態監測不一樣的是 netperf 使用可控方式測試網路, 這一點對測試一個客戶
端到一個高負載伺服器之間的吞吐量很有幫助,netperf 工具是以 C/S 模式執行。
首先需要在伺服器上執行 netperf 服務端:
server# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
netperf 可以執行多種測試,最基本的是標準測試:
client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.02 89.46
輸出顯示吞吐量在 89mbps 左右,伺服器和客戶端在同一網段。
從一個 10 跳的 54G 無線網進行測試只能達到 14mbps 左右:
client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.10 14.09
從 50 跳距離區域網測試:
# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.64 5.05
從外網測試:
# netperf -H litemail.org -p 1500 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
19
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
litemail.org (72.249.104.148) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 31.58 0.93
通過 VPN 測試:
# netperf -H 10.0.1.129 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
10.0.1.129 (10.0.1.129) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384
《Linux 系統和網路效能監測》
讀
書
筆
記
By:星星 from www.xnlinux.cn
0
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
1.0 效能監測簡介
效能調優是找出系統瓶頸並消除這些瓶頸的過程。 很多系統管理員認為效能調優僅僅是
調整一下核心的引數即可解決問題, 事實上情況並不是這樣。 效能調優是實現作業系統的各
個子系統之間的平衡性,這些子系統包括:
* CPU
* Memory
* IO
* Network
子系統之間相互依存,任何一個子系統的負載過度都能導致其他子系統出現問題,例如:
* 大量的 page-in IO 請求可能導致記憶體佇列被塞滿
* 網絡卡的巨量吞吐可能導致 CPU 資源耗盡
* 系統嘗試保持釋放記憶體佇列時可能耗盡 CPU 資源
* 來自記憶體的大量磁碟寫入請求可能導致 CPU 資源和 IO 通道耗盡
效能調優的前提是找出系統瓶頸之所在, 儘管問題看似由某個子系統所導致, 然而這很
可能是另外一個子系統的過載所引起的。
1.1 判定應用的型別
為了明白從何處開始著手調整效能瓶頸, 弄清被分析系統的效能表現是首要任務。 任何
系統的應用常可分為以下兩類:
* IO 限制型——一個 IO 限制型的應用需要大量的記憶體和基礎儲存裝置佔用。 因其需要
大量的資料讀寫請求,此類應用對 CPU 和網路需求不高(除非儲存系統在網路上) 。
IO 限制型應用使用 CPU 資源來進行 IO 操作且常進入睡眠狀態。 資料庫應用常被認為
屬於此類。
* CPU 限制型——一個 CPU 限制型應用需要大量的 CPU 資源,來進行批量的處理或
大量的計算。大容量 web 服務,mail 服務,以及任何型別的渲染服務都被歸到此類。 mail
1.2 判定基準資訊
系統的利用率因管理員的期望值和系統的引數值而異, 判斷一個系統是否有效能問題的
唯一途徑是弄清楚對系統的期望是神馬, 需求的效能是神馬, 應該得到的資料是神馬?而為
了建立這些資訊的唯一途徑是為系統建立一個基準。 在效能可接受的狀態下必須為系統建立
統計資訊,這樣就可以在效能不可接受時進行對比。
在下面的例子中,將對兩種狀態下的統計資訊進行對比:
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
1 0 138592 17932 126272 214244 0 0 1 18 109 19 2 1 1 96
0 0 138592 17932 126272 214244 0 0 0 0 105 46 0 1 0 99
0 0 138592 17932 126272 214244 0 0 0 0 198 62 40 14 0 45
1
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
0 0 138592 17932 126272 214244 0 0 0 0 117 49 0 0 0 100
0 0 138592 17924 126272 214244 0 0 0 176 220 938 3 4 13 80
0 0 138592 17924 126272 214244 0 0 0 0 358 1522 8 17 0 75
1 0 138592 17924 126272 214244 0 0 0 0 368 1447 4 24 0 72
0 0 138592 17924 126272 214244 0 0 0 0 352 1277 9 12 0 79
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 0 145940 17752 118600 215592 0 1 1 18 109 19 2 1 1 96
2 0 145940 15856 118604 215652 0 0 0 468 789 108 86 14 0 0
3 0 146208 13884 118600 214640 0 360 0 360 498 71 91 9 0 0
2 0 146388 13764 118600 213788 0 340 0 340 672 41 87 13 0 0
2 0 147092 13788 118600 212452 0 740 0 1324 620 61 92 8 0 0
2 0 147360 13848 118600 211580 0 720 0 720 690 41 96 4 0 0
2 0 147912 13744 118192 210592 0 720 0 720 605 44 95 5 0 0
2 0 148452 13900 118192 209260 0 372 0 372 639 45 81 19 0 0
2 0 149132 13692 117824 208412 0 372 0 372 457 47 90 10 0 0
只需要看代表 idle 時間的最後一列(id)就能發現問題,在基準資料中 CPU 空閒時間在
79%-100%之間,在高負荷狀態下系統利用率 100%且無空閒。需要考慮的是 CPU 這塊的問
題。
2.0 安裝監測工具
大多*nix 系統均自帶了很多標準監測命令,也有的是第三方工具:
工具名稱 描述 基礎安裝包 可選安裝包
多功能
vmstat Y Y
CPU 效能
mpstat N Y
多功能
sar N Y
磁碟效能
iostat N Y
網路效能
netstat Y Y
多功能 大多數
dstat N
流量監測
iptraf N Y
網路頻寬 大多數
netperf N
網絡卡監測
ethtool Y Y
網路頻寬
iperf N Y
資料包監測
tcptrace N Y
IO 監測
iotop N Y
2
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
3.0 CPU 介紹
CPU 利用率很大部分取決於試圖訪問它的資源,核心擁有一個管理兩種資源的排程器:
執行緒(單或多)和中斷。排程器給予不同資源以不同的優先順序,以下由優先順序從高到低:
* 中斷——裝置通知核心它們處理完成。例如網絡卡傳送一個數據包或硬碟驅動器提供
一次 IO 請求
* 核心(系統)程序——所有的核心程序都在此級別的優先順序進行處理
* 使用者程序——通常被稱為“使用者空間” ,所有應用軟體執行在使用者空間,擁有最低的
優先順序
為了弄明白核心是如何管理不同的資源的,幾個關鍵概念需要提及一下: context
switches,run queues,utilization。
3.1 Context Switches(上下文切換)
大多數處理器在同一時間只能處理一個程序或執行緒,多執行緒處理器可同時處理 n 個線
程。然而,linux 核心把多核處理器的各個核心當做獨立核心。例如,核心把一個雙核的處
理當做兩個獨立處理器。
一個標準的核心可同時處理 50 到 50000 個程序,在只有一顆 CPU 的情況下,核心必須排程
和平衡這些程序和執行緒。 每個執行緒在處理器上都擁有一個時間分配單元, 當一個執行緒超過自
己的時間單元或被更高優先順序的程式搶佔時, 此執行緒及被傳回佇列而此時更高優先順序的程式
將在處理器上執行。這種執行緒間的切換操作即是上下文切換。
3.2 執行佇列
每個 CPU 維持著一個執行緒的執行佇列,理論上,排程器應該是不斷地執行和執行執行緒。
執行緒要麼處於睡眠狀態,要麼處於可執行狀態。假如 CPU 子系統處於高負載狀態,那麼內
核排程器罷工是有可能的, 其結果將導致可執行狀態的程序開始阻塞執行佇列。 執行佇列越
大,執行程序所花費的時間也越長。
一個很流行的術語叫“load(負載) ”經常被用來描述執行佇列的狀態,系統負載是由正在
執行的程序和 CPU 執行佇列中的程序的結合,如果有 2 個執行緒正在一個雙核系統中執行且
4 個正在執行佇列中,那麼負載數即是 6,像 top 等工具可檢視過去 1,5,15 分鐘的負載均值。
3.3 CPU 利用率
CPU 利用率被定義為 CPU 使用的百分比, CPU 如何被利用是衡量一個系統的重要標準。
多數效能監測工具把 CPU 利用分為以下幾個型別:
* 使用者時間——CPU 花在執行使用者空間程序的時間百分比
CPU
* 系統時間——CPU 花在執行核心程序和中斷的時間百分比
CPU
* IO 等待——CPU 花在等待 IO 請求完成的時間百分比
CPU
IDLE——CPU 的空閒時間百分比
CPU
* IDLE
3
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
4.0 CPU 效能監測
理解 CPU 的效能狀態即是理解中斷,執行佇列和上下文切換的狀態。之前有提到過性
能與基準資訊有密切關係,但是有些常規的效能預期:
* 執行佇列——每個處理器上的執行佇列不應該有超過 1-3 個排隊的執行緒。例如,一個
雙核系統不應該有超過 6 個進行在執行佇列裡。
* CPU 利用率——假如一個 CPU 滿狀態負荷,那麼以下的平衡關係需要達到:
65%--70%
65%--70%的使用者時間
30%--35%
30%--35%的系統時間
0%--5%
0%--5%的空閒時間
* 上下文切換——上下文切換的數量與 CPU 的利用率有直接關係。如果 CPU 處於高
負荷狀態下那麼大量的上下文切換是正常的。
linux 系統裡有很多可以監測以上資料的工具,如 vmstat 和 top。
4.1 vmstat 工具的使用
vmstat 工具的低開銷使得它可以在一個高負載的系統上持續執行,它有兩種工作模式:
均值模式和取樣模式。取樣模式如下:
# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 104300 16800 95328 72200 0 0 5 26 7 14 4 1 95 0
0 0 104300 16800 95328 72200 0 0 0 24 1021 64 1 1 98 0
0 0 104300 16800 95328 72200 0 0 0 0 1009 59 1 1 98 0
每個區域的含義:
區域 描述
run queue 執行佇列中的程序數
r
blocked 等待 IO 請求完成的阻塞程序數
b
interrupts 正在處理的中斷數
in
context switches 正在發生的上下文切換數
cs
user 使用者 CPU 時間百分比
us
system 核心 CPU 時間百分比
sys
wait 可執行程序等待 IO 百分比
wa
idle CPU 空閒時間百分比
id
4.2 案例分析:CPU 持續性利用
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
3 0 206564 15092 80336 176080 0 0 0 0 718 26 81 19 0 0
2 0 206564 14772 80336 176120 0 0 0 0 758 23 96 4 0 0
4
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
1 0 206564 14208 80336 176136 0 0 0 0 820 20 96 4 0 0
1 0 206956 13884 79180 175964 0 412 0 2680 1008 80 93 7 0 0
2 0 207348 14448 78800 175576 0 412 0 412 763 70 84 16 0 0
2 0 207348 15756 78800 175424 0 0 0 0 874 25 89 11 0 0
1 0 207348 16368 78800 175596 0 0 0 0 940 24 86 14 0 0
1 0 207348 16600 78800 175604 0 0 0 0 929 27 95 3 0 2
3 0 207348 16976 78548 175876 0 0 0 2508 969 35 93 7 0 0
4 0 207348 16216 78548 175704 0 0 0 0 874 36 93 6 0 1
4 0 207348 16424 78548 175776 0 0 0 0 850 26 77 23 0 0
2 0 207348 17496 78556 175840 0 0 0 0 736 23 83 17 0 0
0 0 207348 17680 78556 175868 0 0 0 0 861 21 91 8 0 1
可從資料得到如下觀察結果:
* 其擁有很高的中斷數(in in
in)和很低的上下文切換數,這說明可能有單個程序在進行大
量的硬體資源請求。
* 使用者時間平均在 85% 85%以上,說明此程序一直停留在處理器中。
* 執行佇列數剛好達到可接受的上限值,且出現超過上限值的情況。
4.3 案例分析:超載排程
以下示例中核心排程器的上下文切換達到飽和:
# vmstat 1
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy wa id
2 1 207740 98476 81344 180972 0 0 2496 0 900 2883 4 12 57 27
0 1 207740 96448 83304 180984 0 0 1968 328 810 2559 8 9 83 0
0 1 207740 94404 85348 180984 0 0 2044 0 829 2879 9 6 78 7
0 1 207740 92576 87176 180984 0 0 1828 0 689 2088 3 9 78 10
2 0 207740 91300 88452 180984 0 0 1276 0 565 2182 7 6 83 4
3 1 207740 90124 89628 180984 0 0 1176 0 551 2219 2 7 91 0
4 2 207740 89240 90512 180984 0 0 880 520 443 907 22 10 67 0
5 3 207740 88056 91680 180984 0 0 1168 0 628 1248 12 11 77 0
4 2 207740 86852 92880 180984 0 0 1200 0 654 1505 6 7 87 0
6 1 207740 85736 93996 180984 0 0 1116 0 526 1512 5 10 85 0
0 1 207740 84844 94888 180984 0 0 892 0 438 1556 6 4 90 0
可從資料得到如下觀察結果:
* 上下文切換數高於中斷數,這表明核心必須花費相當數量的時間來處理上下文切換
程序。
* 大量的上下文切換引起 CPU 利用的不平衡,明顯的事實是大量的 IO 等待和使用者時
間的不足。
* 由於 CPU 受 IO 等待的限制,執行佇列開始阻塞。
4.4 mpstat 工具的使用
如果你的系統有多個處理器核心,你就可以使用 mpstat 工具來監測每個核心。linux 內
5
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
核把一個雙核處理器當做 2 個 CPU,所以一個擁有 2 顆雙核心的系統將被視為 4CPU。
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 0.00 0.00 3.19 96.53 13.27
05:17:32 PM 0 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 1 1.12 0.00 12.73 86.15 13.27
05:17:32 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:32 PM 3 0.00 0.00 0.00 100.00 0.00
4.5 案例分析:未過載狀態
下面的案例中有 4 個 CPU:
# top -d 1
top - 23:08:53 up 8:34, 3 users, load average: 0.91, 0.37, 0.13
Tasks: 190 total, 4 running, 186 sleeping, 0 stopped, 0 zombie
Cpu(s): 75.2% us, 0.2% sy, 0.0% ni, 24.5% id, 0.0% wa, 0.0% hi, 0.0%
si
Mem: 2074736k total, 448684k used, 1626052k free, 73756k buffers
Swap: 4192956k total, 0k used, 4192956k free, 259044k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15957 nobody 25 0 2776 280 224 R 100 20.5 0:25.48 php
15959 mysql 25 0 2256 280 224 R 100 38.2 0:17.78 mysqld
15960 apache 25 0 2416 280 224 R 100 15.7 0:11.20 httpd
15901 root 16 0 2780 1092 800 R 1 0.1 0:01.59 top
1 root 16 0 1780 660 572 S 0 0.0 0:00.64 init
# mpstat –P ALL 1
Linux 2.4.21-20.ELsmp (localhost.localdomain) 05/23/2006
05:17:31 PM CPU %user %nice %system %idle intr/s
05:17:32 PM all 81.52 0.00 18.48 21.17 130.58
05:17:32 PM 0 83.67 0.00 17.35 0.00 115.31
05:17:32 PM 1 80.61 0.00 19.39 0.00 13.27
05:17:32 PM 2 0.00 0.00 16.33 84.66 2.01
05:17:32 PM 3 79.59 0.00 21.43 0.00 0.00
05:17:32 PM CPU %user %nice %system %idle intr/s
05:17:33 PM all 85.86 0.00 14.14 25.00 116.49
05:17:33 PM 0 88.66 0.00 12.37 0.00 116.49
05:17:33 PM 1 80.41 0.00 19.59 0.00 0.00
05:17:33 PM 2 0.00 0.00 0.00 100.00 0.00
6
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
05:17:33 PM 3 83.51 0.00 16.49 0.00 0.00
05:17:33 PM CPU %user %nice %system %idle intr/s
05:17:34 PM all 82.74 0.00 17.26 25.00 115.31
05:17:34 PM 0 85.71 0.00 13.27 0.00 115.31
05:17:34 PM 1 78.57 0.00 21.43 0.00 0.00
05:17:34 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:34 PM 3 92.86 0.00 9.18 0.00 0.00
05:17:34 PM CPU %user %nice %system %idle intr/s
05:17:35 PM all 87.50 0.00 12.50 25.00 115.31
05:17:35 PM 0 91.84 0.00 8.16 0.00 114.29
05:17:35 PM 1 90.82 0.00 10.20 0.00 1.02
05:17:35 PM 2 0.00 0.00 0.00 100.00 0.00
05:17:35 PM 3 81.63 0.00 15.31 0.00 0.00
你可以使用 ps 命令判定哪個程序執行在哪個 CPU 上:
# while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'mysqld'; sleep 1;
done
PID NI PRI %CPU PSR COMMAND
15775 0 15 86.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 94.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 96.6 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.0 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 98.8 3 mysqld
PID NI PRI %CPU PSR COMMAND
15775 0 14 99.3 3 mysqld
4.6 小結
CPU 的效能監測包含以下部分:
* 檢查系統執行佇列並確保每個核心上不超過 3 個可執行程序
* 確保 CPU 利用率的使用者時間和系統時間在 70/30 之間
* 當 CPU 花費更多的時間在 system mode 上時,更有可能是因過載而試圖重新排程優
先級
* 執行 CPU 限制型應用比 IO 限制型應用更易出現效能瓶頸
7
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
5.0 虛擬記憶體介紹
虛擬記憶體是使用磁碟作為 RAM 的擴充使得可用記憶體的有效大小得到相應增加。 核心會
將當前記憶體中未被使用的塊的內容寫入硬碟以此來騰出記憶體空間。 當上面的內容再次需要被
用到時,它們將被重新讀入記憶體。這些對使用者完全透明;在 linux 下執行的程式只會看到有
大量記憶體空間可用而不會去管它們的一部分時不時的從硬碟讀取。 當然, 硬碟的讀寫操作速
度比記憶體慢上千倍, 所以這個程式的執行速度也不會很快。 這個被用作虛擬記憶體的硬碟空間
唄稱作交換空間(swap space) 。
5.1 虛擬記憶體頁
虛擬記憶體被分成頁,在 X86 架構下的每個虛擬記憶體頁大小為 4KB,當核心由記憶體向磁
盤讀寫資料時,是以頁為單位。核心會把記憶體頁寫入 swap 空間和檔案系統。
5.2 核心記憶體分頁
記憶體分頁是一個常見的動作, 不能和記憶體交換相混淆。 記憶體分頁是在正常間隔下同步內
存中資訊至磁碟的過程。隨著時間的增長,應用會不斷耗盡記憶體,有時候核心必須掃描記憶體
並回收被分配給其他應用的空閒頁面。
5.3 頁幀回收演算法(PFRA)
PFRA 負責回收記憶體。PFRA 根據頁型別來判斷是否被回收,記憶體頁有以下型別:
* 不可被回收——locked,kernel,reserved 被鎖、核心、保留頁
* 可交換——無名記憶體頁
* 可同步——被磁碟同步的頁面
* 可丟棄——靜態頁,廢棄頁
除了不可被回收型別外其他均可被 PFRA 回收。PFRA 具有兩個主要功能,一個是 kswapd
核心程序,一個是“Low On Memory Reclaiming”功能。
5.4 kswapd
kswapd 守護程序負責確保記憶體保持可用空閒空間。它監測核心中的 pages_high 和
pages_low 標記,如果空閒記憶體空間值小於 pages_low 值,kswwapd 程序開始掃描並嘗試每
次回收 32 個頁面,如此重複直至空閒記憶體空間大於 pages_high 值。
kswapd 程序履行以下操作:
* 假如頁面未改變,它將該頁面放入 free list list。
* 假如頁面發生改變且被檔案系統回寫,它將頁面內容寫入磁碟。
* 假如頁面發生改變且未被檔案系統回寫(無名頁) ,它將頁面內容寫入 swap 裝置。
5.5 pdflush 核心分頁
pdflush 守護程序負責同步所有與檔案系統相關的頁面至磁碟,換句話說,就是當一個
檔案在記憶體中發生改變,pdflush 守護程序就將其回寫進磁碟。
8
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
當 內 存 中 的 髒 頁 面 數 量 超 過 10% 時 pdflush 守 護 進 程 開 始 回 寫 , 這 個 動 作 與 內 核的
vm.dirty_background_ratio 引數值有關。
# sysctl -n vm.dirty_background_ratio
10
多數情況下 pdflush 守護程序與 PFRA 之間是相互獨立的。除了常規的回收動作之外,
當核心呼叫 LMR 演算法時,LMR 將強制 pdflush 進行髒頁面回收。
5.6 案例分析:大規模寫入 I/O
vmstat 命令除了報告 CPU 的情況外還能檢視虛擬記憶體的使用情況,vmstat 輸出的以下
區域與虛擬記憶體有關:
區域 描述
當前使用的虛擬記憶體 KB 數
swapd
當前空閒的實體記憶體 KB 數
free
供 read()和 write()使用的實體記憶體緩衝大小
buff
對映到程序地址空間的實體記憶體數
cache
swap out 從記憶體到 swap 寫入的大小
so
swap in 從 swap 到記憶體寫入的大小
si
block out 從記憶體寫入磁碟的大小
bo
block in 從磁碟寫入記憶體你的大小
bi
以下資訊顯示一個 I/O 限制型應用執行時的狀態:
# vmstat 3
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
3 2 809192 261556 79760 886880 416 0 8244 751 426 863 17 3 6 75
0 3 809188 194916 79820 952900 307 0 21745 1005 1189 2590 34 6 12 48
0 3 809188 162212 79840 988920 95 0 12107 0 1801 2633 2 2 3 94
1 3 809268 88756 79924 1061424 260 28 18377 113 1142 1694 3 5 3 88
1 2 826284 17608 71240 1144180 100 6140 25839 16380 1528 1179 19 9 12 61
2 1 854780 17688 34140 1208980 1 9535 25557 30967 1764 2238 43 13 16 28
0 8 867528 17588 32332 1226392 31 4384 16524 27808 1490 1634 41 10 7 43
4 2 877372 17596 32372 1227532 213 3281 10912 3337 678 932 33 7 3 57
1 2 885980 17800 32408 1239160 204 2892 12347 12681 1033 982 40 12 2 46
5 2 900472 17980 32440 1253884 24 4851 17521 4856 934 1730 48 12 13 26
1 1 904404 17620 32492 1258928 15 1316 7647 15804 919 978 49 9 17 25
4 1 911192 17944 32540 1266724 37 2263 12907 3547 834 1421 47 14 20 20
1 1 919292 17876 31824 1275832 1 2745 16327 2747 617 1421 52 11 23 14
5 0 925216 17812 25008 1289320 12 1975 12760 3181 772 1254 50 10 21 19
0 5 932860 17736 21760 1300280 8 2556 15469 3873 825 1258 49 13 24 15
通過以上資料可得出以下結果:
* 大量的資料從磁碟讀入記憶體(bi ,因 cache 值在不斷增長 bi
bi)
* 儘管資料正不斷消耗記憶體,空閒空間仍保持在 17M 左右
9
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
* buff 值正不斷減少,說明 kswapd 正不斷回收記憶體
* swpd 值不斷增大,說明 kswapd 正將髒頁面內容寫入交換空間(so so
so)
5.7 小結
虛擬記憶體的效能監測包括以下步驟:
* 當系統利用記憶體快取超過磁碟快取,系統反應速度更快
* 除在有大量持續的交換空間和磁碟讀入動作情況下外, 空閒記憶體空間很少說明 cache cache
得到了有效的利用
* 如果系統報告有持續的交換空間使用,說明記憶體不足
10
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
6.0 I/O 監測介紹
磁碟 IO 子系統是 linux 系統裡最慢的部分,這是由於其與 CPU 相比相去甚遠,且依賴
於物理式工作(轉動和檢索) 。如果將讀取磁碟和讀取記憶體所花費的時間轉換為分秒,那麼
他們之間的差距是 7 天和 7 分鐘,所以 linux 核心儘量少的進行磁碟操作是至關重要的。以
下部分將描述下核心處理資料從磁碟到記憶體和從記憶體到磁碟的不同方式。
6.1 資料讀寫——記憶體頁面
linux 核心將磁碟 IO 分為頁面進行操作,大多數 linux 系統中預設頁面大小為 4K,即以
4K 為單位進行磁碟和記憶體間的讀寫操作。我們可以使用 time 命令來查詢頁面大小:
# /usr/bin/time -v date
......
Page size (bytes): 4096
......
6.2 主要頁錯誤(Major Page Faults)和次要頁錯誤(Minor Page
Faults)
linux 和大多數 UNIX 系統一樣,使用虛擬記憶體層來對映實體地址空間,這種對映在某
種意義上是說當一個程序開始執行,核心僅僅對映其需要的那部分,核心首先會搜尋 CPU
快取和實體記憶體,如果沒有找到核心則開始一次 MPF,一次 MPF 即是一次對磁碟子系統的
請求,它將資料頁從磁碟和快取讀入 RAM。
一旦記憶體頁被對映到高速緩衝區,核心便會試圖使用這些頁,被稱作 MnPF,MnPF 通過重複
使用記憶體頁而縮短了核心時間。
在下面示例中,time 命令顯示了當一個程式啟動的時候產生了多少 MPF 和 MnPF,在第一
次啟動的時候產生了很多 MPF:
# /usr/bin/time -v evolution
......
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
......
第二次啟動的時候 MPF 消失因為程式已經在記憶體中:
# /usr/bin/time -v evolution
......
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
......
6.3 檔案緩衝區
檔案緩衝區可使核心減少對 MPFs 和 MnPFs 的使用,隨著系統不斷地 IO 操作,緩衝區
會隨之增大, 直至記憶體空閒空間不足並開始回收, 最終結果是系統管理員們開始關心這個事
11
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
實,但這只是系統正在很好的使用緩衝空間而已。
下面的輸入來自/proc/meminfo 檔案:
# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
......
以上顯示系統擁有 2G 記憶體, 當前有 52MB 空閒空間, 24MB 的 buffer 供應磁碟寫操作, 1.7GB
的 cache 由磁碟讀入記憶體。
核心通過 MnPF 機制來使用這些東東,光這些資料還不足以說明系統出現瓶頸。
6.4 記憶體頁面分類
在 linux 核心中有 3 種核心頁:
* 讀取頁面——從磁碟讀入(MPF MPF
MPF)的只讀頁面,這些頁面存在於緩衝區中包括不可
改變的靜態檔案,二進位制檔案和庫檔案。核心會因需求而不斷地將他們讀入記憶體,如
果記憶體變得不夠用,核心會將他們“竊取”至空閒列表,這將導致某個應用通過 MPF MPF
將它們重新載入至記憶體。
* 髒頁面——在記憶體中被核心修改的頁面,它們將被 pdflush 守護程序回寫至磁碟, 當
記憶體不夠用時,kswapd 程序也會和 pdflush 一道進行回寫以釋放更多記憶體空間。
kswapd
* 無名頁面——它們屬於某個程序,但是沒有任何檔案或後端儲存與之關聯,它們不
能被回寫進磁碟,當記憶體不夠用時 kswapd 守護程序會將它們寫入交換空間直至 RAM RAM
釋放出來。
6.5 資料頁面磁盤迴寫
應用可能直接呼叫 fsync()或 sync()系統呼叫將髒頁面回寫入磁碟, 這些系統呼叫會直接
請求至 I/O 排程器。如果一個應用不呼叫它們,則 pdflush 守護程序會時不時地進行頁面回
寫操作。
12
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
7.0 監測磁碟 I/O
在一定條件下系統會出現 I/O 瓶頸,可由很多監測工具監測到,如 top,vmstat,iostat,
sar 等。這些工具輸入的資訊大致一樣,也有不同之處,下面將討論出現 I/O 瓶頸的情況。
7.1 計算每秒 IO 量
每一次向磁碟的 IO 請求都會花費一定時間,這主要是因為磁碟必須旋轉,磁頭必須檢
索。磁碟的旋轉通常被稱為“旋轉延遲(rotational delay)” (RD),磁頭的移動杯稱為“磁碟
檢索(disk seek)” (DS) 。因此每次 IO 請求的時間由 DS 和 RD 計算得來,磁碟的 RD 由驅動
氣的轉速所固定,一 RD 被為磁碟一轉的一半,計算一塊 10000 轉磁碟的 RD 如下:
1. 算出每轉的秒數:60 秒/10000 轉 = 0.006 秒/轉
2. 轉換為毫秒: 0.006*1000 毫秒 = 6 毫秒
3. 算出 RD 值: 6/2 = 3 毫秒
4. 加上平均檢索時間:3+3 = 6 毫秒
5. 加上內部轉移等待時間: 6+2 = 8 毫秒
6. 算出一秒的 IO 數:1000 毫秒/8 毫秒 = 125 次/秒(IOPS)
在一塊萬轉硬碟上應用每請求一次 IO 需要 8 毫秒,每秒可提供 120 到 150 次操作。
7.2 隨機 IO 和有序 IO
每次 IO 的資料量與系統的工作負荷相關。系統的負荷分兩類:有序和隨機。
7.2.1 有序 IO
iostat 命令可提供 IOPS 值和每次 IO 的資料量, 有序負荷需要一次有序地讀取大量資料,
因此每次 IO 的資料量很大,其效能取決於短時間大資料量的執行能力。
13
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
計算 IOPS 能力的方式是用每秒讀寫資料量除以每秒讀寫次數:
53040/105 = 505 KB/IO
71152/102 = 697 KB/IO
7.2 隨機 IO
隨機負荷與資料大小關係不大,與磁碟的 IOPS 值有關,web 服務,mail 服務一般屬於
此類,IO 請求相對較少,其依賴於一次可執行多少次請求,因此磁碟的 IOPS 值非常關鍵。
此資料與剛才的資料相比每次 IO 寫入的資料量差異很大:
2640/102 = 23 KB/IO
3176/130 = 24 KB/IO
7.3 當虛擬記憶體終結 I/O 時
假如系統沒有足夠的記憶體供給所有的請求時,並開始使用交換空間,和檔案系統 IO 一
樣 swap 的寫入也很慢,假如記憶體嚴重的不足,那麼這可能導致大量的頁面湧向 swap,假如
這個 swap 空間與要寫入的檔案處於同一檔案系統下,此係統將進入 IO 爭搶,這將導致系
統效能直線下降。假如頁面無法讀或寫入磁碟,那麼它們將一直停留於記憶體中,核心會開始
嘗試釋放記憶體空間,問題是 IO 通道已經嚴重阻塞且無法做任何事情,這必將導致系統核心
出錯並崩潰。
下面的 vmstat 輸出展示了這種情況:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
17 0 1250 3248 45820 1488472 30 132 992 0 2437 7657 23 50 0 23
11 0 1376 3256 45820 1488888 57 245 416 0 2391 7173 10 90 0 0
12 0 1582 1688 45828 1490228 63 131 1348 76 2432 7315 10 90 0 10
12 2 3981 1848 45468 1489824 185 56 2300 68 2478 9149 15 12 0 73
14 2 10385 2400 44484 1489732 0 87 1112 20 2515 11620 0 12 0 88
14
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
14 2 12671 2280 43644 1488816 76 51 1812 204 2546 11407 20 45 0 35
以上資料顯示大量的讀入記憶體請求(bi) ,記憶體不夠,導致資料塊不停寫入(so)交換空間,
交換空間大小不斷增長(swpd) ,同樣也出現了大量的 IO 等待時間(wa) ,這表明 CPU 因
為 IO 請求的原因而開始變慢。
在上面的例子中,swap 裝置(/dev/sda1)和檔案系統(/dev/sda3)在爭搶 IO。
7.4 判定應用 IO 使用
iotop 命令顯示每個程序的 IO 使用情況,其輸出結果與 top 命令相似,可與 iostat 命令
結合來判斷產生 IO 瓶頸的應用。
在下面的示例中,在同一磁碟上(sda2)既有讀操作(r/s)又有寫操作(w/s):
# iostat –x 1
avg-cpu: %user %nice %system %iowait %steal %idle
7.14 0.00 35.71 57.14 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 123.47 25.51 987.76 21951.02 153.97 27.76 224.29 6.85 102.04
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 123.47 25.51 987.76 21951.02 153.97 27.76 224.29 6.85 102.04
#iotop -d 5 -P
Total DISK READ: 981.23 K/s | Total DISK WRITE: 21.43 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2574 be/4 root 967.01 K/s 0.00 B/s 0.00 % 39.05 % find /
64 be/3 root 0.00 B/s 19.94 M/s 0.00 % 13.09 % smbd -D
2533 be/4 dhoch 3.63 K/s 8.72 K/s 0.00 % 1.82 % [kjournald]
2442 be/4 root 0.00 B/s 2.91 K/s 0.00 % 0.46 % iostat -x 1
2217 be/4 dhoch 0.00 B/s 1488.57 B/s 0.00 % 0.00 % mono /usr~-ior-fd=25
1985 be/4 dhoch 0.00 B/s 255.12 K/s 0.00 % 0.00 % smbd -D
iotop 的 DISK READ 和 DISK WRITE 與 iostat 的 rsec/s 和 wsec/s 相對應。
15
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
7.5 小結
I/O 效能監測可總結如下:
* 任何時間出現 CPU 等待 IO IO,說明磁碟超載。
* 計算出你的磁碟可維持的 IOPS 值。
* 判定你的應用時屬於隨機磁碟訪問型還是有序型。
* 通過對比等待時間和服務時間即可判斷磁碟是否緩慢。
* 監測交換空間和檔案系統坐在分割槽並確保他們之間不存在爭搶 IO IO。
16
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
8.0 網路監測介紹
網路是所有子系統中最難監測的一個, 因為網路比較抽象, 在監測時有很多在系統可控
制之外的因素如延遲,衝突,擁塞和丟包等對監測產生影響。下面將討論的是乙太網、IP、
TCP 的效能監測。
8.1 乙太網配置設定
除非有明確的設定, 所有乙太網的速度都是自動協商的, 這很大程度上是由於歷史原因
造成的,早些時候一個網路裡經常有不同網速和雙工模式的網路裝置。
大多數企業乙太網是 100BaseTX 或 1000BaseTX,可以使用 ethtool 工具來判斷一個系統的
網速。
下面的示例中一個擁有 100BaseTX 網絡卡的機器工作在 10BaseTX 下:
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 10Mb/s
Duplex: Half
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
下面將其強制設定為 100BaseTX 模式:
# ethtool -s eth0 speed 100 duplex full autoneg off
# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
17
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes
8.2 網路吞吐量監測
監測網路吞吐量最好的辦法是在兩個系統之間傳送流量並統計其延遲和速度。
8.2.0 使用 iptraf 監測本地吞吐量
iptraf 工具可提供乙太網卡的吞吐量情況:
# iptraf -d eth0
上面的資料顯示被測試系統正以 61mbps(7.65M)頻率傳送資料,相比於 100mbps 網路這
有點低。
8.2.1 使用 netperf 監測遠端吞吐量
18
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
與 iptraf 的動態監測不一樣的是 netperf 使用可控方式測試網路, 這一點對測試一個客戶
端到一個高負載伺服器之間的吞吐量很有幫助,netperf 工具是以 C/S 模式執行。
首先需要在伺服器上執行 netperf 服務端:
server# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC
netperf 可以執行多種測試,最基本的是標準測試:
client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.230 (192.168.1.230) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.02 89.46
輸出顯示吞吐量在 89mbps 左右,伺服器和客戶端在同一網段。
從一個 10 跳的 54G 無線網進行測試只能達到 14mbps 左右:
client# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.10 14.09
從 50 跳距離區域網測試:
# netperf -H 192.168.1.215 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.1.215 (192.168.1.215) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 30.64 5.05
從外網測試:
# netperf -H litemail.org -p 1500 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
19
------------------------------------------《Linux 系統和網路效能監測》讀書筆記-------------------------------------------
litemail.org (72.249.104.148) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 31.58 0.93
通過 VPN 測試:
# netperf -H 10.0.1.129 -l 30
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
10.0.1.129 (10.0.1.129) port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384