公司有個測試服務器，上面跑了幾個應用和一個DB。 DB被這個幾個應用使用。 最近老是被掛掉。 CPU 使用率100%。 搞到最后大家都不能用。

敲個命令都沒反應。TOP命令顯示的是一些Oracle session占用CPU資源太多。杯具的是在服務器上連sqlplus都進不去了，命令都沒反應。只好把服務器重啟了。重啟之后再看了一下，是一個同事測試的SQL有問題。一條SQL占用CPU就30%。

在研究這個問題的時候，也google到了一些Linux下的監控事項，整理如下。

一.Linux性能監控的概述

系統由若干子系統構成，通常修改一個子系統有可能影響到另外一個子系統，甚至會導致整個系統不穩定、崩潰。所以說優化、監測、測試通常是連在一起的，而且是一個循環而且長期的過程，通常監測的子系統有以下這些：

(1).CPU

(2).Memory

(3).IO

(4).Network

這些子系統互相依賴，了解這些子系統的特性，監測這些子系統的性能參數以及及時發現可能會出現的瓶頸對系統優化很有幫助。

1.1應用類型

不同的系統用途也不同，要找到性能瓶頸需要知道系統跑的是什么應用、有些什么特點，比如web server對系統的要求肯定和file server不一樣，所以分清不同系統的應用類型很重要，通常應用可以分為兩種類型：

(1)IO相關，IO相關的應用通常用來處理大量數據，需要大量內存和存儲，頻繁IO操作讀寫數據，而對CPU的要求則較少，大部分時候CPU都在等待硬盤，比如，數據庫服務器、文件服務器等。

(2)CPU相關，CPU相關的應用需要使用大量CPU，比如高并發的web/mail服務器、圖像/視頻處理、科學計算等都可被視作CPU相關的應用。

看看實際中的例子，第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 st

0 4 140 1962724 335516 4852308 0 0 388 65024 1442 563 0 2 47 52 0

0 4 140 1961816 335516 4853868 0 0 768 65536 1434 522 0 1 50 48 0

0 4 140 1960788 335516 4855300 0 0 768 48640 1412 573 0 1 50 49 0

0 4 140 1958528 335516 4857280 0 0 1024 65536 1415 521 0 1 41 57 0

0 5 140 1957488 335516 4858884 0 0 768 81412 1504 609 0 2 50 49 0

第2個是CPU做大量計算時表現出來的特征：

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

4 0 140 3625096 334256 3266584 0 0 0 16 1054 470 100 0 0 0 0

4 0 140 3625220 334264 3266576 0 0 0 12 1037 448 100 0 0 0 0

4 0 140 3624468 334264 3266580 0 0 0 148 1160 632 100 0 0 0 0

4 0 140 3624468 334264 3266580 0 0 0 0 1078 527 100 0 0 0 0

4 0 140 3624712 334264 3266580 0 0 0 80 1053 501 100 0 0 0 0

上面兩個例子最明顯的差別就是id一欄，代表CPU的空閑率，拷貝文件時候id維持在50%左右，CPU大量計算的時候id基本為0。

1.2底線

事先建立一個底線，如果性能監測得到的統計數據跨過這條線，我們就可以說這個系統性能差，如果數據能保持在線內我們就說性能好。建立這樣底線需要知道一些理論、額外的負載測試和系統管理員多年的經驗。如果自己沒有多年的經驗，有一個簡單劃底線的辦法就是：把這個底線建立在自己對系統的期望上。自己期望這個系統有個什么樣的性能，這是一個底線，如果沒有達到這個要求就是性能差。

1.3監測工具

二. CPU

CPU的占用主要取決于什么樣的資源正在CPU上面運行，比如拷貝一個文件通常占用較少CPU，因為大部分工作是由DMA(Direct Memory Access)完成，只是在完成拷貝以后給一個中斷讓CPU知道拷貝已經完成;科學計算通常占用較多的CPU，大部分計算工作都需要在CPU上完成，內存、硬盤等子系統只做暫時的數據存儲工作。要想監測和理解CPU的性能需要知道一些的操作系統的基本知識，比如：中斷、進程調度、進程上下文切換、可運行隊列等。這里用個例子來簡單介紹一下這些概念和他們的關系，CPU每時每刻都有工作在做(進程、線程)并且自己有一張工作清單(可運行隊列)，由老板(進程調度)來決定他該干什么，他需要和老板溝通以便得到老板的想法并及時調整自己的工作(上下文切換)，部分工作做完以后還需要及時向老板匯報(中斷)，所以打工仔(CPU)除了做自己該做的工作以外，還有大量時間和精力花在溝通和匯報上。

