最詳細的 Linux 服務器性能參數指標

一個基於Linux操做系統的服務器運行的同時，也會表徵出各類各樣參數信息。一般來講運維人員、系統管理員會對這些數據會極爲敏感，可是這些參數對於開發者來講也十分重要，尤爲當你的程序非正常工做的時候，這些蛛絲馬跡每每會幫助快速定位跟蹤問題。

這裏只是一些簡單的工具查看系統的相關參數，固然不少工具也是經過分析加工/proc、/sys下的數據來工做的，而那些更加細緻、專業的性能監測和調優，可能還須要更加專業的工具(perf、systemtap等)和技術才能完成哦。畢竟來講，系統性能監控自己就是個大學問。

1、CPU和內存類

1.1 top

~ top

第一行後面的三個值是系統在以前一、五、15的平均負載，也能夠看出系統負載是上升、平穩、降低的趨勢，當這個值超過CPU可執行單元的數目，則表示CPU的性能已經飽和成爲瓶頸了。

第二行統計了系統的任務狀態信息。running很天然沒必要多說，包括正在CPU上運行的和將要被調度運行的；sleeping一般是等待事件(好比IO操做)完成的任務，細分能夠包括interruptible和uninterruptible的類型；stopped是一些被暫停的任務，一般發送SIGSTOP或者對一個前臺任務操做Ctrl-Z能夠將其暫停；zombie殭屍任務，雖然進程終止資源會被自動回收，可是含有退出任務的task descriptor須要父進程訪問後才能釋放，這種進程顯示爲defunct狀態，不管是由於父進程提早退出仍是未wait調用，出現這種進程都應該格外注意程序是否設計有誤。

第三行CPU佔用率根據類型有如下幾種狀況：

• (us) user: CPU在低nice值(高優先級)用戶態所佔用的時間(nice<=0)。正常狀況下只要服務器不是很閒，那麼大部分的CPU時間應該都在此執行這類程序

• (sy) system: CPU處於內核態所佔用的時間，操做系統經過系統調用(system call)從用戶態陷入內核態，以執行特定的服務；一般狀況下該值會比較小，可是當服務器執行的IO比較密集的時候，該值會比較大

• (ni) nice: CPU在高nice值(低優先級)用戶態以低優先級運行佔用的時間(nice>0)。默認新啓動的進程nice=0，是不會計入這裏的，除非手動經過renice或者setpriority()的方式修改程序的nice值

• (id) idle: CPU在空閒狀態(執行kernel idle handler)所佔用的時間

• (wa) iowait: 等待IO完成作佔用的時間

• (hi) irq: 系統處理硬件中斷所消耗的時間

• (si) softirq: 系統處理軟中斷所消耗的時間，記住軟中斷分爲softirqs、tasklets(實際上是前者的特例)、work queues，不知道這裏是統計的是哪些的時間，畢竟work queues的執行已經不是中斷上下文了

• (st) steal: 在虛擬機狀況下才有意義，由於虛擬機下CPU也是共享物理CPU的，因此這段時間代表虛擬機等待hypervisor調度CPU的時間，也意味着這段時間hypervisor將CPU調度給別的CPU執行，這個時段的CPU資源被」stolen」了。這個值在我KVM的VPS機器上是不爲0的，但也只有0.1這個數量級，是否是能夠用來判斷VPS超售的狀況？

CPU佔用率高不少狀況下意味着一些東西，這也給服務器CPU使用率太高狀況下指明瞭相應地排查思路：

• (a) 當user佔用率太高的時候，一般是某些個別的進程佔用了大量的CPU，這時候很容易經過top找到該程序；此時若是懷疑程序異常，能夠經過perf等思路找出熱點調用函數來進一步排查；

• (b) 當system佔用率太高的時候，若是IO操做(包括終端IO)比較多，可能會形成這部分的CPU佔用率高，好比在file server、database server等類型的服務器上，不然(好比>20%)極可能有些部分的內核、驅動模塊有問題；

