Linux伺服器的那些效能參數指標

一個基於 Linux 作業系統的伺服器運作的同時，也會表徵出各種參數資訊。通常來說維運人員、系統管理員會對這些資料會極為敏感，但是這些參數對開發者來說也十分重要，尤其當你的程式非正常運作的時候，這些蛛絲馬跡往往會幫助快速定位追蹤問題。

這裡只是一些簡單的工具查看系統的相關參數，當然很多工具也是透過分析加工/proc、/sys 下的資料來運作的，而那些更細緻、專業的效能監控和調優，可能還需要更專業的工具(perf、systemtap 等)和技術才能完成哦。畢竟來說，系統效能監控本身就是大學問。

一、CPU與記憶體類別

#1.1 top

➜ ~ top

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

第二行統計了系統的任務狀態資訊。 running 很自然不必多說，包括正在CPU 上運行的和將要被調度運行的；sleeping 通常是等待事件(比如IO 操作)完成的任務，細分可以包括interruptible 和uninterruptible 的類型；stopped 是一些被暫停的任務，通常發送SIGSTOP 或對一個前台任務操作Ctrl-Z 可以將其暫停；zombie 殭屍任務，雖然進程終止資源會被自動回收，但是含有退出任務的task descriptor 需要父進程訪問後才能釋放，這種進程顯示為defunct 狀態，無論是因為父進程提前退出還是未wait 調用，出現這種進程都應該格外注意程式是否設計有誤。第三行 CPU 佔用率依型別有下列幾種情況：

　●　(us) user：CPU 在低 nice 值(高優先權)使用者態所佔用的時間(nice

　●　(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 使用率過高情況下指明了相應地排​​查思路：

1、當user 佔用率過高的時候，通常是某些個別的進程佔用了大量的CPU，這時候很容易透過top 找到該程式；此時如果懷疑程式異常，可以透過perf 等思路找出熱點呼叫函數來進一步排查；

2、當system 佔用率過高的時候，如果IO 操作(包括終端IO)比較多，可能會造成這部分的CPU 佔用率高，例如在file server、database server 等類型的伺服器上，否則(例如>20%)很可能有些部分的核心、驅動模組有問題；

3、當nice 佔用率過高的時候，通常是有意行為，當進程的發起者知道某些進程佔用較高的CPU，會設定其nice 值確保不會淹沒其他行程對CPU 的使用請求；

4、當iowait 佔用率過高的時候，通常意味著某些程式的IO 操作效率很低，或者IO 對應設備的效能很低以至於讀寫操作需要很長的時間來完成；

5、當irq/softirq 佔用率過高的時候，很可能某些週邊出現問題，導致產生大量的irq請求，這時候透過檢查/proc/interrupts 檔案來深究問題所在；

6、當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： 顯示缺頁錯誤和記憶體使用狀況，缺頁錯誤是程式需要存取映射在虛擬記憶體空間中但是還尚未載入到實體記憶體中的一個分頁，缺頁錯誤兩個主要類型是

minflt/s 指的minor faults，當需要存取的實體頁面因為某些原因(例如共享頁面、快取機制等)已經存在於實體記憶體中了，只是在目前進程的頁表中沒有引用，MMU 只需要設定對應的entry 就可以了，這個代價是相當小的

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

二、磁碟IO類別

iotop 可以直覺的顯示各個進程、執行緒的磁碟讀取即時速率；lsof 不僅可以顯示普通檔案的開啟資訊(使用者)，還可以操作/dev/sda1這類設備檔案的開啟訊息，那麼例如當分割區無法umount 的時候，就可以透過lsof 找出磁碟該分割區的使用狀態了，而且新增fg 參數還可以額外顯示檔案開啟flag 標記。

2.1 iostat

➜ ~ iostat -xz 1

其實無論使用iostat -xz 1 或使用sar -d 1，對於磁碟重要的參數是：

avgqu-s：傳送給裝置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 技術，使用讀寫快取技術來改善效能，不過這又跟上面的實體記憶體的限制相制約了。

上面的這些參數，對網路檔案系統也是受用的。

三、網路類別

網路效能對於伺服器的重要性不言而喻，工具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 開啟後對網卡和系統的性能會有影響，進而影響到在線業務的性能。

更多Linux文章，請造訪Linux教學欄位學習！

以上是Linux伺服器的那些效能參數指標的詳細內容。更多資訊請關注PHP中文網其他相關文章！