CPU也是一種硬件資源，和任何其他硬件設備一樣也需要驅動和管理程序才能使用，我們可以把內核的進程調度看作是CPU的管理程序，用來管理和分配CPU資源，合理安排進程搶占CPU，并決定哪個進程該使用CPU、哪個進程該等待。操作系統內核里的進程調度主要用來調度兩類資源：進程(或線程)和中斷，進程調度給不同的資源分配了不同的優先級，優先級最高的是硬件中斷，其次是內核(系統)進程，最后是用戶進程。每個CPU都維護著一個可運行隊列，用來存放那些可運行的線程。線程要么在睡眠狀態(blocked正在等待IO)要么在可運行狀態，如果CPU當前負載太高而新的請求不斷，就會出現進程調度暫時應付不過來的情況，這個時候就不得不把線程暫時放到可運行隊列里。

可以從以下幾個方面監控CPU的信息：

(1)中斷;

(2)上下文切換;

(3)可運行隊列;

(4)CPU利用率。

2.1底線

通常我們期望我們的系統能到達以下目標：

(1)CPU利用率，如果CPU有100%利用率，那么應該到達這樣一個平衡：65%-70%User Time，30%-35%System Time，0%-5%Idle Time;

(2)上下文切換，上下文切換應該和CPU利用率聯系起來看，如果能保持上面的CPU利用率平衡，大量的上下文切換是可以接受的;

(3)可運行隊列，每個可運行隊列不應該有超過1-3個線程(每處理器)，比如：雙處理器系統的可運行隊列里不應該超過6個線程。

2.2vmstat

vmstat是個查看系統整體性能的小工具，小巧、即使在很heavy的情況下也運行良好，并且可以用時間間隔采集得到連續的性能數據。

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

2 1 140 2787980 336304 3531996 0 0 0 128 1166 5033 3 3 70 25 0

0 1 140 2788296 336304 3531996 0 0 0 0 1194 5605 3 3 69 25 0

0 1 140 2788436 336304 3531996 0 0 0 0 1249 8036 5 4 67 25 0

0 1 140 2782688 336304 3531996 0 0 0 0 1333 7792 6 6 64 25 0

3 1 140 2779292 336304 3531992 0 0 0 28 1323 7087 4 5 67 25 0

參數介紹：

(1).r，可運行隊列的線程數，這些線程都是可運行狀態，只不過CPU暫時不可用;

(2).b，被blocked的進程數，正在等待IO請求;

(3).in，被處理過的中斷數

(4).cs，系統上正在做上下文切換的數目

(5).us，用戶占用CPU的百分比

(6).sys，內核和中斷占用CPU的百分比

(7).wa，所有可運行的線程被blocked以后都在等待IO，這時候CPU空閑的百分比

(8).id，CPU完全空閑的百分比

舉兩個現實中的例子來實際分析一下：

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

4 0 140 2915476 341288 3951700 0 0 0 0 1057 523 19 81 0 0 0

4 0 140 2915724 341296 3951700 0 0 0 0 1048 546 19 81 0 0 0

4 0 140 2915848 341296 3951700 0 0 0 0 1044 514 18 82 0 0 0

4 0 140 2915848 341296 3951700 0 0 0 24 1044 564 20 80 0 0 0

4 0 140 2915848 341296 3951700 0 0 0 0 1060 546 18 82 0 0 0

從上面的數據可以看出幾點：

(1).interrupts(in)非常高，context switch(cs)比較低，說明這個CPU一直在不停的請求資源;

(2).user time(us)一直保持在80%以上，而且上下文切換較低(cs)，說明某個進程可能一直霸占著CPU;

(3).run queue(r)剛好在4個。

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

14 0 140 2904316 341912 3952308 0 0 0 460 1106 9593 36 64 1 0 0

