Linux按照CPU、內存、磁盤IO、網絡性能監測

Linux按照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 的情況下也運行良好，並且可以用時間間隔采集得到連續的性能數據。   舉兩個現實中的例子來實際分析一下：   1 $ vmstat 1 2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ 3  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 4  4  0    140 2915476 341288 3951700  0    0     0     0 1057  523 19 81  0  0  0 5  4  0    140 2915724 341296 3951700  0    0     0     0 1048  546 19 81  0  0  0 6  4  0    140 2915848 341296 3951700  0    0     0     0 1044  514 18 82  0  0  0 7  4  0    140 2915848 341296 3951700  0    0     0    24 1044  564 20 80  0  0  0 8  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個。  1 $ vmstat 1 2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ 3  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 4 14  0    140 2904316 341912 3952308  0    0     0   460 1106 9593 36 64  1  0  0 5 17  0    140 2903492 341912 3951780  0    0     0     0 1037 9614 35 65  1  0  0 6 20  0    140 2902016 341912 3952000  0    0     0     0 1046 9739 35 64  1  0  0 7 17  0    140 2903904 341912 3951888  0    0     0    76 1044 9879 37 63  0  0  0 8 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 基本上沒有派上用場，系統有足夠的能力處理更多的任務。   1 $ mpstat -P ALL 1 2 Linux 2.6.18-164.el5 (vpsee) 11/13/2009 3   4 02:24:33 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s 5 02:24:34 PM  all    5.26    0.00    4.01   25.06    0.00    0.00    0.00   65.66   1446.00 6 02:24:34 PM    0    7.00    0.00    8.00    0.00    0.00    0.00    0.00   85.00   1001.00 7 02:24:34 PM    1   13.00    0.00    8.00    0.00    0.00    0.00    0.00   79.00    444.00 8 02:24:34 PM    2    0.00    0.00    0.00  100.00    0.00    0.00    0.00    0.00      0.00 9 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： 1 $ while :; do ps -eo pid,ni,pri,pcpu,psr,comm | grep 'firefox'; sleep 1; done 2  PID  NI PRI %CPU PSR COMMAND 3  7252   0  24  3.2   3 firefox 4  9846   0  24  8.8   0 firefox 5  7252   0  24  3.2   2 firefox 6  9846   0  24  8.8   0 firefox 7  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％的時候開始寫入硬盤。 1 # /sbin/sysctl -n vm.dirty_background_ratio 2 10 vmstat  繼續 vmstat 一些參數的介紹，上一篇 Linux 性能監測：CPU 介紹了 vmstat 的部分參數，這裡介紹另外一部分。以下數據來自 VPSee 的一個 256MB RAM，512MB SWAP 的 Xen VPS：  1 # vmstat 1 2 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ 3  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 4  0  3 252696   2432    268   7148 3604 2368  3608  2372  288  288  0  0 21 78  1 5  0  2 253484   2216    228   7104 5368 2976  5372  3036  930  519  0  0  0 100  0 6  0  1 259252   2616    128   6148 19784 18712 19784 18712 3821 1853  0  1  3 95  1 7  1  2 260008   2188    144   6824 11824 2584 12664  2584 1347 1174 14  0  0 86  0 8  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。可以用以下命令查看系統默認的頁面大小：  1 $ /usr/bin/time -v date 2 ... 3 Page size (bytes): 4096 4 ... 缺頁中斷       Linux 利用虛擬內存極大的擴展了程序地址空間，使得原來物理內存不能容下的程序也可以通過內存和硬盤之間的不斷交換（把暫時不用的內存頁交換到硬盤，把需要的內 存頁從硬盤讀到內存）來贏得更多的內存，看起來就像物理內存被擴大了一樣。事實上這個過程對程序是完全透明的，程序完全不用理會自己哪一部分、什麼時候被 交換進內存，一切都有內核的虛擬內存管理來完成。當程序啟動的時候，Linux 內核首先檢查 CPU 的緩存和物理內存，如果數據已經在內存裡就忽略，如果數據不在內存裡就引起一個缺頁中斷（Page Fault），然後從硬盤讀取缺頁，並把缺頁緩存到物理內存裡。缺頁中斷可分為主缺頁中斷（Major Page Fault）和次缺頁中斷（Minor Page Fault），要從磁盤讀取數據而產生的中斷是主缺頁中斷；數據已經被讀入內存並被緩存起來，從內存緩存區中而不是直接從硬盤中讀取數據而產生的中斷是次 缺頁中斷。       上面的內存緩存區起到了預讀硬盤的作用，內核先在物理內存裡尋找缺頁，沒有的話產生次缺頁中斷從內存緩存裡找，如果還沒有發現的話就從硬盤讀取。很 顯然，把多余的內存拿出來做成內存緩存區提高了訪問速度，這裡還有一個命中率的問題，運氣好的話如果每次缺頁都能從內存緩存區讀取的話將會極大提高性能。 要提高命中率的一個簡單方法就是增大內存緩存區面積，緩存區越大預存的頁面就越多，命中率也會越高。下面的 time 命令可以用來查看某程序第一次啟動的時候產生了多少主缺頁中斷和次缺頁中斷：  1 $ /usr/bin/time -v date 2 ... 3 Major (requiring I/O) page faults: 1 4 Minor (reclaiming a frame) page faults: 260 5 ... File Buffer Cache       從上面的內存緩存區（也叫文件緩存區 File Buffer Cache）讀取頁比從硬盤讀取頁要快得多，所以 Linux 內核希望能盡可能產生次缺頁中斷（從文件緩存區讀），並且能盡可能避免主缺頁中斷（從硬盤讀），這樣隨著次缺頁中斷的增多，文件緩存區也逐步增大，直到系 統只有少量可用物理內存的時候 Linux 才開始釋放一些不用的頁。我們運行 Linux 一段時間後會發現雖然系統上運行的程序不多，但是可用內存總是很少，這樣給大家造成了 Linux 對內存管理很低效的假象，事實上 Linux 把那些暫時不用的物理內存高效的利用起來做預存（內存緩存區）呢。下面打印的是 VPSee 的一台 Sun 服務器上的物理內存和文件緩存區的情況：  1 $ cat /proc/meminfo 2 MemTotal:      8182776 kB 3 MemFree:       3053808 kB 4 Buffers:        342704 kB 5 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）：  01 $ iostat -kx 1 02 avg-cpu:  %user   %nice %system %iowait  %steal   %idle 03            0.00    0.00    2.50   25.25    0.00   72.25 04   05 Device:  rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util 06 sdb       24.00 19995.00 29.00 99.00  4228.00 45060.00   770.12    45.01  539.65   7.80  99.80 07   08 avg-cpu:  %user   %nice %system %iowait  %steal   %idle 09            0.00    0.00    1.00   30.67    0.00   68.33 10   11 Device:  rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util 12 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 多少次是關鍵。  01 $ iostat -kx 1 02 avg-cpu:  %user   %nice %system %iowait  %steal   %idle 03            1.75    0.00    0.75    0.25    0.00   97.26 04   05 Device:  rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util 06 sdb        0.00    52.00  0.00 57.00     0.00   436.00    15.30     0.03    0.54   0.23   1.30 07   08 avg-cpu:  %user   %nice %system %iowait  %steal   %idle 09            1.75    0.00    0.75    0.25    0.00   97.24 10   11 Device:  rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util 12 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 等：  01 $ cat /proc/meminfo 02 MemTotal:      8182776 kB 03 MemFree:       2125476 kB 04 Buffers:        347952 kB 05 Cached:        4892024 kB 06 SwapCached:        112 kB 07 ... 08 SwapTotal:     4096564 kB 09 SwapFree:      4096424 kB 10 ... Linux性能監測：網絡篇      網絡的監測是所有 Linux 子系統裡面最復雜的，有太多的因素在裡面，比如：延遲、阻塞、沖突、丟包等，更糟的是與 Linux 主機相連的路由器、交換機、無線信號都會影響到整體網絡並且很難判斷是因為 Linux 網絡子系統的問題還是別的設備的問題，增加了監測和判斷的復雜度。現在我們使用的所有網卡都稱為自適應網卡，意思是說能根據網絡上的不同網絡設備導致的不 同網絡速度和工作模式進行自動調整。我們可以通過 ethtool 工具來查看網卡的配置和工作模式：  01 # /sbin/ethtool eth0 02 Settings for eth0: 03 Supported ports: [ TP ] 04 Supported link modes:   10baseT/Half 10baseT/Full 05                         100baseT/Half 100baseT/Full 06                         1000baseT/Half 1000baseT/Full 07 Supports auto-negotiation: Yes 08 Advertised link modes:  10baseT/Half 10baseT/Full 09                         100baseT/Half 100baseT/Full 10                         1000baseT/Half 1000baseT/Full 11 Advertised auto-negotiation: Yes 12 Speed: 100Mb/s 13 Duplex: Full 14 Port: Twisted Pair 15 PHYAD: 1 16 Transceiver: internal 17 Auto-negotiation: on 18 Supports Wake-on: g 19 Wake-on: g 20 Current message level: 0x000000ff (255) 21 Link detected: yes      上面給出的例子說明網卡有 10baseT，100baseT 和 1000baseT 三種選擇，目前正自適應為 100baseT（Speed: 100Mb/s）。可以通過 ethtool 工具強制網卡工作在 1000baseT 下：  1 # /sbin/ethtool -s eth0 speed 1000 duplex full autoneg off 2 iptraf 兩台主機之間有網線（或無線）、路由器、交換機等設備，測試兩台主機之間的網絡性能的一個辦法就是在這兩個系統之間互發數據並統計結果，看看吞吐 量、延遲、速率如何。iptraf 就是一個很好的查看本機網絡吞吐量的好工具，支持文字圖形界面，很直觀。下面圖片顯示在 100 mbps 速率的網絡下這個 Linux 系統的發送傳輸率有點慢，Outgoing rates 只有 66 mbps.  1 # iptraf -d eth0    netperf      netperf 運行在 client/server 模式下，比 iptraf 能更多樣化的測試終端的吞吐量。先在服務器端啟動 netserver：  1 # netserver 2 Starting netserver at port 12865 3 Starting netserver at hostname 0.0.0.0 port 12865 and family AF_UNSPEC 然後在客戶端測試服務器，執行一次持續10秒的 TCP 測試：  1 # netperf -H 172.16.38.36 -l 10 2 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 3 Recv   Send    Send 4 Socket Socket  Message  Elapsed 5 Size   Size    Size     Time     Throughput 6 bytes  bytes   bytes    secs.    10^6bits/sec  7   8  87380  16384  16384    10.32      93.68       從以上輸出可以看出，網絡吞吐量在 94mbps 左右，對於 100mbps 的網絡來說這個性能算的上很不錯。上面的測試是在服務器和客戶端位於同一個局域網，並且局域網是有線網的情況，你也可以試試不同結構、不同速率的網絡，比 如：網絡之間中間多幾個路由器、客戶端在 wi-fi、VPN 等情況。        netperf 還可以通過建立一個 TCP 連接並順序地發送數據包來測試每秒有多少 TCP 請求和響應。下面的輸出顯示在 TCP requests 使用 2K 大小，responses 使用 32K 的情況下處理速率為每秒243：  1 # netperf -t TCP_RR -H 172.16.38.36 -l 10 -- -r 2048,32768 2 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 3 Local /Remote 4 Socket Size   Request  Resp.   Elapsed  Trans. 5 Send   Recv   Size     Size    Time     Rate 6 bytes  Bytes  bytes    bytes   secs.    per sec   7   8 16384  87380  2048     32768   10.00     243.03 9 16384  87380 iperf  iperf 和 netperf 運行方式類似，也是 server/client 模式，先在服務器端啟動 iperf：  1 # iperf -s -D 2 ------------------------------------------------------------ 3 Server listening on TCP port 5001 4 TCP window size: 85.3 KByte (default) 5 ------------------------------------------------------------ 6 Running Iperf Server as a daemon 7 The Iperf daemon process ID : 5695 然後在客戶端對服務器進行測試，客戶端先連接到服務器端（172.16.38.36），並在30秒內每隔5秒對服務器和客戶端之間的網絡進行一次帶寬測試和采樣：  01 # iperf -c 172.16.38.36 -t 30 -i 5 02 ------------------------------------------------------------ 03 Client connecting to 172.16.38.36, TCP port 5001 04 TCP window size: 16.0 KByte (default) 05 ------------------------------------------------------------ 06 [  3] local 172.16.39.100 port 49515 connected with 172.16.38.36 port 5001 07 [ ID] Interval       Transfer     Bandwidth 08 [  3]  0.0- 5.0 sec  58.8 MBytes  98.6 Mbits/sec 09 [ ID] Interval       Transfer     Bandwidth 10 [  3]  5.0-10.0 sec  55.0 MBytes  92.3 Mbits/sec 11 [ ID] Interval       Transfer     Bandwidth 12 [  3] 10.0-15.0 sec  55.1 MBytes  92.4 Mbits/sec 13 [ ID] Interval       Transfer     Bandwidth 14 [  3] 15.0-20.0 sec  55.9 MBytes  93.8 Mbits/sec 15 [ ID] Interval       Transfer     Bandwidth 16 [  3] 20.0-25.0 sec  55.4 MBytes  92.9 Mbits/sec 17 [ ID] Interval       Transfer     Bandwidth 18 [  3] 25.0-30.0 sec  55.3 MBytes  92.8 Mbits/sec 19 [ ID] Interval       Transfer     Bandwidth 20 [  3]  0.0-30.0 sec    335 MBytes  93.7 Mbits/sec tcpdump 和 tcptrace       tcmdump 和 tcptrace 提供了一種更細致的分析方法，先用 tcpdump 按要求捕獲數據包把結果輸出到某一文件，然後再用 tcptrace 分析其文件格式。這個工具組合可以提供一些難以用其他工具發現的信息：  01 # /usr/sbin/tcpdump -w network.dmp 02 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 03 511942 packets captured 04 511942 packets received by filter 05 0 packets dropped by kernel 06   07 # tcptrace network.dmp 08 1 arg remaining, starting with 'network.dmp' 09 Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004 10   11 511677 packets seen, 511487 TCP packets traced 12 elapsed wallclock time: 0:00:00.510291, 1002714 pkts/sec analyzed 13 trace file elapsed time: 0:02:35.836372 14 TCP connection info: 15   1: zaber:54581 - boulder:111 (a2b)                   6>    5<  (complete) 16   2: zaber:833 - boulder:32774 (c2d)                   6>    5<  (complete) 17   3: zaber:pcanywherestat - 172.16.39.5:53086 (e2f)    2>    3< 18   4: zaber:716 - boulder:2049 (g2h)                  347>  257< 19   5: 172.16.39.100:58029 - zaber:12865 (i2j)           7>    5<  (complete) 20   6: 172.16.39.100:47592 - zaber:36814 (k2l)        255380> 255378<  (reset) 21   7: breakpoint:45510 - zaber:7012 (m2n)               9>    5<  (complete) 22   8: zaber:35813 - boulder:111 (o2p)                   6>    5<  (complete) 23   9: zaber:837 - boulder:32774 (q2r)                   6>    5<  (complete) 24  10: breakpoint:45511 - zaber:7012 (s2t)               9>    5<  (complete) 25  11: zaber:59362 - boulder:111 (u2v)                   6>    5<  (complete) 26  12: zaber:841 - boulder:32774 (w2x)                   6>    5<  (complete) 27  13: breakpoint:45512 - zaber:7012 (y2z)               9>    5<  (complete) tcptrace 功能很強大，還可以通過過濾和布爾表達式來找出有問題的連接，比如，找出轉播大於100 segments 的連接：  1 # tcptrace -f'rexmit_segs>100' network.dmp 如果發現連接 ＃10 有問題，可以查看關於這個連接的其他信息：  1 # tcptrace -o10 network.dmp 下面的命令使用 tcptrace 的 slice 模式，程序自動在當前目錄創建了一個 slice.dat 文件，這個文件包含了每隔15秒的轉播信息:  01 # tcptrace -xslice network.dmp 02   03 # cat slice.dat 04 date                segs    bytes  rexsegs rexbytes      new   active 05 --------------- -------- -------- -------- -------- -------- -------- 06 16:58:50.244708    85055  4513418        0        0        6        6 07 16:59:05.244708   110921  5882896        0        0        0        2 08 16:59:20.244708   126107  6697827        0        0        1        3 09 16:59:35.244708   151719  8043597        0        0        0        2 10 16:59:50.244708    37296  1980557        0        0        0        3 11 17:00:05.244708       67     8828        0        0        2        3 12 17:00:20.244708      149    22053        0        0        1        2 13 17:00:35.244708       30     4080        0        0        0        1 14 17:00:50.244708       39     5688        0        0        0        1 15 17:01:05.244708       67     8828        0        0        2        3 16 17:01:11.081080       37     4121        0        0        1        3