性能優化中CPU、內存、磁盤IO、網絡性能的依賴

【好書摘要】性能優化中CPU、內存、磁盤IO、網絡性能的依賴

系統優化是一項複雜、繁瑣、長期的工做，優化前須要監測、採集、測試、評估，優化後也須要測試、採集、評估、監測，並且是一個長期和持續的過程，不 是說如今優化了，測試了，之後就能夠一勞永逸了，也不是說書本上的優化就適合眼下正在運行的系統，不一樣的系統、不一樣的硬件、不一樣的應用優化的重點也不一樣、 優化的方法也不一樣、優化的參數也不一樣。性能監測是系統優化過程當中重要的一環，若是沒有監測、不清楚性能瓶頸在哪裏，怎麼優化呢?因此找到性能 瓶頸是性能監測的目的，也是系統優化的關鍵。系統由若干子系統構成，一般修改一個子系統有可能影響到另一個子系統，甚至會致使整個系統不穩定、崩潰。所 以說優化、監測、測試一般是連在一塊兒的，並且是一個循環並且長期的過程，一般監測的子系統有如下這些：
    CPU
    Memory
    IO
    Network
這些子系統互相依賴，瞭解這些子系統的特性，監測這些子系統的性能參數以及及時發現可能會出現的瓶頸對系統優化頗有幫助。
應用類型
不一樣的系統用途也不一樣，要找到性能瓶頸須要知道系統跑的是什麼應用、有些什麼特色，好比 web server 對系統的要求確定和 file server 不同，因此分清不一樣系統的應用類型很重要，一般應用能夠分爲兩種類型：
    IO 相關，IO 相關的應用一般用來處理大量數據，須要大量內存和存儲，頻繁 IO 操做讀寫數據，而對 CPU 的要求則較少，大部分時候 CPU 都在等待硬盤，好比，數據庫服務器、文件服務器等。

    CPU 相關，CPU 相關的應用須要使用大量 CPU，好比高併發的 web/mail 服務器、圖像/視頻處理、科學計算等均可被視做 CPU 相關的應用。

監測工具
咱們只須要簡單的工具就能夠對 Linux 的性能進行監測，如下是 VPSee 經常使用的工具：
工具    簡單介紹
top    查看進程活動狀態以及一些系統情況
vmstat    查看系統狀態、硬件和系統信息等
iostat    查看CPU 負載，硬盤情況
sar    綜合工具，查看系統情況
mpstat    查看多處理器情況
netstat    查看網絡情況
iptraf    實時網絡情況監測
tcpdump    抓取網絡數據包，詳細分析
tcptrace    數據包分析工具
netperf    網絡帶寬工具
dstat    綜合工具，綜合了 vmstat, iostat, ifstat, netstat 等多個信息
本系列將按照CPU、內存、磁盤IO、網絡這幾個方面分別介紹。

Linux性能監測：CPU篇

CPU 的佔用主要取決於什麼樣的資源正在 CPU 上面運行，好比拷貝一個文件一般佔用較少 CPU，由於大部分工做是由 DMA（Direct Memory Access）完成，只是在完成拷貝之後給一箇中斷讓 CPU 知道拷貝已經完成；科學計算一般佔用較多的 CPU，大部分計算工做都須要在 CPU 上完成，內存、硬盤等子系統只作暫時的數據存儲工做。要想監測和理解 CPU 的性能須要知道一些的操做系統的基本知識，好比：中斷、進程調度、進程上下文切換、可運行隊列等。這裏 VPSee 用個例子來簡單介紹一下這些概念和他們的關係，CPU 很無辜，是個不辭辛苦的打工仔，每時每刻都有工做在作（進程、線程）而且本身有一張工做清單（可運行隊列），由老闆（進程調度）來決定他該幹什麼，他須要 和老闆溝通以便獲得老闆的想法並及時調整本身的工做（上下文切換），部分工做作完之後還須要及時向老闆彙報（中斷），因此打工仔（CPU）除了作本身該作 的工做之外，還有大量時間和精力花在溝通和彙報上。
CPU 也是一種硬件資源，和任何其餘硬件設備同樣也須要驅動和管理程序才能使用，咱們能夠把內核的進程調度看做是 CPU 的管理程序，用來管理和分配 CPU 資源，合理安排進程搶佔 CPU，並決定哪一個進程該使用 CPU、哪一個進程該等待。操做系統內核裏的進程調度主要用來調度兩類資源：進程（或線程）和中斷，進程調度給不一樣的資源分配了不一樣的優先級，優先級最高的 是硬件中斷，其次是內核（系統）進程，最後是用戶進程。每一個 CPU 都維護着一個可運行隊列，用來存放那些可運行的線程。線程要麼在睡眠狀態（blocked 正在等待 IO）要麼在可運行狀態，若是 CPU 當前負載過高而新的請求不斷，就會出現進程調度暫時應付不過來的狀況，這個時候就不得不把線程暫時放到可運行隊列裏。VPSee 在這裏要討論的是性能監測，上面談了一堆都沒提到性能，那麼這些概念和性能監測有什麼關係呢？關係重大。若是你是老闆，你如何檢查打工仔的效率（性能） 呢？咱們通常會經過如下這些信息來判斷打工仔是否偷懶：
    打工仔接受和完成多少任務並向老闆彙報了（中斷）；
    打工仔和老闆溝通、協商每項工做的工做進度（上下文切換）；
    打工仔的工做列表是否是都有排滿（可運行隊列）；
    打工仔工做效率如何，是否是在偷懶（CPU 利用率）。