• (c) 當nice佔用率太高的時候，一般是有意行爲，當進程的發起者知道某些進程佔用較高的CPU，會設置其nice值確保不會淹沒其餘進程對CPU的使用請求；

• (d) 當iowait佔用率太高的時候，一般意味着某些程序的IO操做效率很低，或者IO對應設備的性能很低以致於讀寫操做須要很長的時間來完成；

• (e) 當irq/softirq佔用率太高的時候，極可能某些外設出現問題，致使產生大量的irq請求，這時候經過檢查/proc/interrupts文件來深究問題所在；

• (f) 當steal佔用率太高的時候，黑心廠商虛擬機超售了吧！

第四行和第五行是物理內存和虛擬內存(交換分區)的信息:

total = free + used + buff/cache，如今buffers和cached Mem信息總和到一塊兒了，可是buffers和cached Mem的關係不少地方都沒說清楚。其實經過對比數據，這兩個值就是/proc/meminfo中的Buffers和Cached字段：Buffers是針對raw disk的塊緩存，主要是以raw block的方式緩存文件系統的元數據(好比超級塊信息等)，這個值通常比較小(20M左右)；而Cached是針對於某些具體的文件進行讀緩存，以增長文件的訪問效率而使用的，能夠說是用於文件系統中文件緩存使用。

而avail Mem是一個新的參數值，用於指示在不進行交換的狀況下，能夠給新開啓的程序多少內存空間，大體和free + buff/cached至關，而這也印證了上面的說法，free + buffers + cached Mem纔是真正可用的物理內存。而且，使用交換分區不見得是壞事情，因此交換分區使用率不是什麼嚴重的參數，可是頻繁的swap in/out就不是好事情了，這種狀況須要注意，一般表示物理內存緊缺的狀況。

最後是每一個程序的資源佔用列表，其中CPU的使用率是全部CPU core佔用率的總和。一般執行top的時候，自己該程序會大量的讀取/proc操做，因此基本該top程序自己也會是名列前茅的。

top雖然很是強大，可是一般用於控制檯實時監測系統信息，不適合長時間(幾天、幾個月)監測系統的負載信息，同時對於短命的進程也會遺漏沒法給出統計信息。

1.2 vmstat

vmstat是除top以外另外一個經常使用的系統檢測工具，下面截圖是我用-j4編譯boost的系統負載。

r表示可運行進程數目，數據大體相符；而b表示的是uninterruptible睡眠的進程數目；swpd表示使用到的虛擬內存數量，跟top-Swap-used的數值是一個含義，而如手冊所說，一般狀況下buffers數目要比cached Mem小的多，buffers通常20M這麼個數量級；io域的bi、bo代表每秒鐘向磁盤接收和發送的塊數目(blocks/s)；system域的in代表每秒鐘的系統中斷數(包括時鐘中斷)，cs代表由於進程切換致使上下文切換的數目。

說到這裏，想到之前不少人糾結編譯linux kernel的時候-j參數到底是CPU Core仍是CPU Core+1？經過上面修改-j參數值編譯boost和linux kernel的同時開啓vmstat監控，發現兩種狀況下context switch基本沒有變化，且也只有顯著增長-j值後context switch纔會有顯著的增長，看來沒必要過於糾結這個參數了，雖然具體編譯時間長度我尚未測試。資料說若是不是在系統啓動或者benchmark的狀態，參數context switch>100000程序確定有問題。

1.3 pidstat

若是想對某個進程進行全面具體的追蹤，沒有什麼比pidstat更合適的了——棧空間、缺頁狀況、主被動切換等信息一覽無餘。這個命令最有用的參數是-t，能夠將進程中各個線程的詳細信息羅列出來。

-r： 顯示缺頁錯誤和內存使用情況，缺頁錯誤是程序須要訪問映射在虛擬內存空間中可是還還沒有被加載到物理內存中的一個分頁，缺頁錯誤兩個主要類型是