17 0 140 2903492 341912 3951780 0 0 0 0 1037 9614 35 65 1 0 0

20 0 140 2902016 341912 3952000 0 0 0 0 1046 9739 35 64 1 0 0

17 0 140 2903904 341912 3951888 0 0 0 76 1044 9879 37 63 0 0 0

16 0 140 2904580 341912 3952108 0 0 0 0 1055 9808 34 65 1 0 0

從上面的數據可以看出幾點：

(1).context switch(cs)比interrupts(in)要高得多，說明內核不得不來回切換進程;

(2).進一步觀察發現system time(sy)很高而user time(us)很低，而且加上高頻度的上下文切換(cs)，說明正在運行的應用程序調用了大量的系統調用(system call);

(3).run queue(r)在14個線程以上，按照這個測試機器的硬件配置(四核)，應該保持在12個以內。

我上午CPU 100%時的信息：

top - 11:49:08 up 50 days, 22:25,6 users,load average: 59.79, 59.98, 60.50

Tasks: 200 total,61 running, 139 sleeping,0 stopped,0 zombie

Cpu0: 26.5%us, 73.5%sy,0.0%ni,0.0%id,0.0%wa,0.0%hi,0.0%si,0.0%st

Cpu1: 25.0%us, 75.0%sy,0.0%ni,0.0%id,0.0%wa,0.0%hi,0.0%si,0.0%st

Mem:1939780k total,1744412k used,195368k free,95704k buffers

Swap:4401800k total,662836k used,3738964k free,811124k cached

[root@localhost ~]# vmstat 2 10

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

rbswpdfreebuffcachesisobiboincs us sy id wa st

581 662836 19598895428 81074000410641 234 7210

591 662836 19598895448 810732000128235221 28 72000

591 662836 19598895448 8107680000216209 28 72000

2.3mpstat

mpstat和vmstat類似，不同的是mpstat可以輸出多個處理器的數據。

注意：需要安裝sysstat包后才有這個命令，可以使用yum安裝：

#yum install sysstat

sysstat包含iostat、mpstat、sar、命令。

[root@localhost gmail]# export LANG=en_US

[root@localhost gmail]# mpstat -P ALL

Linux 2.6.18-8.el5xen (localhost.localdomain) 02/21/2011

10:20:16 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s

10:20:16 PM all 11.49 0.00 2.58 1.04 0.01 0.13 0.01 84.74 314.61

10:20:16 PM 0 15.73 0.00 2.56 0.55 0.02 0.23 0.01 80.89 241.09

10:20:16 PM 1 7.25 0.00 2.60 1.53 0.00 0.02 0.01 88.59 73.52

[root@localhost gmail]# mpstat -P ALL 1

Linux 2.6.18-8.el5xen (localhost.localdomain) 02/21/2011

10:20:18 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s

10:20:19 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 136.63

10:20:19 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 86.14

10:20:19 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 50.50

10:20:19 PM CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s

10:20:20 PM all 0.00 0.00 0.00 0.47 0.00 0.00 0.00 99.53 105.00

10:20:20 PM 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 79.00

10:20:20 PM 1 0.00 0.00 0.00 0.90 0.00 0.00 0.00 99.10 26.00

2.4ps

查看某個程序、進程占用了多少CPU資源:

[root@localhost gmail]# while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'oracle'; sleep 1; done

PID NI PRI %CPU PSR COMMAND

3668 0 24 0.0 0 oracle

3670 0 21 0.0 0 oracle

3672 0 24 0.0 0 oracle

3674 0 23 0.0 0 oracle

3676 0 24 0.0 1 oracle

3678 0 23 0.0 0 oracle

3680 0 21 0.0 1 oracle

3682 0 24 0.0 1 oracle

3684 0 24 0.0 0 oracle

3686 0 21 0.0 0 oracle

三. Memory

這里的講到的“內存”包括物理內存和虛擬內存，虛擬內存(Virtual Memory)把計算機的內存空間擴展到硬盤，物理內存(RAM)和硬盤的一部分空間(SWAP)組合在一起作為虛擬內存為計算機提供了一個連貫的虛擬內存空間，好處是我們擁有的內存”變多了“，可以運行更多、更大的程序，壞處是把部分硬盤當內存用整體性能受到影響，硬盤讀寫速度要比內存慢幾個數量級，并且RAM和SWAP之間的交換增加了系統的負擔。