如今把打工仔換成 CPU，咱們能夠經過查看這些重要參數：中斷、上下文切換、可運行隊列、CPU 利用率來監測 CPU 的性能。
底線
Linux 性能監測：介紹提到了性能監測前須要知道底線，那麼監測 CPU 性能的底線是什麼呢？一般咱們指望咱們的系統能到達如下目標：
    CPU 利用率，若是 CPU 有 100％ 利用率，那麼應該到達這樣一個平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time；
    上下文切換，上下文切換應該和 CPU 利用率聯繫起來看，若是能保持上面的 CPU 利用率平衡，大量的上下文切換是能夠接受的；
    可運行隊列，每一個可運行隊列不該該有超過1－3個線程（每處理器），好比：雙處理器系統的可運行隊列裏不該該超過6個線程。
vmstat
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
 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個之內。
參數介紹：
    r，可運行隊列的線程數，這些線程都是可運行狀態，只不過 CPU 暫時不可用；
    b，被 blocked 的進程數，正在等待 IO 請求；
    in，被處理過的中斷數
    cs，系統上正在作上下文切換的數目
    us，用戶佔用 CPU 的百分比
    sys，內核和中斷佔用 CPU 的百分比
    wa，全部可運行的線程被 blocked 之後都在等待 IO，這時候 CPU 空閒的百分比
    id，CPU 徹底空閒的百分比

mpstat
mpstat 和 vmstat 相似，不一樣的是 mpstat 能夠輸出多個處理器的數據，下面的輸出顯示 CPU1 和 CPU2 基本上沒有派上用場，系統有足夠的能力處理更多的任務。
$ mpstat -P ALL 1
Linux 2.6.18-164.el5 (vpsee) 11/13/2009

02:24:33 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
02:24:34 PM  all    5.26    0.00    4.01   25.06    0.00    0.00    0.00   65.66   1446.00
02:24:34 PM    0    7.00    0.00    8.00    0.00    0.00    0.00    0.00   85.00   1001.00
02:24:34 PM    1   13.00    0.00    8.00    0.00    0.00    0.00    0.00   79.00    444.00
02:24:34 PM    2    0.00    0.00    0.00  100.00    0.00    0.00    0.00    0.00      0.00
02:24:34 PM    3    0.99    0.00    0.99    0.00    0.00    0.00    0.00   98.02      0.00
ps
如何查看某個程序、進程佔用了多少 CPU 資源呢？下面是 Firefox 在 VPSee 的一臺 Sunray 服務器上的運行狀況，當前只有2個用戶在使用 Firefox：
$ while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'firefox'; sleep 1; done
 PID  NI PRI %CPU PSR COMMAND
 7252   0  24  3.2   3 firefox
 9846   0  24  8.8   0 firefox
 7252   0  24  3.2   2 firefox
 9846   0  24  8.8   0 firefox
 7252   0  24  3.2   2 firefox

Linux性能監測：內存篇