(a). minflt/s 指的minor faults，當須要訪問的物理頁面由於某些緣由(好比共享頁面、緩存機制等)已經存在於物理內存中了，只是在當前進程的頁表中沒有引用，MMU只須要設置對應的entry就能夠了，這個代價是至關小的

(b). majflt/s 指的major faults，MMU須要在當前可用物理內存中申請一塊空閒的物理頁面(若是沒有可用的空閒頁面，則須要將別的物理頁面切換到交換空間去以釋放獲得空閒物理頁面)，而後從外部加載數據到該物理頁面中，並設置好對應的entry，這個代價是至關高的，和前者有幾個數據級的差別

-s：棧使用情況，包括StkSize爲線程保留的棧空間，以及StkRef實際使用的棧空間。使用ulimit -s發現CentOS 6.x上面默認棧空間是10240K，而CentOS 7.x、Ubuntu系列默認棧空間大小爲8196K

-u：CPU使用率狀況，參數同前面相似

-w：線程上下文切換的數目，還細分爲cswch/s由於等待資源等因素致使的主動切換，以及nvcswch/s線程CPU時間致使的被動切換的統計

若是每次都先ps獲得程序的pid後再操做pidstat會顯得很麻煩，因此這個殺手鐗的-C能夠指定某個字符串，而後Command中若是包含這個字符串，那麼該程序的信息就會被打印統計出來，-l能夠顯示完整的程序名和參數
~ pidstat -w -t -C 「ailaw」 -l 

這麼看來，若是查看單個尤爲是多線程的任務時候，pidstat比經常使用的ps更好使！

1.4 其餘

當須要單獨監測單個CPU狀況的時候，除了htop還可使用mpstat，查看在SMP處理器上各個Core的工做量是否負載均衡，是否有某些熱點線程佔用Core。

~ mpstat -P ALL 1

若是想直接監測某個進程佔用的資源，既可使用top -u taozj的方式過濾掉其餘用戶無關進程，也能夠採用下面的方式進行選擇，ps命令能夠自定義須要打印的條目信息：

while :; do ps -eo user,pid,ni,pri,pcpu,psr,comm | grep 'ailawd'; sleep 1; done

如想理清繼承關係，下面一個經常使用的參數能夠用於顯示進程樹結構，顯示效果比pstree詳細美觀的多

~ ps axjf

2、磁盤IO類

iotop能夠直觀的顯示各個進程、線程的磁盤讀取實時速率；lsof不只能夠顯示普通文件的打開信息(使用者)，還能夠操做/dev/sda1這類設備文件的打開信息，那麼好比當分區沒法umount的時候，就能夠經過lsof找出磁盤該分區的使用狀態了，並且添加+fg參數還能夠額外顯示文件打開flag標記。

2.1 iostat

~ iostat -xz 1

其實不管使用iostat -xz 1仍是使用sar -d 1，對於磁盤重要的參數是：

avgqu-sz: 發送給設備I/O請求的等待隊列平均長度，對於單個磁盤若是值>1代表設備飽和，對於多個磁盤陣列的邏輯磁盤狀況除外；
await(r_await、w_await): 平均每次設備I/O請求操做的等待時間(ms)，包含請求排列在隊列中和被服務的時間之和；

svctm: 發送給設備I/O請求的平均服務時間(ms)，若是svctm與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，不然磁盤隊列等待時間較長，磁盤響應較差；

%util: 設備的使用率，代表每秒中用於I/O工做時間的佔比，單個磁盤當%util>60%的時候性能就會降低(體如今await也會增長)，當接近100%時候就設備飽和了，但對於有多個磁盤陣列的邏輯磁盤狀況除外；

還有，雖然監測到的磁盤性能比較差，可是不必定會對應用程序的響應形成影響，內核一般使用I/O asynchronously技術，使用讀寫緩存技術來改善性能，不過這又跟上面的物理內存的限制相制約了。

上面的這些參數，對網絡文件系統也是受用的。

3、網絡類