在操作系統里，虛擬內存被分成頁，在x86系統上每個頁大小是4KB。Linux內核讀寫虛擬內存是以“頁”為單位操作的，把內存轉移到硬盤交換空間(SWAP)和從交換空間讀取到內存的時候都是按頁來讀寫的。內存和SWAP的這種交換過程稱為頁面交換(Paging)，值得注意的是paging和swapping是兩個完全不同的概念，國內很多參考書把這兩個概念混為一談，swapping也翻譯成交換，在操作系統里是指把某程序完全交換到硬盤以騰出內存給新程序使用，和paging只交換程序的部分(頁面)是兩個不同的概念。純粹的swapping在現代操作系統中已經很難看到了，因為把整個程序交換到硬盤的辦法既耗時又費力而且沒必要，現代操作系統基本都是paging或者paging/swapping混合，swapping最初是在Unix system V上實現的。

在這里只介紹和性能監測有關的兩個內核進程：kswapd和pdflush。

(1)kswapd daemon用來檢查pages_high和pages_low，如果可用內存少于pages_low，kswapd就開始掃描并試圖釋放32個頁面，并且重復掃描釋放的過程直到可用內存大于pages_high為止。

掃描的時候檢查3件事：

1)如果頁面沒有修改，把頁放到可用內存列表里;

2)如果頁面被文件系統修改，把頁面內容寫到磁盤上;

3)如果頁面被修改了，但不是被文件系統修改的，把頁面寫到交換空間。

(2)pdflush daemon用來同步文件相關的內存頁面，把內存頁面及時同步到硬盤上。比如打開一個文件，文件被導入到內存里，對文件做了修改后并保存后，內核并不馬上保存文件到硬盤，由pdflush決定什么時候把相應頁面寫入硬盤，這由一個內核參數vm.dirty_background_ratio來控制，比如下面的參數顯示臟頁面(dirty pages)達到所有內存頁面10%的時候開始寫入硬盤。

# /sbin/sysctl -n vm.dirty_background_ratio

10

3.1vmstat

# vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

0 3 252696 2432 268 7148 3604 2368 3608 2372 288 288 0 0 21 78 1

0 2 253484 2216 228 7104 5368 2976 5372 3036 930 519 0 0 0 100 0

0 1 259252 2616 128 6148 19784 18712 19784 18712 3821 1853 0 1 3 95 1

1 2 260008 2188 144 6824 11824 2584 12664 2584 1347 1174 14 0 0 86 0

2 1 262140 2964 128 5852 24912 17304 24952 17304 4737 2341 86 10 0 0 4

部分參數說明：

(1).swpd，已使用的SWAP空間大小，KB為單位;

(2).free，可用的物理內存大小，KB為單位;

(3).buff，物理內存用來緩存讀寫操作的buffer大小，KB為單位;

(4).cache，物理內存用來緩存進程地址空間的cache大小，KB為單位;

(5).si，數據從SWAP讀取到RAM(swap in)的大小，KB為單位;

(6).so，數據從RAM寫到SWAP(swap out)的大小，KB為單位;

(7).bi，磁盤塊從文件系統或SWAP讀取到RAM(blocks in)的大小，block為單位;

(8).bo，磁盤塊從RAM寫到文件系統或SWAP(blocks out)的大小，block為單位;

上面是一個頻繁讀寫交換區的例子，可以觀察到以下幾點：

(1).物理可用內存free基本沒什么顯著變化，swapd逐步增加，說明最小可用的內存始終保持在256MB(物理內存大小) * 10%= 2.56MB左右，當臟頁達到10%的時候(vm.dirty_background_ratio=10)就開始大量使用swap;

(2).buff穩步減少說明系統知道內存不夠了，kwapd正在從buff那里借用部分內存;

(3).kswapd持續把臟頁面寫到swap交換區(so)，并且從swapd逐漸增加看出確實如此。根據上面講的kswapd掃描時檢查的三件事，如果頁面被修改了，但不是被文件系統修改的，把頁面寫到swap，所以這里swapd持續增加。