這裏的講到的 「內存」 包括物理內存和虛擬內存，虛擬內存（Virtual Memory）把計算機的內存空間擴展到硬盤，物理內存（RAM）和硬盤的一部分空間（SWAP）組合在一塊兒做爲虛擬內存爲計算機提供了一個連貫的虛擬內 存空間，好處是咱們擁有的內存 」變多了「，能夠運行更多、更大的程序，壞處是把部分硬盤當內存用總體性能受到影響，硬盤讀寫速度要比內存慢幾個數量級，而且 RAM 和 SWAP 之間的交換增長了系統的負擔。
在操做系統裏，虛擬內存被分紅頁，在 x86 系統上每一個頁大小是 4KB。Linux 內核讀寫虛擬內存是以 「頁」 爲單位操做的，把內存轉移到硬盤交換空間（SWAP）和從交換空間讀取到內存的時候都是按頁來讀寫的。內存和 SWAP 的這種交換過程稱爲頁面交換（Paging），值得注意的是 paging 和 swapping 是兩個徹底不一樣的概念，國內不少參考書把這兩個概念混爲一談，swapping 也翻譯成交換，在操做系統裏是指把某程序徹底交換到硬盤以騰出內存給新程序使用，和 paging 只交換程序的部分（頁面）是兩個不一樣的概念。純粹的 swapping 在現代操做系統中已經很難看到了，由於把整個程序交換到硬盤的辦法既耗時又費力並且不必，現代操做系統基本都是 paging 或者 paging/swapping 混合，swapping 最初是在 Unix system V 上實現的。
虛擬內存管理是 Linux 內核裏面最複雜的部分，要弄懂這部份內容可能須要一整本書的講解。VPSee 在這裏只介紹和性能監測有關的兩個內核進程：kswapd 和 pdflush。
    kswapd daemon 用來檢查 pages_high 和 pages_low，若是可用內存少於 pages_low，kswapd 就開始掃描並試圖釋放 32個頁面，而且重複掃描釋放的過程直到可用內存大於 pages_high 爲止。掃描的時候檢查3件事：1）若是頁面沒有修改，把頁放到可用內存列表裏；2）若是頁面被文件系統修改，把頁面內容寫到磁盤上；3）若是頁面被修改 了，但不是被文件系統修改的，把頁面寫到交換空間。
    pdflush daemon 用來同步文件相關的內存頁面，把內存頁面及時同步到硬盤上。好比打開一個文件，文件被導入到內存裏，對文件作了修改後並保存後，內核並不立刻保存文件到硬 盤，由 pdflush 決定何時把相應頁面寫入硬盤，這由一個內核參數 vm.dirty_background_ratio 來控制，好比下面的參數顯示髒頁面（dirty pages）達到全部內存頁面10％的時候開始寫入硬盤。
# /sbin/sysctl -n vm.dirty_background_ratio
10
vmstat
繼續 vmstat 一些參數的介紹，上一篇 Linux 性能監測：CPU 介紹了 vmstat 的部分參數，這裏介紹另一部分。如下數據來自 VPSee 的一個 256MB RAM，512MB SWAP 的 Xen VPS：
# 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
    swpd，已使用的 SWAP 空間大小，KB 爲單位；
    free，可用的物理內存大小，KB 爲單位；
    buff，物理內存用來緩存讀寫操做的 buffer 大小，KB 爲單位；
    cache，物理內存用來緩存進程地址空間的 cache 大小，KB 爲單位；
    si，數據從 SWAP 讀取到 RAM（swap in）的大小，KB 爲單位；
    so，數據從 RAM 寫到 SWAP（swap out）的大小，KB 爲單位；
    bi，磁盤塊從文件系統或 SWAP 讀取到 RAM（blocks in）的大小，block 爲單位；
    bo，磁盤塊從 RAM 寫到文件系統或 SWAP（blocks out）的大小，block 爲單位；
上面是一個頻繁讀寫交換區的例子，能夠觀察到如下幾點：
    物理可用內存 free 基本沒什麼顯著變化，swapd 逐步增長，說明最小可用的內存始終保持在 256MB X 10％ = 2.56MB 左右，當髒頁達到10％的時候（vm.dirty_background_ratio ＝ 10）就開始大量使用 swap；
    buff 穩步減小說明系統知道內存不夠了，kwapd 正在從 buff 那裏借用部份內存；
    kswapd 持續把髒頁面寫到 swap 交換區（so），而且從 swapd 逐漸增長看出確實如此。根據上面講的 kswapd 掃描時檢查的三件事，若是頁面被修改了，但不是被文件系統修改的，把頁面寫到 swap，因此這裏 swapd 持續增長。