網絡性能對於服務器的重要性不言而喻，工具iptraf能夠直觀的現實網卡的收發速度信息，比較的簡潔方便經過sar -n DEV 1也能夠獲得相似的吞吐量信息，而網卡都標配了最大速率信息，好比百兆網卡千兆網卡，很容易查看設備的利用率。

一般，網卡的傳輸速率並非網絡開發中最爲關切的，而是針對特定的UDP、TCP鏈接的丟包率、重傳率，以及網絡延時等信息。

3.1 netstat

~ netstat -s

顯示自從系統啓動以來，各個協議的整體數據信息。雖然參數信息比較豐富有用，可是累計值，除非兩次運行作差才能得出當前系統的網絡狀態信息，亦或者使用watch眼睛直觀其數值變化趨勢。因此netstat一般用來檢測端口和鏈接信息的：

netstat –all(a) –numeric(n) –tcp(t) –udp(u) –timers(o) –listening(l) –program(p)

–timers能夠取消域名反向查詢，加快顯示速度；比較經常使用的有

  ~ netstat -antp  #列出全部TCP的鏈接  ~ netstat -nltp   #列出本地全部TCP偵聽套接字，不要加-a參數

3.2 sar

sar這個工具太強大了，什麼CPU、磁盤、頁面交換啥都管，這裏使用-n主要用來分析網絡活動，雖然網絡中它還給細分了NFS、IP、ICMP、SOCK等各類層次各類協議的數據信息，咱們只關心TCP和UDP。下面的命令除了顯示常規狀況下段、數據報的收發狀況，還包括
TCP

~ sudo sar -n TCP,ETCP 1 

active/s：本地發起的TCP鏈接，好比經過connect()，TCP的狀態從CLOSED -> SYN-SENT

passive/s：由遠程發起的TCP鏈接，好比經過accept()，TCP的狀態從LISTEN -> SYN-RCVD

retrans/s(tcpRetransSegs)：每秒鐘TCP重傳數目，一般在網絡質量差，或者服務器過載後丟包的狀況下，根據TCP的確認重傳機制會發生重傳操做

isegerr/s(tcpInErrs)：每秒鐘接收到出錯的數據包(好比checksum失敗)

UDP

~ sudo sar -n UDP 1 

noport/s(udpNoPorts)：每秒鐘接收到的可是卻沒有應用程序在指定目的端口的數據報個數

idgmerr/s(udpInErrors)：除了上面緣由以外的本機接收到但卻沒法派發的數據報個數

固然，這些數據必定程度上能夠說明網絡可靠性，但也只有同具體的業務需求場景結合起來才具備意義。

3.3 tcpdump

tcpdump不得不說是個好東西。你們都知道本地調試的時候喜歡使用wireshark，可是線上服務端出現問題怎麼弄呢？附錄的參考文獻給出了思路：復原環境，使用tcpdump進行抓包，當問題復現(好比日誌顯示或者某個狀態顯現)的時候，就能夠結束抓包了，並且tcpdump自己帶有-C/-W參數，能夠限制抓取包存儲文件的大小，當達到這個這個限制的時候保存的包數據自動rotate，因此抓包數量整體仍是可控的。此後將數據包拿下線來，用wireshark想怎麼看就怎麼看，豈不樂哉！tcpdump雖然沒有GUI界面，可是抓包的功能絲絕不弱，能夠指定網卡、主機、端口、協議等各項過濾參數，抓下來的包完整又帶有時間戳，因此線上程序的數據包分析也能夠這麼簡單。
下面就是一個小的測試，可見Chrome啓動時候自動向Webserver發起創建了三條鏈接，因爲這裏限制了dst port參數，因此服務端的應答包被過濾掉了，拿下來用wireshark打開，SYNC、ACK創建鏈接的過程仍是很明顯的！在使用tcpdump的時候，須要儘量的配置抓取的過濾條件，一方面便於接下來的分析，二則tcpdump開啓後對網卡和系統的性能會有影響，進而會影響到在線業務的性能。

本文完！