四. IO

磁盤通常是計算機最慢的子系統，也是最容易出現性能瓶頸的地方，因為磁盤離CPU距離最遠而且CPU訪問磁盤要涉及到機械操作，比如轉軸、尋軌等。訪問硬盤和訪問內存之間的速度差別是以數量級來計算的，就像1天和1分鐘的差別一樣。要監測IO性能，有必要了解一下基本原理和Linux是如何處理硬盤和內存之間的IO的。

4.1內存頁

在第三節Memory中提到了內存和硬盤之間的IO是以頁為單位來進行的，在Linux系統上1頁的大小為4K?？梢杂靡韵旅畈榭聪到y默認的頁面大?。?/p>

$ /usr/bin/time -v date

...

Page size (bytes): 4096

...

4.2缺頁中斷

Linux利用虛擬內存極大的擴展了程序地址空間，使得原來物理內存不能容下的程序也可以通過內存和硬盤之間的不斷交換(把暫時不用的內存頁交換到硬盤，把需要的內存頁從硬盤讀到內存)來贏得更多的內存，看起來就像物理內存被擴大了一樣。事實上這個過程對程序是完全透明的，程序完全不用理會自己哪一部分、什么時候被交換進內存，一切都有內核的虛擬內存管理來完成。當程序啟動的時候，Linux內核首先檢查CPU的緩存和物理內存，如果數據已經在內存里就忽略，如果數據不在內存里就引起一個缺頁中斷(Page Fault)，然后從硬盤讀取缺頁，并把缺頁緩存到物理內存里。缺頁中斷可分為主缺頁中斷(Major Page Fault)和次缺頁中斷(Minor Page Fault)，要從磁盤讀取數據而產生的中斷是主缺頁中斷;數據已經被讀入內存并被緩存起來，從內存緩存區中而不是直接從硬盤中讀取數據而產生的中斷是次缺頁中斷。

上面的內存緩存區起到了預讀硬盤的作用，內核先在物理內存里尋找缺頁，沒有的話產生次缺頁中斷從內存緩存里找，如果還沒有發現的話就從硬盤讀取。很顯然，把多余的內存拿出來做成內存緩存區提高了訪問速度，這里還有一個命中率的問題，運氣好的話如果每次缺頁都能從內存緩存區讀取的話將會極大提高性能。要提高命中率的一個簡單方法就是增大內存緩存區面積，緩存區越大預存的頁面就越多，命中率也會越高。

下面的time命令可以用來查看某程序第一次啟動的時候產生了多少主缺頁中斷和次缺頁中斷：

$ /usr/bin/time -v date

...

Major (requiring I/O) page faults: 1

Minor (reclaiming a frame) page faults: 260

...

4.3File Buffer Cache

從上面的內存緩存區(也叫文件緩存區File Buffer Cache)讀取頁比從硬盤讀取頁要快得多，所以Linux內核希望能盡可能產生次缺頁中斷(從文件緩存區讀)，并且能盡可能避免主缺頁中斷(從硬盤讀)，這樣隨著次缺頁中斷的增多，文件緩存區也逐步增大，直到系統只有少量可用物理內存的時候Linux才開始釋放一些不用的頁。我們運行Linux一段時間后會發現雖然系統上運行的程序不多，但是可用內存總是很少，這樣給大家造成了Linux對內存管理很低效的假象，事實上Linux把那些暫時不用的物理內存高效的利用起來做預存(內存緩存區)呢。下面是一臺Sun服務器上的物理內存和文件緩存區的情況：

$ cat /proc/meminfo

MemTotal: 8182776 kB

MemFree: 3053808 kB

Buffers: 342704 kB

Cached: 3972748 kB

這臺服務器總共有8GB物理內存(MemTotal)，3GB左右可用內存(MemFree)，343MB左右用來做磁盤緩存(Buffers)，4GB左右用來做文件緩存區(Cached)，可見Linux真的用了很多物理內存做Cache，而且這個緩存區還可以不斷增長。

4.4頁面類型

Linux中內存頁面有三種類型：