Linux性能監測：磁盤IO篇
磁盤一般是計算機最慢的子系統，也是最容易出現性能瓶頸的地方，由於磁盤離 CPU 距離最遠並且 CPU 訪問磁盤要涉及到機械操做，好比轉軸、尋軌等。訪問硬盤和訪問內存之間的速度差異是以數量級來計算的，就像1天和1分鐘的差異同樣。要監測 IO 性能，有必要了解一下基本原理和 Linux 是如何處理硬盤和內存之間的 IO 的。
內存頁
上一篇 Linux 性能監測：Memory 提到了內存和硬盤之間的 IO 是以頁爲單位來進行的，在 Linux 系統上1頁的大小爲 4K。能夠用如下命令查看系統默認的頁面大小：
$ /usr/bin/time -v date
...
Page size (bytes): 4096
...
缺頁中斷
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
...
File Buffer Cache
從上面的內存緩存區（也叫文件緩存區 File Buffer Cache）讀取頁比從硬盤讀取頁要快得多，因此 Linux 內核但願能儘量產生次缺頁中斷（從文件緩存區讀），而且能儘量避免主缺頁中斷（從硬盤讀），這樣隨着次缺頁中斷的增多，文件緩存區也逐步增大，直到系 統只有少許可用物理內存的時候 Linux 纔開始釋放一些不用的頁。咱們運行 Linux 一段時間後會發現雖然系統上運行的程序很少，可是可用內存老是不多，這樣給你們形成了 Linux 對內存管理很低效的假象，事實上 Linux 把那些暫時不用的物理內存高效的利用起來作預存（內存緩存區）呢。下面打印的是 VPSee 的一臺 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，並且這個緩存區還能夠不斷增加。
頁面類型
Linux 中內存頁面有三種類型：
    Read pages，只讀頁（或代碼頁），那些經過主缺頁中斷從硬盤讀取的頁面，包括不能修改的靜態文件、可執行文件、庫文件等。當內核須要它們的時候把它們讀到 內存中，當內存不足的時候，內核就釋放它們到空閒列表，當程序再次須要它們的時候須要經過缺頁中斷再次讀到內存。
    Dirty pages，髒頁，指那些在內存中被修改過的數據頁，好比文本文件等。這些文件由 pdflush 負責同步到硬盤，內存不足的時候由 kswapd 和 pdflush 把數據寫回硬盤並釋放內存。
    Anonymous pages，匿名頁，那些屬於某個進程可是又和任何文件無關聯，不能被同步到硬盤上，內存不足的時候由 kswapd 負責將它們寫到交換分區並釋放內存。
IO’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）。
順序 IO 和 隨機 IO
IO 可分爲順序 IO 和 隨機 IO 兩種，性能監測前須要弄清楚系統偏向順序 IO 的應用仍是隨機 IO 應用。順序 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
隨機 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）。
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
...

Linux性能監測：網絡篇
網絡的監測是全部 Linux 子系統裏面最複雜的，有太多的因素在裏面，好比：延遲、阻塞、衝突、丟包等，更糟的是與 Linux 主機相連的路由器、交換機、無線信號都會影響到總體網絡而且很難判斷是由於 Linux 網絡子系統的問題仍是別的設備的問題，增長了監測和判斷的複雜度。如今咱們使用的全部網卡都稱爲自適應網卡，意思是說能根據網絡上的不一樣網絡設備致使的不 同網絡速度和工做模式進行自動調整。咱們能夠經過 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
iptraf
兩臺主機之間有網線（或無線）、路由器、交換機等設備，測試兩臺主機之間的網絡性能的一個辦法就是在這兩個系統之間互發數據並統計結果，看看吞吐 量、延遲、速率如何。iptraf 就是一個很好的查看本機網絡吞吐量的好工具，支持文字圖形界面，很直觀。下面圖片顯示在 100 mbps 速率的網絡下這個 Linux 系統的發送傳輸率有點慢，Outgoing rates 只有 66 mbps.
# iptraf -d eth0
 
 
netperf
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、××× 等狀況。
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
iperf
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
tcpdump 和 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

http://www.cnblogs.com/Javame/p/3665565.html