Linux System and Performance Monitoring
Linux System and Performance Monitoring(CPU篇)
Date: 2009.07.21
Author: Darren Hoch
譯: Tonnyom[AT]hotmail.com 2009.08.10
前言: 網上其實有很多關於這方面的文章,那爲什麼還會有此篇呢,有這麼幾個原因,是我翻譯的動力,第一,概念和內容雖然老套,但都講得很透徹,而且還很全面.第二,理論結合實際,其中案例分析都不錯.第三,不花哨,採用的工具及命令都是最基本的,有助於實際操作.但本人才疏學淺,譯文大多數都是立足於自己對原文的理解,大家也可以自己去OSCAN上找原文,如果有什麼較大出入,還望留言回覆,甚是感激!
1.0 性能監控介紹
性能優化就是找到系統處理中的瓶頸以及去除這些的過程,多數管理員相信看一些相關的”cook book”就可以實現性能優化,通常通過對內核的一些配置是可以簡單的解決問題,但並不適合每個環境,性能優化其實是對OS 各子系統達到一種平衡的定義,這些子系統包括了:
CPU
Memory
IO
Network
這些子系統之間關係是相互彼此依賴的,任何一個高負載都會導致其他子系統出現問題.比如:
大量的頁調入請求導致內存隊列的擁塞
網卡的大吞吐量可能導致更多的 CPU開銷
大量的CPU開銷又會嘗試更多的內存使用請求
大量來自內存的磁盤寫請求可能導致更多的 CPU 以及 IO問題
所以要對一個系統進行優化,查找瓶頸來自哪個方面是關鍵,雖然看似是某一個子系統出現問題,其實有可能是別的子系統導致的.
1.1 確定應用類型
基於需要理解該從什麼地方來入手優化瓶頸,首先重要的一點,就是理解並分析當前系統的特點,多數系統所跑的應用類型,主要爲2種:
IO Bound(譯註:IO 範疇): 在這個範疇中的應用,一般都是高負荷的內存使用以及存儲系統,這實際上表示IO 範疇的應用,就是一個大量數據處理的過程.IO 範疇的應用不對CPU以及網絡發起更多請求(除非類似NAS這樣的網絡存儲硬件).IO 範疇的應用通常使用CPU 資源都是爲了產生IO 請求以及進入到內核調度的sleep 狀態.通常數據庫軟件(譯註:mysql,oracle等)被認爲是IO 範疇的應用類型.
CPU Bound(譯註:CPU 範疇): 在這個範疇中的應用,一般都是高負荷的CPU 佔用. CPU 範疇的應用,就是一個批量處理CPU 請求以及數學計算的過程.通常web server,mail server,以及其他類型服務被認爲是CPU 範疇的應用類型.
1.2 確定基準線統計
系統利用率情況,一般隨管理員經驗以及系統本身用途來決定.唯一要清楚的就是,系統優化希望達成什麼效果,以及哪些方面是需要優化,還有參考值是什麼?因此就建立一個基準線,這個統計數據必須是系統可用性能狀態值,用來比較不可用性能狀態值.
在以下例子中,1個系統性能的基準線快照,用來比較當高負荷時的系統性能快照.
# 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
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
從上面第一個結果可看到,最後一列(id) 表示的是空閒時間,我們可以看到,在基準線統計時,CPU 的空閒時間在79% - 100%.在第二個結果可看到,系統處於100%的佔用率以及沒有空閒時間.從這個比較中,我們就可以確定是否是CPU 使用率應該被優化.
2.0 安裝監控工具
多數 *nix系統都有一堆標準的監控命令.這些命令從一開始就是*nix 的一部分.Linux 則通過基本安裝包以及額外包提供了其他監控工具,這些安裝包多數都存在各個Linux 發佈版本中.儘管還有其他更多的開源以及第三方監控軟件,但本文檔只討論基於Linux 發佈版本的監控工具.
本章將討論哪些工具怎樣來監控系統性能.
Tool Description Base Repository
vmstat all purpose performance tool yes yes
mpstat provides statistics per CPU no yes
sar all purpose performance monitoring tool no yes
iostat provides disk statistics no yes
netstat provides network statistics yes yes
dstat monitoring statistics aggregator no in most distributions
iptraf traffic monitoring dashboard no yes
netperf Network bandwidth tool no In some distributions
ethtool reports on Ethernet interface configuration yes yes
iperf Network bandwidth tool no yes
tcptrace Packet analysis tool no yes
3.0 CPU 介紹
CPU 利用率主要依賴於是什麼資源在試圖存取.內核調度器將負責調度2種資源種類:線程(單一或者多路)和中斷.調度器去定義不同資源的不同優先權.以下列表從優先級高到低排列:
Interrupts(譯註:中斷) - 設備通知內核,他們完成一次數據處理的過程.例子,當一塊網卡設備遞送網絡數據包或者一塊硬件提供了一次IO 請求.
Kernel(System) Processes(譯註:內核處理過程) - 所有內核處理過程就是控制優先級別.
User Processes(譯註:用戶進程) - 這塊涉及”userland”.所有軟件程序都運行在這個user space.這塊在內核調度機制中處於低優先級.
從上面,我們可以看出內核是怎樣管理不同資源的.還有幾個關鍵內容需要介紹,以下部分就將介紹context(譯註:上下文切換),run queues(譯註:運行隊列)以及utilization(譯註:利用率).
3.1 上下文切換
多數現代處理器都能夠運行一個進程(單一線程)或者線程.多路超線程處理器有能力運行多個線程.然而,Linux 內核還是把每個處理器核心的雙核心芯片作爲獨立的處理器.比如,以Linux 內核的系統在一個雙核心處理器上,是報告顯示爲兩個獨立的處理器.
一個標準的Linux 內核可以運行50 至 50,000 的處理線程.在只有一個CPU時,內核將調度並均衡每個進程線程.每個線程都分配一個在處理器中被開銷的時間額度.一個線程要麼就是獲得時間額度或已搶先獲得一些具有較高優先級(比如硬件中斷),其中較高優先級的線程將從區域重新放置回處理器的隊列中.這種線程的轉換關係就是我們提到的上下文切換.
每次內核的上下文切換,資源被用於關閉在CPU寄存器中的線程和放置在隊列中.系統中越多的上下文切換,在處理器的調度管理下,內核將得到更多的工作.
3.2 運行隊列
每個CPU 都維護一個線程的運行隊列.理論上,調度器應該不斷的運行和執行線程.進程線程不是在sleep 狀態中(譯註:阻塞中和等待IO中)或就是在可運行狀態中.如果CPU 子系統處於高負荷下,那就意味着內核調度將無法及時響應系統請求.導致結果,可運行狀態進程擁塞在運行隊列裏.當運行隊列越來越巨大,進程線程將花費更多的時間獲取被執行.
比較流行的術語就是”load”,它提供當前運行隊列的詳細狀態.系統 load 就是指在CPU 隊列中有多少數目的線程,以及其中當前有多少進程線程數目被執行的組合.如果一個雙核系統執行了2個線程,還有4個在運行隊列中,則 load 應該爲 6. top 這個程序裏顯示的load averages 是指1,5,15 分鐘以內的load 情況.
3.3 CPU 利用率
CPU 利用率就是定義CPU 使用的百分比.評估系統最重要的一個度量方式就是CPU 的利用率.多數性能監控工具關於CPU 利用率的分類有以下幾種:
User Time(譯註:用戶進程時間) - 關於在user space中被執行進程在CPU 開銷時間百分比.
System Time(譯註:內核線程以及中斷時間) - 關於在kernel space中線程和中斷在CPU 開銷時間百分比.
Wait IO(譯註:IO 請求等待時間) - 所有進程線程被阻塞等待完成一次IO 請求所佔CPU 開銷idle的時間百分比.
Idle(譯註:空閒) - 一個完整空閒狀態的進程在CPU 處理器中開銷的時間百分比.
4.0 CPU 性能監控
理解運行隊列,利用率,上下文切換對怎樣CPU 性能最優化之間的關係.早期提及到,性能是相對於基準線數據的.在一些系統中,通常預期所達到的性能包括:
Run Queues - 每個處理器應該運行隊列不超過1-3 個線程.例子,一個雙核處理器應該運行隊列不要超過6 個線程.
CPU Utiliation - 如果一個CPU 被充分使用,利用率分類之間均衡的比例應該是
65% - 70% User Time
30% - 35% System Time
0% - 5% Idle Time
Context Switches - 上下文切換的數目直接關係到CPU 的使用率,如果CPU 利用率保持在上述均衡狀態時,大量的上下文切換是正常的.
很多Linux 上的工具可以得到這些狀態值,首先就是 vmstat 和 top 這2個工具.
4.1 vmstat 工具的使用
vmstat 工具提供了一種低開銷的系統性能觀察方式.因爲 vmstat 本身就是低開銷工具,在非常高負荷的服務器上,你需要查看並監控系統的健康情況,在控制窗口還是能夠使用vmstat 輸出結果.這個工具運行在2種模式下:average 和 sample 模式.sample 模式通過指定間隔時間測量狀態值.這個模式對於理解在持續負荷下的性能表現,很有幫助.下面就是
vmstat 運行1秒間隔的示例:
# 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
Table 1: The vmstat CPU statistics
Field Description
r The amount of threads in the run queue. These are threads that are runnable, but the CPU is not available to execute them.
當前運行隊列中線程的數目.代表線程處於可運行狀態,但CPU 還未能執行.
b This is the number of processes blocked and waiting on IO requests to finish.
當前進程阻塞並等待IO 請求完成的數目
in This is the number of interrupts being processed.
當前中斷被處理的數目
cs This is the number of context switches currently happening on the system.
當前kernel system中,發生上下文切換的數目
us This is the percentage of user CPU utilization.
CPU 利用率的百分比
sys This is the percentage of kernel and interrupts utilization.
內核和中斷利用率的百分比
wa This is the percentage of idle processor time due to the fact that ALL runnable threads are blocked waiting on IO.
所有可運行狀態線程被阻塞在等待IO 請求的百分比
id This is the percentage of time that the CPU is completely idle.
CPU 空閒時間的百分比
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
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
根據觀察值,我們可以得到以下結論:
1,有大量的中斷(in) 和較少的上下文切換(cs).這意味着一個單一的進程在產生對硬件設備的請求.
2,進一步顯示某單個應用,user time(us) 經常在85%或者更多.考慮到較少的上下文切換,這個應用應該還在處理器中被處理.
3,運行隊列還在可接受的性能範圍內,其中有2個地方,是超出了允許限制.
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
根據觀察值,我們可以得到以下結論:
1,上下文切換數目高於中斷數目,說明kernel中相當數量的時間都開銷在上下文切換線程.
2,大量的上下文切換將導致CPU 利用率分類不均衡.很明顯實際上等待io 請求的百分比(wa)非常高,以及user time百分比非常低(us).
3,因爲CPU 都阻塞在IO請求上,所以運行隊列裏也有相當數目的可運行狀態線程在等待執行.
4.4 mpstat 工具的使用
如果你的系統運行在多處理器芯片上,你可以使用 mpstat 命令來監控每個獨立的芯片.Linux 內核視雙核處理器爲2 CPU’s,因此一個雙核處理器的雙內核就報告有4 CPU’s 可用.
mpstat 命令給出的CPU 利用率統計值大致和 vmstat 一致,但是 mpstat 可以給出基於單個處理器的統計值.
# 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核心可用.其中2個CPU 主要處理進程運行(CPU 0 和1).第3個核心處理所有內核和其他系統功能(CPU 3).第4個核心處於idle(CPU 2).
使用 top 命令可以看到有3個進程差不多完全佔用了整個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
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 命令通過查看 PSR 這列,檢查哪個進程在佔用了哪個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 性能由以下幾個部分組成:
1,檢查system的運行隊列,以及確定不要超出每個處理器3個可運行狀態線程的限制.
2,確定CPU 利用率中user/system比例維持在70/30
3,當CPU 開銷更多的時間在system mode,那就說明已經超負荷並且應該嘗試重新調度優先級
4,當I/O 處理得到增長,CPU 範疇的應用處理將受到影響
5.0 Virtual Memory介紹
虛擬內存就是採用硬盤對物理內存進行擴展,所以對可用內存的增加是要相對在一個有效範圍內的.內核會寫當前未使用內存塊的內容到硬盤上,此時這部分內存被用於其它用途.當再一次需要原始內容時,此時再讀回到內存中.這對於用戶來說,是完全透明的;在Linux 下運行的程序能夠看到,也僅僅是大量的可用內存,同時也不會留意到,偶爾還有部分是駐留在磁盤上的.當然,在硬盤上進行讀和寫,都是很慢的(大約會慢上千倍),相對於使用真實內存的話,因此程序無法運行的更快.用硬盤的一部分作爲Virtual Memory,這就被稱爲”swap space”(譯註:交換空間).
5.1 Virtual Memory Pages
虛擬內存被分爲很多 pages(譯註:頁),在X86架構中,每個虛擬內存頁爲 4KB.當內核寫內存到磁盤或者讀磁盤到內存,這就是一次寫內存到頁的過程.內核通常是在swap 分區和文件系統之間進行這樣的操作.
5.2 Kernel Memory Paging
內存分頁在正常情況下總是活躍的,與memory swapping(譯註:內存交換)之間不要搞錯了.內存分頁是指內核會定期將內存中的數據同步到硬盤,這個過程就是Memory Paging.日復一日,應用最終將會消耗掉所有的內存空間.考慮到這點,內核就必須經常掃描內存空間並且收回其中未被使用的內存頁,然後再重新分配內存空間給其他應用使用.
5.3 The Page Frame Reclaim Algorithm(PFRA)(譯註:頁框回收算法)
PFRA 就是OS 內核用來回收並釋放內存空間的算法.PFRA 選擇哪個內存頁被釋放是基於內存頁類型的.頁類型有以下幾種:
Unreclaimable –鎖定的，內核保留的頁面
Swappable –匿名的內存頁
Syncable –通過硬盤文件備份的內存頁
Discardable –靜態頁和被丟棄的頁
除了第一種（Unreclaimable）之外其餘的都可以被PFRA進行回收.
與PFRA 相關的,還包括kswapd 內核線程以及Low On Memory Reclaiming(LMR算法) 這2種進程和實現.
5.4 kswapd
kswapd 進程負責確保內存空間總是在被釋放中.它監控內核中的pages_high和pages_low閥值.如果空閒內存的數值低於 pages_low,則每次 kswapd 進程啓動掃描並嘗試釋放32個free pages.並一直重複這個過程,直到空閒內存的數值高於 pages_high.
kswapd 進程完成以下幾個操作:
1,如果該頁處於未修改狀態,則將該頁放置回空閒列表中.
2,如果該頁處於已修改狀態並可備份迴文件系統,則將頁內容寫入到磁盤.
3,如果該頁處於已修改狀態但沒有任何磁盤備份,則將頁內容寫入到swap device.
# ps -ef | grep kswapd
root 30 1 0 23:01 ? 00:00:00 [kswapd0]
5.5 Kernel Paging with pdflush
pdflush 進程負責將內存中的內容和文件系統進行同步操作.也就是說,當一個文件在內存中進行修改後, pdflush 將負責寫回到磁盤上.
# ps -ef | grep pdflush
root 28 3 0 23:01 ? 00:00:00 [pdflush]
root 29 3 0 23:01 ? 00:00:00 [pdflush]
當內存中存在10% 的髒頁,pdflush 將被啓動同步髒頁迴文件系統裏.這個參數值可以通過 vm.dirty_background_ratio 來進行調整.
(譯註:
Q:什麼是髒頁?
A:由於內存中頁緩存的緩存作用,寫操作實際上都是延遲的.當頁緩存中的數據比磁盤存儲的數據還要更新時,那麼該數據就被稱做髒頁.)
# sysctl -n vm.dirty_background_ratio
10
在多數環境下,Pdflush與PFRA是獨立運行的,當內核調用LMR時,LMR 就觸發pdflush將髒頁寫入到磁盤裏.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
在2.4 內核下,一個高負荷的內存環境中,系統將遇到交換過程中不斷的崩潰.這是因爲PFRA 從一個運行進程中,偷取其中一個內存頁並嘗試使用.導致結果就是,這個進程如果要回收那個頁時,要是沒有就會嘗試再去偷取這個頁,這樣一來,就越來越糟糕了.在2.6 內核下,使用”Swap token”修復了這個BUG,用來防止PFRA 不斷從一個進程獲取同一個頁.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5.6 案例學習:大量的入口I/O
vmstat 工具報告裏除了CPU 使用情況,還包括了虛擬內存.以下就是vmstat 輸出中關於虛擬內存的部分:
Table 2: The vmstat Memory Statistics
Field Description
Swapd The amount of virtual memory in KB currently in use. As free memory reaches low thresholds, more data is paged to the swap device.
當前虛擬內存使用的總額(單位:KB).空閒內存達到最低的閥值時,更多的數據被轉換成頁到交換設備中.
Free The amount of physical RAM in kilobytes currently available to running applications.
當前內存中可用空間字節數.
Buff The amount of physical memory in kilobytes in the buffer cache as a result of read() and write() operations.
當前內存中用於read()和write()操作的緩衝區中緩存字節數
Cache The amount of physical memory in kilobytes mapped into process address space.
當前內存中映射到進程地址空間字節數
So The amount of data in kilobytes written to the swap disk.
寫入交換空間的字節數總額
Si The amount of data in kilobytes written from the swap disk back into RAM.
從交換空間寫回內存的字節數總額
Bo The amount of disk blocks paged out from the RAM to the filesystem or swap device.
磁盤塊頁面從內存到文件或交換設備的總額
Bi The amount of disk blocks paged into RAM from the filesystem or swap device.
磁盤塊頁面從文件或交換設備到內存的總額
以下 vmstat 的輸出結果,就是演示一個在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
根據觀察值,我們可以得到以下結論:
1,大量的disk pages(bi)被寫入內存,很明顯在進程地址空間裏,數據緩存(cache)也在不斷的增長.
2,在這個時間點上,空閒內存(free) 始終保持在17MB,即使數據從硬盤讀入而在消耗RAM.
3,爲了維護空閒列表, kswapd 從讀/寫緩存區(buff)中獲取內存並分配到空閒列表裏.很明顯可以看到buffer cache(buff) 在逐漸的減少中.
4, 同時kswapd 進程不斷的寫髒頁到swap device(so)時,很明顯虛擬內存的利用率是在逐漸的增加中(swpd).
5.7 結論
監控虛擬內存性能由以下幾個部分組成:
1,當系統中出現較少的頁錯誤,獲得最好的響應時間,是因爲memory caches(譯註:內存高速緩存)比disk caches更快(譯註:磁盤高速緩存).
2,較少的空閒內存,是件好事情,那意味着緩存的使用更有效率.除非在不斷的寫入swap device和disk.
3,如果系統不斷報告,swap device總是繁忙中,那就意味着內存已經不足,需要升級了.
6.0 I/O 監控介紹
磁盤I/O 子系統是Linux 系統中最慢的部分.這個主要是歸於CPU到物理操作磁盤之間距離(譯註:盤片旋轉以及尋道).如果拿讀取磁盤和內存的時間作比較就是分鐘級到秒級,這就像7天和7分鐘的區別.因此本質上,Linux 內核就是要最低程度的降低I/O 數.本章將訴述內核在磁盤和內存之間處理數據的這個過程中,哪些地方會產生I/O.
6.1 讀和寫數據 - 內存頁
Linux 內核將硬盤I/O 進行分頁,多數Linux 系統的默認頁大小爲4K.讀和寫磁盤塊進出到內存都爲4K 頁大小.你可以使用time 這個命令加-v 參數,來檢查你係統中設置的頁大小:
# /usr/bin/time -v date
<snip>
Page size (bytes): 4096
<snip>
6.2 Major and Minor Page Faults(譯註:主要頁錯誤和次要頁錯誤)
Linux,類似多數的UNIX 系統,使用一個虛擬內存層來映射硬件地址空間.當一個進程被啓動,內核先掃描CPU caches和物理內存.如果進程需要的數據在這2個地方都沒找到,就需要從磁盤上讀取,此時內核過程就是major page fault(MPF).MPF 要求磁盤子系統檢索頁並緩存進RAM.
一旦內存頁被映射進內存的buffer cache(buff)中,內核將嘗試從內存中讀取或寫入,此時內核過程就是minor page fault(MnPF).與在磁盤上操作相比,MnPF 通過反覆使用內存中的內存頁就大大的縮短了內核時間.
以下的例子,使用time 命令驗證了,當進程啓動後,MPF 和 MnPF 的變化情況.第一次運行進程,MPF 會更多:
# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 163
Minor (reclaiming a frame) page faults: 5918
<snip>
第二次再運行時,內核已經不需要進行MPF了,因爲進程所需的數據已經在內存中:
# /usr/bin/time -v evolution
<snip>
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 5581
<snip>
6.3 The File Buffer Cache(譯註:文件緩存區)
文件緩存區就是指,內核將MPF 過程最小化,MnPF 過程最大化.隨着系統不斷的產生I/O,buffer cache也將不斷的增加.直到內存不夠,以及系統需要釋放老的內存頁去給其他用戶進程使用時,系統就會丟棄這些內存頁.結果是,很多sa(譯註:系統管理員)對系統中過少的free memory(譯註:空閒內存)表示擔心,實際上這是系統更高效的在使用caches.
以下例子,是查看/proc/meminfo 文件:
# cat /proc/meminfo
MemTotal: 2075672 kB
MemFree: 52528 kB
Buffers: 24596 kB
Cached: 1766844 kB
<snip>
可以看出,這個系統總計有2GB (Memtotal)的可用內存.當前的空閒內存爲52MB (MemFree),有24 MB內存被分配磁盤寫操作(Buffers),還有1.7 GB頁用於讀磁盤(Cached).
內核這樣是通過MnPF機制,而不代表所有的頁都是來自磁盤.通過以上部分,我們不可能確認系統是否處於瓶頸中.
6.4 Type of Memory Pages
在Linux 內核中,memory pages有3種,分別是:
1,Read Pages - 這些頁通過MPF 從磁盤中讀入,而且是隻讀.這些頁存在於Buffer Cache中以及包括不能夠修改的靜態文件,二進制文件,還有庫文件.當內核需要它們時,將讀取到內存中.如果內存不足,內核將釋放它們回空閒列表中.程序再次請求時,則通過MPF 再次讀回內存.
2,Dirty Pages - 這些頁是內核在內存中已經被修改過的數據頁.當這些頁需要同步回磁盤上,由pdflush 負責寫回磁盤.如果內存不足,kswapd (與pdflush 一起)將這些頁寫回到磁盤上並釋放更多的內存.
3,Anonymous Pages - 這些頁屬於某個進程,但是沒有任何磁盤文件和它們有關.他們不能和同步回磁盤.如果內存不足,kswapd 將他們寫入swap 分區上並釋放更多的內存(”swapping” pages).
6.5 Writing Data Pages Back to Disk
應用程序有很多選擇可以寫髒頁回磁盤上,可通過I/O 調度器使用 fsync() 或 sync() 這樣的系統函數來實現立即寫回.如果應用程序沒有調用以上函數,pdflush 進程會定期與磁盤進行同步.
# ps -ef | grep pdflush
root 186 6 0 18:04 ? 00:00:00 [pdflush]
7.0 監控 I/O
當覺得系統中出現了I/O 瓶頸時,可以使用標準的監控軟件來查找原因.這些工具包括了top,vmstat,iostat,sar.它們的輸出結果一小部分是很相似,不過每個也都提供了各自對於性能不同方面的解釋.以下章節就將討論哪些情況會導致I/O 瓶頸的出現.
7.1 Calculating IO’s Per Second(譯註:IOPS 的計算)
每個I/O 請求到磁盤都需要若干時間.主要是因爲磁盤的盤邊必須旋轉,機頭必須尋道.磁盤的旋轉常常被稱爲”rotational delay”(RD),機頭的移動稱爲”disk seek”(DS).一個I/O 請求所需的時間計算就是DS加上RD.磁盤的RD 基於設備自身RPM 單位值(譯註:RPM 是Revolutions Perminute的縮寫,是轉/每分鐘,代表了硬盤的轉速).一個RD 就是一個盤片旋轉的
半圓.如何計算一個10K RPM設備的RD 值呢:
1, 10000 RPM / 60 seconds (10000/60 = 166 RPS)
2, 轉換爲 166分之1 的值(1/166 = 0.006 seconds/Rotation)
3, 單位轉換爲毫秒(6 MS/Rotation)
4, 旋轉半圓的時間(6/2 = 3MS) 也就是 RD
5, 加上平均3 MS 的尋道時間 (3MS + 3MS = 6MS)
6, 加上2MS 的延遲(6MS + 2MS = 8MS)
7, 1000 MS / 8 MS (1000/8 = 125 IOPS)
每次應用程序產生一個I/O,在10K RPM磁盤上都要花費平均 8MS.在這個固定時間裏,磁盤將盡可能且有效率在進行讀寫磁盤.IOPS 可以計算出大致的I/O 請求數,10K RPM 磁盤有能力提供120-150 次IOPS.評估IOPS 的效能,可用每秒讀寫I/O 字節數除以每秒讀寫IOPS 數得出.
7.2 Random vs Sequential I/O(譯註:隨機/順序 I/O)
per I/O產生的KB 字節數是與系統本身workload相關的,有2種不同workload的類型,它們是sequential和random.
7.2.1 Sequential I/O(譯註:順序IO)
iostat 命令提供信息包括IOPS 和每個I/O 數據處理的總額.可使用iostat -x 查看.順序的workload是同時讀順序請求大量的數據.這包括的應用,比如有商業數據庫(database)在執行大量的查詢和流媒體服務.在這個workload 中,KB per I/O 的比率應該是很高的.Sequential workload 是可以同時很快的移動大量數據.如果每個I/O 都節省了時間,那就意味了能帶來更多的數據處理.
# iostat -x 1
avg-cpu: %user %nice %sys %idle
0.00 0.00 57.1 4 42.86
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 12891.43 0.00 105.71 0.00 1 06080.00 0.00 53040.00 1003.46 1099.43 3442.43 26.49 280.00
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 12857.14 0.00 5.71 0.00 105782.86 0.00 52891.43 18512.00 559.14 780.00 490.00 280.00
/dev/sda3 0.00 34.29 0.00 100.00 0.00 297.14 0.00 148.57 2.97 540.29 594.57 24.00 240.00
avg-cpu: %user %nice %sys %idle
0.00 0.00 23.53 76.47
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 17320.59 0.00 102.94 0.00 142305.88 0.00 71152.94 1382.40 6975.29 952.29 28.57 294.12
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 16844.12 0.00 102.94 0.00 138352.94 0.00 69176.47 1344.00 6809.71 952.29 28.57 294.12
/dev/sda3 0.00 476.47 0.00 0.00 0.00 952.94 0.00 1976.47 0.00 165.59 0.00 0.00 276.47
評估IOPS 的效能,可用每秒讀寫I/O 字節數除以每秒讀寫IOPS 數得出,比如
rkB/s 除以 r/s
wkB/s 除以 w/s
53040/105 = 505KB per I/O
71152/102 = 697KB per I/O
在上面例子可看出,每次循環下,/dev/sda 的per I/O 都在增加.
7.2.2 Random I/O(譯註:隨機IO)
Random的worklaod環境下,不依賴於數據大小的多少,更多依賴的是磁盤的IOPS 數.Web和Mail 服務就是典型的Random workload.I/O 請求內容都很小.Random workload是同時每秒會有更多的請求數產生.所以,磁盤的IOPS 數是關鍵.
# iostat -x 1
avg-cpu: %user %nice %sys %idle
2.04 0.00 97.96 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 633.67 3.06 102.31 24.49 5281.63 12.24 2640.82 288.89 73.67 113.89 27.22 50.00
/dev/sda1 0.00 5.10 0.00 2.04 0.00 57.14 0.00 28.57 28.00 1.12 55.00 55.00 11.22
/dev/sda2 0.00 628.57 3.06 100.27 24.49 5224.49 12.24 2612.24 321.50 72.55 121.25 30.63 50.00
/dev/sda3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
avg-cpu: %user %nice %sys %idle
2.15 0.00 97.85 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 41.94 6.45 130.98 51.61 352.69 25.81 3176.34 19.79 2.90 286.32 7.37 15.05
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 41.94 4.30 130.98 34.41 352.69 17.20 3176.34 21.18 2.90 320.00 8.24 15.05
/dev/sda3 0.00 0.00 2.15 0.00 17.20 0.00 8.60 0.00 8.00 0.00 0.00 0.00 0.00
計算方式和之前的公式一致:
2640/102 = 23KB per I/O
3176/130 = 24KB per I/O
(譯註:對於順序I/O來說,主要是考慮讀取大量數據的能力即KB per request.對於隨機I/O系統,更需要考慮的是IOPS值)
7.3 When Virtual Memory Kills I/O
如果系統沒有足夠的RAM 響應所有的請求,就會使用到SWAP device.就像使用文件系統I/O,使用SWAP device 代價也很大.如果系統已經沒有物理內存可用,那就都在SWAP disk上創建很多很多的內存分頁,如果同一文件系統的數據都在嘗試訪問SWAP device,那系統將遇到I/O 瓶頸.最終導致系統性能的全面崩潰.如果內存頁不能夠及時讀或寫磁盤,它們就一直保留在RAM中.如果保留時間太久,內核又必須釋放內存空間.問題來了,I/O 操作都被阻塞住了,什麼都沒做就被結束了,不可避免地就出現kernel panic和system crash.
下面的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 2 12671 2280 43644 1488816 76 51 1812 204 2546 11407 20 45 0 35
這個結果可看出,大量的讀請求回內存(bi),導致了空閒內存在不斷的減少(free).這就使得系統寫入swap device的塊數目(so)和swap 空間(swpd)在不斷增加.同時看到CPU WIO time(wa)百分比很大.這表明I/O 請求已經導致CPU 開始效率低下.
要看swaping 對磁盤的影響,可使用iostat 檢查swap 分區
# iostat -x 1
avg-cpu: %user %nice %sys %idle
0.00 0.00 100.00 0.00
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 1766.67 4866.67 1700.00 38933.33 31200.00 19466.67 15600.00 10.68 6526.67 100.56 5.08 3333.33
/dev/sda1 0.00 933.33 0.00 0.00 0.00 7733.33 0.00 3866.67 0.00 20.00 2145.07 7.37 200.00
/dev/sda2 0.00 0.00 4833.33 0.00 38666.67 533.33 19333.33 266.67 8.11 373.33 8.07 6.90 87.00
/dev/sda3 0.00 833.33 33.33 1700.00 266.67 22933.33 133.33 11466.67 13.38 6133.33 358.46 11.35 1966.67
在這個例子中,swap device(/dev/sda1) 和 file system device(/dev/sda3)在互相作用於I/O. 其中任一個會有很高寫請求(w/s),也會有很高wait time(await),或者較低的服務時間比率(svctm).這表明2個分區之間互有聯繫,互有影響.
7.4 結論
I/O 性能監控包含了以下幾點:
1,當CPU 有等待I/O 情況時,那說明磁盤處於超負荷狀態.
2,計算你的磁盤能夠承受多大的IOPS 數.
3,確定你的應用是屬於隨機或者順序讀取磁盤.
4,監控磁盤慢需要比較wait time(await) 和 service time(svctm).
5,監控swap 和系統分區,要確保virtual memory不是文件系統I/O 的瓶頸.8.0 Network 監控介紹
在所有的子系統監控中,網絡是最困難的.這主要是由於網絡概念很抽象.當監控系統上的網絡性能,這有太多因素.這些因素包括了延遲,衝突,擁擠和數據包丟失.
這個章節討論怎麼樣檢查Ethernet(譯註:網卡),IP,TCP的性能.
8.1 Ethernet Configuration Settings(譯註:網卡配置的設置)
除非很明確的指定,幾乎所有的網卡都是自適應網絡速度.當一個網絡中有很多不同的網絡設備時,會各自採用不同的速率和工作模式.
多數商業網絡都運行在100 或 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: 0×00000007 (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
Duplex: Full
Port: MII
PHYAD: 32
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0×00000007 (7)
Link detected: yes8.2 Monitoring Network Throughput(譯註:網絡吞吐量監控)
接口之間的同步並不意味着僅僅有帶寬問題.重要的是,如何管理並優化,這2臺主機之間的交換機,網線,或者路由器.測試網絡吞吐量最好的方式就是,在這2個系統之間互相發送數據傳輸並統計下來,比如延遲和速度.
8.2.0 使用iptraf 查看本地吞吐量
iptraf 工具(http://iptraf.seul.org),提供了每個網卡吞吐量的儀表盤.
#iptraf -d eth0
Figure 1: Monitoring for Network Throughput
從輸出中可看到,該系統發送傳輸率(譯註:Outgoing rates)爲 61 mbps,這對於100 mbps網絡來說,有點慢.
8.2.1 使用netperf 查看終端吞吐量
不同於iptraf 被動的在本地監控流量,netperf 工具可以讓管理員,執行更加可控的吞吐量監控.對於確定從客戶端工作站到一個高負荷的服務器端(比如file 或web server),它們之間有多少吞吐量是非常有幫助的.netperf 工具運行的是client/server 模式.
完成一個基本可控吞吐量測試,首先netperf server 必須運行在服務器端系統上:
server# netserver
Starting netserver at port 12865
Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPECnetperf 工具可能需要進行多重採樣.多數基本測試就是一次標準的吞吐量測試.以下例子就是,一個LAN(譯註:局域網) 環境下,從client 上執行一次30秒的TCP 吞吐量採樣:
從輸出可看出,該網絡的吞吐量大致在89 mbps 左右.server(192.168.1.215) 與client 在同一LAN 中.這對於100 mbps網絡來說,性能非常好.
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/sec87380 16384 16384 30.02 89.46
從LAN 切換到具備54G(譯註:Wireless-G是未來54Mbps無線網聯網標準)無線網絡路由器中,並在10 英尺範圍內測試時.該吞吐量就急劇的下降.在最大就爲54 MBits的可能下,筆記本電腦可實現總吞吐量就爲14 MBits.
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/sec87380 16384 16384 30.10 14.09
如果在50英尺範圍內呢,則進一步會下降至5 MBits.
# 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/sec87380 16384 16384 30.64 5.05
如果從LAN 切換到互聯網上,則吞吐量跌至1 Mbits下了.
# 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
litemail.org (72.249.104.14port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec87380 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/sec87380 16384 16384 31.99 0.51
另外,netperf 可以幫助測試每秒總計有多少的TCP 請求和響應數.通過建立單一TCP 連接並順序地發送多個請求/響應(ack 包來回在1個byte 大小).有點類似於RDBMS 程序在執行多個交易或者郵件服務器在同一個連接管道中發送郵件.
以下例子在30 秒的持續時間內,模擬TCP 請求/響應:
client# netperf -t TCP_RR -H 192.168.1.230 -l 30
TCP REQUEST/RESPONSE 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
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec16384 87380 1 1 30.00 4453.80
16384 87380在輸出中看出,這個網絡支持的處理速率爲每秒4453 psh/ack(包大小爲1 byte).這其實是理想狀態下,因爲實際情況時,多數requests(譯註:請求),特別是responses(譯註:響應),都大於1 byte.
現實情況下,netperf 一般requests 默認使用2K大小,responses 默認使用32K大小:
client# netperf -t TCP_RR -H 192.168.1.230 -l 30 — -r 2048,32768
TCP REQUEST/RESPONSE 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
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec16384 87380 2048 32768 30.00 222.37
16384 87380這個處理速率減少到了每秒222.
8.2.2 使用iperf 評估網絡效率
基於都是需要在2端檢查連接情況下,iperf 和netperf 很相似.不同的是,iperf 更深入的通過windows size和QOS 設備來檢查TCP/UDP 的效率情況.這個工具,是給需要優化TCP/IP stacks以及測試這些stacks 效率的管理員們量身定做的.
iperf 作爲一個二進制程序,可運行在server 或者client 任一模式下.默認使用50001 端口.
首先啓動server 端(192.168.1.215):
server# iperf -s -D
Running Iperf Server as a daemon
The Iperf daemon process ID : 3655
————————————————————
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
————————————————————在以下例子裏,一個無線網絡環境下,其中client 端重複運行iperf,用於測試網絡的吞吐量情況.這個環境假定處於被充分利用狀態,很多主機都在下載ISO images文件.
首先client 端連接到server 端(192.168.1.215),並在總計60秒時間內,每5秒進行一次帶寬測試的採樣.
client# iperf -c 192.168.1.215 -t 60 -i 5
————————————————————
Client connecting to 192.168.1.215, TCP port 5001
TCP window size: 25.6 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 51978 connected with
192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 6.22 MBytes 10.4 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 5.0-10.0 sec 6.05 MBytes 10.1 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 10.0-15.0 sec 5.55 MBytes 9.32 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 15.0-20.0 sec 5.19 MBytes 8.70 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 20.0-25.0 sec 4.95 MBytes 8.30 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 25.0-30.0 sec 5.21 MBytes 8.74 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 30.0-35.0 sec 2.55 MBytes 4.29 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 35.0-40.0 sec 5.87 MBytes 9.84 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 40.0-45.0 sec 5.69 MBytes 9.54 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 45.0-50.0 sec 5.64 MBytes 9.46 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 50.0-55.0 sec 4.55 MBytes 7.64 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 55.0-60.0 sec 4.47 MBytes 7.50 Mbits/sec
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-60.0 sec 61.9 MBytes 8.66 Mbits/sec這臺主機的其他網絡傳輸,也會影響到這部分的帶寬採樣.所以可以看到總計60秒時間內,都在4 - 10 MBits 上下起伏.
除了TCP 測試之外,iperf 的UDP 測試主要是評估包丟失和抖動.
接下來的iperf 測試,是在同樣的54Mbit G標準無線網絡中.在早期的示範例子中,目前的吞吐量只有9 Mbits.
# iperf -c 192.168.1.215 -b 10M
WARNING: option -b implies udp testing
————————————————————
Client connecting to 192.168.1.215, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size: 107 KByte (default)
————————————————————
[ 3] local 192.168.224.150 port 33589 connected with 192.168.1.215 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 11.8 MBytes 9.90 Mbits/sec
[ 3] Sent 8420 datagrams
[ 3] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 6.50 MBytes 5.45 Mbits/sec 0.480 ms 3784/ 8419 (45%)
[ 3] 0.0-10.0 sec 1 datagrams received out-of-order從輸出中可看出,在嘗試傳輸10M 的數據時,實際上只產生了5.45M.卻有45% 的包丟失.
8.3 Individual Connections with tcptrace
tcptrace 工具提供了對於某一具體連接裏,詳細的TCP 相關信息.該工具使用libcap 來分析某一具體TCP sessions.該工具彙報的信息,有時很難在某一TCP stream被發現.這些信息
包括了有:
1,TCP Retransmissions(譯註:IP 轉播) - 所有數據大小被髮送所需的包總額
2,TCP Windows Sizes - 連接速度慢與小的windows sizes 有關
3,Total throughput of the connection - 連接的吞吐量
4,Connection duration - 連接的持續時間8.3.1 案例學習 - 使用tcptrace
tcptrace 工具可能已經在部分Linux 發佈版中有安裝包了,該文作者通過網站,下載的是源碼安裝包:http://dag.wieers.com/rpm/packages /tcptrace.tcptrace 需要libcap 基於文件輸入方式使用.在tcptrace 沒有選項的情況下,默認每個唯一的連接過程都將被捕獲.
以下例子是,使用libcap 基於輸入文件爲bigstuff:
# tcptrace bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:01.634065, 89413 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
1: 192.168.1.60:pcanywherestat - 192.168.1.102:2571 (a2b) 404> 450< 2: 192.168.1.60:3356 - ftp.strongmail.net:21 (c2d) 35> 21< 3: 192.168.1.60:3825 - ftp.strongmail.net:65023 (e2f) 5> 4< (complete) 4: 192.168.1.102:1339 - 205.188.8.194:5190 (g2h) 6> 6< 5: 192.168.1.102:1490 - cs127.msg.mud.yahoo.com:5050 (i2j) 5> 5< 6: py-in-f111.google.com:993 - 192.168.1.102:3785 (k2l) 13> 14<上面的輸出中,每個連接都有對應的源主機和目的主機.tcptrace 使用-l 和-o 選項可查看某一連接更詳細的數據.
以下的結果,就是在bigstuff 文件中,#16 連接的相關統計數據:
# tcptrace -l -o1 bigstuff
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.529361, 276008 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
32 TCP connections traced:
TCP connection 1:
host a: 192.168.1.60:pcanywherestat
host b: 192.168.1.102:2571
complete conn: no (SYNs: 0) (FINs: 0)
first packet: Sun Jul 20 15:58:05.472983 2008
last packet: Sun Jul 20 16:00:04.564716 2008
elapsed time: 0:01:59.091733
total packets: 854
filename: bigstuff
a->b: b->a:
total packets: 404 total packets: 450
ack pkts sent: 404 ack pkts sent: 450
pure acks sent: 13 pure acks sent: 320
sack pkts sent: 0 sack pkts sent: 0
dsack pkts sent: 0 dsack pkts sent: 0
max sack blks/ack: 0 max sack blks/ack: 0
unique bytes sent: 52608 unique bytes sent: 10624
actual data pkts: 391 actual data pkts: 130
actual data bytes: 52608 actual data bytes: 10624
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
zwnd probe pkts: 0 zwnd probe pkts: 0
zwnd probe bytes: 0 zwnd probe bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 391 pushed data pkts: 130
SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0
urgent data pkts: 0 pkts urgent data pkts: 0 pkts
urgent data bytes: 0 bytes urgent data bytes: 0 bytes
mss requested: 0 bytes mss requested: 0 bytes
max segm size: 560 bytes max segm size: 176 bytes
min segm size: 48 bytes min segm size: 80 bytes
avg segm size: 134 bytes avg segm size: 81 bytes
max win adv: 19584 bytes max win adv: 65535 bytes
min win adv: 19584 bytes min win adv: 64287 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 19584 bytes avg win adv: 64949 bytes
initial window: 160 bytes initial window: 0 bytes
initial window: 2 pkts initial window: 0 pkts
ttl stream length: NA ttl stream length: NA
missed data: NA missed data: NA
truncated data: 36186 bytes truncated data: 5164 bytes
truncated packets: 391 pkts truncated packets: 130 pkts
data xmit time: 119.092 secs data xmit time: 116.954 secs
idletime max: 441267.1 ms idletime max: 441506.3 ms
throughput: 442 Bps throughput: 89 Bps8.3.2 案例學習 - 計算轉播率
幾乎不可能確定說哪個連接會有嚴重不足的轉播問題,只是需要分析,使用tcptrace 工具可以通過過濾機制和布爾表達式來找出出問題的連接.一個很繁忙的網絡中,會有很多的連接,幾乎所有的連接都會有轉播.找出其中最多的一個,這就是問題的關鍵.
下面的例子裏,tcptrace 將找出那些轉播大於100 segments(譯註:分段數)的連接:
# tcptrace -f’rexmit_segs>100′ bigstuff
Output filter: ((c_rexmit_segs>100)OR(s_rexmit_segs>100))
1 arg remaining, starting with ‘bigstuff’
Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004146108 packets seen, 145992 TCP packets traced
elapsed wallclock time: 0:00:00.687788, 212431 pkts/sec analyzed
trace file elapsed time: 0:09:20.358860
TCP connection info:
16: ftp.strongmail.net:65014 - 192.168.1.60:2158 (ae2af) 18695> 9817< 在這個輸出中,是#16 這個連接裏,超過了100 轉播.現在,使用以下命令查看關於這個連接的其他信息: # tcptrace -l -o16 bigstuff arg remaining, starting with ‘bigstuff’ Ostermann’s tcptrace — version 6.6.7 — Thu Nov 4, 2004 146108 packets seen, 145992 TCP packets traced elapsed wallclock time: 0:00:01.355964, 107752 pkts/sec analyzed trace file elapsed time: 0:09:20.358860 TCP connection info: 32 TCP connections traced: ================================ TCP connection 16: host ae: ftp.strongmail.net:65014 host af: 192.168.1.60:2158 complete conn: no (SYNs: 0) (FINs: 1) first packet: Sun Jul 20 16:04:33.257606 2008 last packet: Sun Jul 20 16:07:22.317987 2008 elapsed time: 0:02:49.060381 total packets: 28512 filename: bigstuff ae->af: af->ae:unique bytes sent: 25534744 unique bytes sent: 0
actual data pkts: 18695 actual data pkts: 0
actual data bytes: 25556632 actual data bytes: 0
rexmt data pkts: 1605 rexmt data pkts: 0
rexmt data bytes: 2188780 rexmt data bytes: 0計算轉播率:
rexmt/actual * 100 = Retransmission rate1605/18695* 100 = 8.5%
這個慢連接的原因,就是因爲它有8.5% 的轉播率.
8.3.3 案例學習 - 計算轉播時間
tcptrace 工具有一系列的模塊展示不同的數據,按照屬性,其中就有protocol(譯註:協議),port(譯註:端口),time等等.Slice module使得你可觀察在一段時間內的TCP 性能.你可以在一系列的轉發過程中,查看其他性能數據,以確定找出瓶頸.
以下例子示範了,tcptrace 是怎樣使用slice 模式的:
# tcptrace –xslice bigfile
以上命令會創建一個slice.dat 文件在現在的工作目錄中.這個文件內容,包含是每15秒間隔內轉播的相關信息:
# ls -l slice.dat
-rw-r–r– 1 root root 3430 Jul 10 22:50 slice.dat
# more slice.dat
date segs bytes rexsegs rexbytes new active
————— ——– ——– ——– ——– ——– ——–
22:19:41.913288 46 5672 0 0 1 1
22:19:56.913288 131 25688 0 0 0 1
22:20:11.913288 0 0 0 0 0 0
22:20:26.913288 5975 4871128 0 0 0 1
22:20:41.913288 31049 25307256 0 0 0 1
22:20:56.913288 23077 19123956 40 59452 0 1
22:21:11.913288 26357 21624373 5 7500 0 1
22:21:26.913288 20975 17248491 3 4500 12 13
22:21:41.913288 24234 19849503 10 15000 3 5
22:21:56.913288 27090 22269230 36 53999 0 2
22:22:11.913288 22295 18315923 9 12856 0 2
22:22:26.913288 8858 7304603 3 4500 0 18.4 結論
監控網絡性能由以下幾個部分組成:
1,檢查並確定所有網卡都工作在正確的速率.
2,檢查每塊網卡的吞吐量,並確認其處於服務時的網絡速度.
3,監控網絡流量的類型,並確定適當的流量優先級策略.結束語: 這是該譯文的最後一篇,在這篇中,作者提供了一個案例環境,用之前幾篇所闡述的理論以及涉及到的工具,對其進行一個整體的系統性能檢查.對大家更好理解系統性能監控,進行一次實戰演習.
BTW:在中文技術網站上,類似內容的文章,大體是來自該作者06-07年所著論文,此譯文是建立在作者爲OSCON 2009重寫基礎上的.所以部分內容可能會存在重複雷同,特此說明下.附錄 A: 案例學習 - 性能監控之循序漸進
某一天,一個客戶打電話來需要技術幫助,並抱怨平常15秒就可以打開的網頁現在需要20分鐘纔可以打開.
具體系統配置如下:
RedHat Enterprise Linux 3 update 7
Dell 1850 Dual Core Xenon Processors, 2 GB RAM, 75GB 15K Drives
Custom LAMP software stack(譯註:Llinux+apache+mysql+php 環境)性能分析之步驟
1. 首先使用vmstat 查看大致的系統性能情況:
# vmstat 1 10
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 249844 19144 18532 1221212 0 0 7 3 22 17 25 8 17 18
0 1 249844 17828 18528 1222696 0 0 40448 8 1384 1138 13 7 65 14
0 1 249844 18004 18528 1222756 0 0 13568 4 623 534 3 4 56 37
2 0 249844 17840 18528 1223200 0 0 35200 0 1285 1017 17 7 56 20
1 0 249844 22488 18528 1218608 0 0 38656 0 1294 1034 17 7 58 18
0 1 249844 21228 18544 1219908 0 0 13696 484 609 559 5 3 54 38
0 1 249844 17752 18544 1223376 0 0 36224 4 1469 1035 10 6 67 17
1 1 249844 17856 18544 1208520 0 0 28724 0 950 941 33 12 49 7
1 0 249844 17748 18544 1222468 0 0 40968 8 1266 1164 17 9 59 16
1 0 249844 17912 18544 1222572 0 0 41344 12 1237 1080 13 8 65 13分析:
1,不會是內存不足導致,因爲swapping 始終沒變化(si 和 so).儘管空閒內存不多(free),但swpd 也沒有變化.
2,CPU 方面也沒有太大問題,儘管有一些運行隊列(procs r),但處理器還始終有50% 多的idle(CPU id).
3,有太多的上下文切換(cs)以及disk block從RAM中被讀入(bo).
4,CPU 還有平均20% 的I/O 等待情況.結論:
從以上總結出,這是一個I/O 瓶頸.2. 然後使用iostat 檢查是誰在發出IO 請求:
# iostat -x 1
Linux 2.4.21-40.ELsmp (mail.example.com) 03/26/2007avg-cpu: %user %nice %sys %idle
30.00 0.00 9.33 60.67Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 7929.01 30.34 1180.91 14.23 7929.01 357.84 3964.50 178.92 6.93 0.39 0.03 0.06 6.69
/dev/sda1 2.67 5.46 0.40 1.76 24.62 57.77 12.31 28.88 38.11 0.06 2.78 1.77 0.38
/dev/sda2 0.00 0.30 0.07 0.02 0.57 2.57 0.29 1.28 32.86 0.00 3.81 2.64 0.03
/dev/sda3 7929.01 24.58 1180.44 12.45 7929.01 297.50 3964.50 148.75 6.90 0.32 0.03 0.06 6.68avg-cpu: %user %nice %sys %idle
9.50 0.00 10.68 79.82Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1195.24 0.00 0.00 0.00 0.00 0.00 0.00 43.69 3.60 0.99 117.86avg-cpu: %user %nice %sys %idle
9.23 0.00 10.55 79.22Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/sda 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51
/dev/sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
/dev/sda3 0.00 0.00 1200.37 0.00 0.00 0.00 0.00 0.00 0.00 41.65 2.12 0.99 112.51分析:
1,看上去只有/dev/sda3 分區很活躍,其他分區都很空閒.
2,差不多有1200 讀IOPS,磁盤本身是支持200 IOPS左右(譯註:參考之前的IOPS 計算公式).
3,有超過2秒,實際上沒有一個讀磁盤(rkb/s).這和在vmstat 看到有大量I/O wait是有關係的.
4,大量的read IOPS(r/s)和在vmstat 中大量的上下文是匹配的.這說明很多讀操作都是失敗的.結論:
從以上總結出,部分應用程序帶來的讀請求,已經超出了I/O 子系統可處理的範圍.3. 使用top 來查找系統最活躍的應用程序
# top -d 1
11:46:11 up 3 days, 19:13, 1 user, load average: 1.72, 1.87, 1.80
176 processes: 174 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 12.8% 0.0% 4.6% 0.2% 0.2% 18.7% 63.2%
cpu00 23.3% 0.0% 7.7% 0.0% 0.0% 36.8% 32.0%
cpu01 28.4% 0.0% 10.7% 0.0% 0.0% 38.2% 22.5%
cpu02 0.0% 0.0% 0.0% 0.9% 0.9% 0.0% 98.0%
cpu03 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
Mem: 2055244k av, 2032692k used, 22552k free, 0k shrd, 18256k buff
1216212k actv, 513216k in_d, 25520k in_c
Swap: 4192956k av, 249844k used, 3943112k free 1218304k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14939 mysql 25 0 379M 224M 1117 R 38.2 25.7% 15:17.78 mysqld
4023 root 15 0 2120 972 784 R 2.0 0.3 0:00.06 top
1 root 15 0 2008 688 592 S 0.0 0.2 0:01.30 init
2 root 34 19 0 0 0 S 0.0 0.0 0:22.59 ksoftirqd/0
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
4 root 10 -5 0 0 0 S 0.0 0.0 0:00.05 events/0分析:
1,佔用資源最多的好像就是mysql 進程,其他都處於完全idle 狀態.
2,在top(wa) 看到的數值,和在vmstat 看到的wio 數值是有關聯的.結論:
從以上總結出,似乎就只有mysql 進程在請求資源,因此可以推論它就是導致問題的關鍵.4. 現在已經確定是mysql 在發出讀請求,使用strace 來檢查它在讀請求什麼.
# strace -p 14939
Process 14939 attached - interrupt to quit
read(29, “/3/1/237/1/366/337/1/222%/4/2/0/0/0/0/0012P/d”, 20) = 20
read(29, “ata1/strongmail/log/strongmail-d”…, 399) = 399
_llseek(29, 2877621036, [2877621036], SEEK_SET) = 0
read(29, “/1/1/241/366/337/1/223%/4/2/0/0/0/0/0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 400) = 400
_llseek(29, 2877621456, [2877621456], SEEK_SET) = 0
read(29, “/1/1/235/366/337/1/224%/4/2/0/0/0/0/0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 396) = 396
_llseek(29, 2877621872, [2877621872], SEEK_SET) = 0
read(29, “/1/1/245/366/337/1/225%/4/2/0/0/0/0/0012P/da”, 20) = 20
read(29, “ta1/strongmail/log/strongmail-de”…, 404) = 404
_llseek(29, 2877622296, [2877622296], SEEK_SET) = 0
read(29, “/3/1/236/2/366/337/1/226%/4/2/0/0/0/0/0012P/d”, 20) = 20分析:
1,大量的讀操作都在不斷尋道中,說明mysql 進程產生的是隨機IO.
2,看上去似乎是,某一sql 查詢導致讀操作.結論:
從以上總結出,所有的讀IOPS 都是mysql 進程在執行某些讀查詢時產生的.5. 使用mysqladmin 命令,來查找是哪個慢查詢導致的.
# ./mysqladmin -pstrongmail processlist
+—-+——+———–+————+———+——+———-+—————————————-
| Id | User | Host | db | Command | Time | State | Info
+—-+——+———–+————+———+——+———-+—————————————-
| 1 | root | localhost | strongmail | Sleep | 10 | |
| 2 | root | localhost | strongmail | Sleep | 8 | |
| 3 | root | localhost | root | Query | 94 | Updating | update `failures` set
`update_datasource`=’Y’ where database_id=’32′ and update_datasource=’N’ and |
| 14 | root | localhost | | Query | 0 | | show processlist分析:
1,MySQL 數據庫裏,似乎在不斷的運行table update查詢.
2,基於這個update 查詢,數據庫是對所有的table 進行索引.結論:
從以上總結出,MySQL裏這些update 查詢問題,都是在嘗試對所有table 進行索引.這些產生的讀請求正是導致系統性能下降的原因.後續
把以上這些性能信息移交給了相關開發人員,用於分析他們的PHP 代碼.一個開發人員對代碼進行了臨時性優化.某個查詢如果出錯了,也最多到100K記錄.數據庫本身考慮最多存在4百萬記錄.最後,這個查詢不會再給數據庫帶來負擔了.
References
• Ezlot, Phillip – Optimizing Linux Performance, Prentice Hall, Princeton NJ 2005 ISBN – 0131486829
• Johnson, Sandra K., Huizenga, Gerrit – Performance Tuning for Linux Servers, IBM Press, Upper Saddle River NJ 2005 ISBN 013144753X
• Bovet, Daniel Cesati, Marco – Understanding the Linux Kernel, O’Reilly Media, Sebastoppl CA 2006, ISBN 0596005652
• Blum, Richard – Network Performance Open Source Toolkit, Wiley, Indianapolis IN 2003, ISBN 0-471-43301-2
• Understanding Virtual Memory in RedHat 4, Neil Horman, 12/05 http://people.redhat.com/nhorman/papers/rhel4_vm.pdf
• IBM, Inside the Linux Scheduler, http://www.ibm.com/developerworks/linux/library/l-scheduler/
• Aas, Josh, Understanding the Linux 2.6.8.1 CPU Scheduler, http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
• Wieers, Dag, Dstat: Versatile Resource Statistics Tool, http://dag.wieers.com/home-made/dstat/
port 0 AF_INET