(1).Read pages，只讀頁(或代碼頁)，那些通過主缺頁中斷從硬盤讀取的頁面，包括不能修改的靜態文件、可執行文件、庫文件等。當內核需要它們的時候把它們讀到內存中，當內存不足的時候，內核就釋放它們到空閑列表，當程序再次需要它們的時候需要通過缺頁中斷再次讀到內存。

(2).Dirty pages，臟頁，指那些在內存中被修改過的數據頁，比如文本文件等。這些文件由pdflush負責同步到硬盤，內存不足的時候由kswapd和pdflush把數據寫回硬盤并釋放內存。

(3).Anonymous pages，匿名頁，那些屬于某個進程但是又和任何文件無關聯，不能被同步到硬盤上，內存不足的時候由kswapd負責將它們寫到交換分區并釋放內存。

4.5IO’s Per Second(IOPS)

每次磁盤IO請求都需要一定的時間，和訪問內存比起來這個等待時間簡直難以忍受。在一臺2001年的典型1GHz PC上，磁盤隨機訪問一個word需要8,000,000 nanosec = 8 millisec，順序訪問一個word需要200 nanosec;而從內存訪問一個word只需要10 nanosec.(數據來自：Teach Yourself Programming in Ten Years)這個硬盤可以提供125次IOPS(1000 ms / 8 ms)。

4.6順序IO和隨機IO

IO可分為順序IO和隨機IO兩種，性能監測前需要弄清楚系統偏向順序IO的應用還是隨機IO應用。

(1)順序IO是指同時順序請求大量數據，比如數據庫執行大量的查詢、流媒體服務等，順序IO可以同時很快的移動大量數據?？梢赃@樣來評估IOPS的性能，用每秒讀寫IO字節數除以每秒讀寫IOPS數，rkB/s除以r/s，wkB/s除以w/s.下面顯示的是連續2秒的IO情況，可見每次IO寫的數據是增加的(45060.00 / 99.00 = 455.15 KB per IO，54272.00 / 112.00 = 484.57 KB per IO)。

相對隨機IO而言，順序IO更應該重視每次IO的吞吐能力(KB per IO)：

$ iostat -kx 1

avg-cpu: %user %nice %system %iowait %steal %idle

0.00 0.00 2.50 25.25 0.00 72.25

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sdb 24.00 19995.00 29.00 99.00 4228.00 45060.00 770.12 45.01 539.65 7.80 99.80

avg-cpu: %user %nice %system %iowait %steal %idle

0.00 0.00 1.00 30.67 0.00 68.33

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sdb 3.00 12235.00 3.00 112.00 768.00 54272.00 957.22 144.85 576.44 8.70 100.10

(2)隨機IO是指隨機請求數據，其IO速度不依賴于數據的大小和排列，依賴于磁盤的每秒能IO的次數，比如Web服務、Mail服務等每次請求的數據都很小，隨機IO每秒同時會有更多的請求數產生，所以磁盤的每秒能IO多少次是關鍵。

$ iostat -kx 1

avg-cpu: %user %nice %system %iowait %steal %idle

1.75 0.00 0.75 0.25 0.00 97.26

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sdb 0.00 52.00 0.00 57.00 0.00 436.00 15.30 0.03 0.54 0.23 1.30

avg-cpu: %user %nice %system %iowait %steal %idle

1.75 0.00 0.75 0.25 0.00 97.24

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sdb 0.00 56.44 0.00 66.34 0.00 491.09 14.81 0.04 0.54 0.19 1.29

按照上面的公式得出：436.00 / 57.00 = 7.65 KB per IO，491.09 / 66.34 = 7.40 KB per IO.與順序IO比較發現，隨機IO的KB per IO小到可以忽略不計，可見對于隨機IO而言重要的是每秒能IOPS的次數，而不是每次IO的吞吐能力(KB per IO)。

4.7 SWAP

當系統沒有足夠物理內存來應付所有請求的時候就會用到swap設備，swap設備可以是一個文件，也可以是一個磁盤分區。不過要小心的是，使用swap的代價非常大。如果系統沒有物理內存可用，就會頻繁swapping，如果swap設備和程序正要訪問的數據在同一個文件系統上，那會碰到嚴重的IO問題，最終導致整個系統遲緩，甚至崩潰。swap設備和內存之間的swapping狀況是判斷Linux系統性能的重要參考，我們已經有很多工具可以用來監測swap和swapping情況，比如：top、cat /proc/meminfo、vmstat等：

