Linux 服務器的性能參數指標總結

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

一、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<=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 ) 所佔用的時間

√ (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 超售的情況？

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

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

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

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

√ 當 irq/softirq 佔用率過高的時候，很可能某些外設出現問題，導致產生大量的 irq 請求，這時候通過檢查 /proc/interrupts 文件來深究問題所在；

√ 當 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 表明因爲進程切換導致上下文切換的數目。

1.3 pidstat

-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

這麼看來，如果查看單個尤其是多線程的任務時候，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 開啓後對網卡和系統的性能會有影響，進而會影響到在線業務的性能。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/7LRpfYAviLjACKVZaogfxQ