$ cat /proc/meminfo

MemTotal: 8182776 kB

MemFree: 2125476 kB

Buffers: 347952 kB

Cached: 4892024 kB

SwapCached: 112 kB

...

SwapTotal: 4096564 kB

SwapFree: 4096424 kB

...

$ vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

r b swpd free buff cache si so bi bo in cs us sy id wa st

1 2 260008 2188 144 6824 11824 2584 12664 2584 1347 1174 14 0 0 86 0

2 1 262140 2964 128 5852 24912 17304 24952 17304 4737 2341 86 10 0 0

五. network

網絡的監測是所有Linux子系統里面最復雜的，有太多的因素在里面，比如：延遲、阻塞、沖突、丟包等，更糟的是與Linux主機相連的路由器、交換機、無線信號都會影響到整體網絡并且很難判斷是因為Linux網絡子系統的問題還是別的設備的問題，增加了監測和判斷的復雜度?，F在我們使用的所有網卡都稱為自適應網卡，意思是說能根據網絡上的不同網絡設備導致的不同網絡速度和工作模式進行自動調整。我們可以通過ethtool工具來查看網卡的配置和工作模式：

# /sbin/ethtool eth0

Settings for eth0:

Supported ports: [ TP ]

Supported link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Half 1000baseT/Full

Supports auto-negotiation: Yes

Advertised link modes: 10baseT/Half 10baseT/Full

100baseT/Half 100baseT/Full

1000baseT/Half 1000baseT/Full

Advertised auto-negotiation: Yes

Speed: 100Mb/s

Duplex: Full

Port: Twisted Pair

PHYAD: 1

Transceiver: internal

Auto-negotiation: on

Supports Wake-on: g

Wake-on: g

Current message level: 0x000000ff (255)

Link detected: yes

上面給出的例子說明網卡有10baseT，100baseT和1000baseT三種選擇，目前正自適應為100baseT(Speed: 100Mb/s)。可以通過ethtool工具強制網卡工作在1000baseT下：

# /sbin/ethtool -s eth0 speed 1000 duplex full autoneg off

5.1iptraf

兩臺主機之間有網線(或無線)、路由器、交換機等設備，測試兩臺主機之間的網絡性能的一個辦法就是在這兩個系統之間互發數據并統計結果，看看吞吐量、延遲、速率如何。iptraf就是一個很好的查看本機網絡吞吐量的好工具，支持文字圖形界面，很直觀。下面圖片顯示在100 mbps速率的網絡下這個Linux系統的發送傳輸率有點慢，Outgoing rates只有66 mbps.

# iptraf -d eth0

5.2netperf

netperf運行在client/server模式下，比iptraf能更多樣化的測試終端的吞吐量。先在服務器端啟動netserver：

# netserver

Starting netserver at port 12865

Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC

然后在客戶端測試服務器，執行一次持續10秒的TCP測試：

# netperf -H 172.16.38.36 -l 10

TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) 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 10.32 93.68

從以上輸出可以看出，網絡吞吐量在94mbps左右，對于100mbps的網絡來說這個性能算的上很不錯。上面的測試是在服務器和客戶端位于同一個局域網，并且局域網是有線網的情況，你也可以試試不同結構、不同速率的網絡，比如：網絡之間中間多幾個路由器、客戶端在wi-fi、VPN等情況。

netperf還可以通過建立一個TCP連接并順序地發送數據包來測試每秒有多少TCP請求和響應。下面的輸出顯示在TCP requests使用2K大小，responses使用32K的情況下處理速率為每秒243：

# netperf -t TCP_RR -H 172.16.38.36 -l 10 -- -r 2048,32768

TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 172.16.38.36 (172.16.38.36) port 0 AF_INET

Local /Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

bytes Bytes bytes bytes secs. per sec

16384 87380 2048 32768 10.00 243.03

16384 87380

5.3iperf

iperf和netperf運行方式類似，也是server/client模式，先在服務器端啟動iperf：

# iperf -s -D

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

Running Iperf Server as a daemon

The Iperf daemon process ID : 5695

然后在客戶端對服務器進行測試，客戶端先連接到服務器端(172.16.38.36)，并在30秒內每隔5秒對服務器和客戶端之間的網絡進行一次帶寬測試和采樣：

# iperf -c 172.16.38.36 -t 30 -i 5

------------------------------------------------------------

Client connecting to 172.16.38.36, TCP port 5001

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 3] local 172.16.39.100 port 49515 connected with 172.16.38.36 port 5001

[ ID] Interval Transfer Bandwidth

[ 3] 0.0- 5.0 sec 58.8 MBytes 98.6 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 5.0-10.0 sec 55.0 MBytes 92.3 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 10.0-15.0 sec 55.1 MBytes 92.4 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 15.0-20.0 sec 55.9 MBytes 93.8 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 20.0-25.0 sec 55.4 MBytes 92.9 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 25.0-30.0 sec 55.3 MBytes 92.8 Mbits/sec

[ ID] Interval Transfer Bandwidth

[ 3] 0.0-30.0 sec 335 MBytes 93.7 Mbits/sec

5.4tcpdump和tcptrace

tcmdump和tcptrace提供了一種更細致的分析方法，先用tcpdump按要求捕獲數據包把結果輸出到某一文件，然后再用tcptrace分析其文件格式。這個工具組合可以提供一些難以用其他工具發現的信息：

# /usr/sbin/tcpdump -w network.dmp

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

511942 packets captured

511942 packets received by filter

0 packets dropped by kernel

# tcptrace network.dmp

1 arg remaining, starting with 'network.dmp'

Ostermann's tcptrace -- version 6.6.7 -- Thu Nov 4, 2004

511677 packets seen, 511487 TCP packets traced

elapsed wallclock time: 0:00:00.510291, 1002714 pkts/sec analyzed

trace file elapsed time: 0:02:35.836372

TCP connection info:

1: zaber:54581 - boulder:111 (a2b) 6> 5< (complete)

2: zaber:833 - boulder:32774 (c2d) 6> 5< (complete)

3: zaber:pcanywherestat - 172.16.39.5:53086 (e2f) 2> 3<

4: zaber:716 - boulder:2049 (g2h) 347> 257<

5: 172.16.39.100:58029 - zaber:12865 (i2j) 7> 5< (complete)

6: 172.16.39.100:47592 - zaber:36814 (k2l) 255380> 255378< (reset)

7: breakpoint:45510 - zaber:7012 (m2n) 9> 5< (complete)

8: zaber:35813 - boulder:111 (o2p) 6> 5< (complete)

9: zaber:837 - boulder:32774 (q2r) 6> 5< (complete)

10: breakpoint:45511 - zaber:7012 (s2t) 9> 5< (complete)

11: zaber:59362 - boulder:111 (u2v) 6> 5< (complete)

12: zaber:841 - boulder:32774 (w2x) 6> 5< (complete)

13: breakpoint:45512 - zaber:7012 (y2z) 9> 5< (complete)

tcptrace功能很強大，還可以通過過濾和布爾表達式來找出有問題的連接，比如，找出轉播大于100 segments的連接：

# tcptrace -f'rexmit_segs>100' network.dmp

如果發現連接#10有問題，可以查看關于這個連接的其他信息：

# tcptrace -o10 network.dmp

下面的命令使用tcptrace的slice模式，程序自動在當前目錄創建了一個slice.dat文件，這個文件包含了每隔15秒的轉播信息:

# tcptrace -xslice network.dmp

# cat slice.dat

date segs bytes rexsegs rexbytes new active

--------------- -------- -------- -------- -------- -------- --------

16:58:50.244708 85055 4513418 0 0 6 6

16:59:05.244708 110921 5882896 0 0 0 2

16:59:20.244708 126107 6697827 0 0 1 3

16:59:35.244708 151719 8043597 0 0 0 2

16:59:50.244708 37296 1980557 0 0 0 3

17:00:05.244708 67 8828 0 0 2 3

17:00:20.244708 149 22053 0 0 1 2

17:00:35.244708 30 4080 0 0 0 1

17:00:50.244708 39 5688 0 0 0 1

17:01:05.244708 67 8828 0 0 2 3

17:01:11.081080 37 4121 0 0 1 3