Linux 服務器性能出問題的解決方案

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

這里只是一些簡單的工具查看系統(tǒng)的相關(guān)參數(shù)，當然很多工具也是通過分析加工 /proc、/sys 下的數(shù)據(jù)來工作的，而那些更加細致、專業(yè)的性能監(jiān)測和調(diào)優(yōu)，可能還需要更加專業(yè)的工具(perf、systemtap 等)和技術(shù)才能完成哦。

畢竟來說，系統(tǒng)性能監(jiān)控本身就是個大學問。

一、CPU和內(nèi)存類

1.1

top

? ~ top

第一行后面的三個值是系統(tǒng)在之前 1、5、15 的平均負載，也可以看出系統(tǒng)負載是上升、平穩(wěn)、下降的趨勢，當這個值超過 CPU 可執(zhí)行單元的數(shù)目，則表示 CPU 的性能已經(jīng)飽和成為瓶頸了。

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

(us) user：CPU 在低 nice 值(高優(yōu)先級)用戶態(tài)所占用的時間(nice<=0)。正常情況下只要服務器不是很閑，那么大部分的 CPU 時間應該都在此執(zhí)行這類程序

(sy) system：CPU 處于內(nèi)核態(tài)所占用的時間，操作系統(tǒng)通過系統(tǒng)調(diào)用(system call)從用戶態(tài)陷入內(nèi)核態(tài)，以執(zhí)行特定的服務；通常情況下該值會比較小，但是當服務器執(zhí)行的 IO 比較密集的時候，該值會比較大

(ni) nice：CPU 在高 nice 值(低優(yōu)先級)用戶態(tài)以低優(yōu)先級運行占用的時間(nice>0)。默認新啟動的進程 nice=0，是不會計入這里的，除非手動通過 renice 或者 setpriority() 的方式修改程序的nice值

(id) idle：CPU 在空閑狀態(tài)(執(zhí)行 kernel idle handler )所占用的時間

(wa) iowait：等待 IO 完成做占用的時間

(hi) irq：系統(tǒng)處理硬件中斷所消耗的時間

(si) softirq：系統(tǒng)處理軟中斷所消耗的時間，記住軟中斷分為 softirqs、tasklets (其實是前者的特例)、work queues，不知道這里是統(tǒng)計的是哪些的時間，畢竟 work queues 的執(zhí)行已經(jīng)不是中斷上下文了

(st) steal：在虛擬機情況下才有意義，因為虛擬機下 CPU 也是共享物理 CPU 的，所以這段時間表明虛擬機等待 hypervisor 調(diào)度 CPU 的時間，也意味著這段時間 hypervisor 將 CPU 調(diào)度給別的 CPU 執(zhí)行，這個時段的 CPU 資源被“stolen”了。這個值在我 KVM 的 VPS 機器上是不為 0 的，但也只有 0.1 這個數(shù)量級，是不是可以用來判斷 VPS 超售的情況？

CPU 占用率高很多情況下意味著一些東西，這也給服務器 CPU 使用率過高情況下指明了相應地排查思路：

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

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

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

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

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

當 steal 占用率過高的時候，黑心廠商虛擬機超售了吧！

第四行和第五行是物理內(nèi)存和虛擬內(nèi)存(交換分區(qū))的信息：total = free + used + buff/cache，現(xiàn)在buffers和cached Mem信息總和到一起了，但是buffers和cached

Mem 的關(guān)系很多地方都沒說清楚。其實通過對比數(shù)據(jù)，這兩個值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是針對 raw disk 的塊緩存，主要是以 raw block 的方式緩存文件系統(tǒng)的元數(shù)據(jù)(比如超級塊信息等)，這個值一般比較小(20M左右)；而 Cached 是針對于某些具體的文件進行讀緩存，以增加文件的訪問效率而使用的，可以說是用于文件系統(tǒng)中文件緩存使用。

而 avail Mem 是一個新的參數(shù)值，用于指示在不進行交換的情況下，可以給新開啟的程序多少內(nèi)存空間，大致和 free + buff/cached 相當，而這也印證了上面的說法，free + buffers + cached Mem才是真正可用的物理內(nèi)存。并且，使用交換分區(qū)不見得是壞事情，所以交換分區(qū)使用率不是什么嚴重的參數(shù)，但是頻繁的 swap in/out 就不是好事情了，這種情況需要注意，通常表示物理內(nèi)存緊缺的情況。

最后是每個程序的資源占用列表，其中 CPU 的使用率是所有 CPU core 占用率的總和。通常執(zhí)行 top 的時候，本身該程序會大量的讀取 /proc 操作，所以基本該 top 程序本身也會是名列前茅的。

top 雖然非常強大，但是通常用于控制臺實時監(jiān)測系統(tǒng)信息，不適合長時間(幾天、幾個月)監(jiān)測系統(tǒng)的負載信息，同時對于短命的進程也會遺漏無法給出統(tǒng)計信息。

1.2

vmstat

vmstat 是除 top 之外另一個常用的系統(tǒng)檢測工具，下面截圖是我用-j4編譯boost的系統(tǒng)負載。

說到這里，想到以前很多人糾結(jié)編譯 linux kernel 的時候 -j 參數(shù)究竟是 CPU Core 還是 CPU Core+1？通過上面修改 -j 參數(shù)值編譯 boost 和 linux kernel 的同時開啟 vmstat 監(jiān)控，發(fā)現(xiàn)兩種情況下 context switch 基本沒有變化，且也只有顯著增加 -j 值后 context switch 才會有顯著的增加，看來不必過于糾結(jié)這個參數(shù)了，雖然具體編譯時間長度我還沒有測試。資料說如果不是在系統(tǒng)啟動或者 benchmark 的狀態(tài)，參數(shù) context switch>100000 程序肯定有問題。

1.3

pidstat

如果想對某個進程進行全面具體的追蹤，沒有什么比 pidstat 更合適的了——?？臻g、缺頁情況、主被動切換等信息盡收眼底。這個命令最有用的參數(shù)是-t，可以將進程中各個線程的詳細信息羅列出來。

-r： 顯示缺頁錯誤和內(nèi)存使用狀況，缺頁錯誤是程序需要訪問映射在虛擬內(nèi)存空間中但是還尚未被加載到物理內(nèi)存中的一個分頁，缺頁錯誤兩個主要類型是

minflt/s 指的 minor faults，當需要訪問的物理頁面因為某些原因(比如共享頁面、緩存機制等)已經(jīng)存在于物理內(nèi)存中了，只是在當前進程的頁表中沒有引用，MMU 只需要設置對應的 entry 就可以了，這個代價是相當小的

majflt/s 指的 major faults，MMU 需要在當前可用物理內(nèi)存中申請一塊空閑的物理頁面(如果沒有可用的空閑頁面，則需要將別的物理頁面切換到交換空間去以釋放得到空閑物理頁面)，然后從外部加載數(shù)據(jù)到該物理頁面中，并設置好對應的 entry，這個代價是相當高的，和前者有幾個數(shù)據(jù)級的差異

-s：棧使用狀況，包括 StkSize 為線程保留的?？臻g，以及 StkRef 實際使用的?？臻g。使用ulimit -s發(fā)現(xiàn)CentOS 6.x上面默認棧空間是10240K，而 CentOS 7.x、Ubuntu系列默認?？臻g大小為8196K

-u：CPU使用率情況，參數(shù)同前面類似

-w：線程上下文切換的數(shù)目，還細分為cswch/s因為等待資源等因素導致的主動切換，以及nvcswch/s線程CPU時間導致的被動切換的統(tǒng)計

如果每次都先ps得到程序的pid后再操作pidstat會顯得很麻煩，所以這個殺手锏的-C可以指定某個字符串，然后Command中如果包含這個字符串，那么該程序的信息就會被打印統(tǒng)計出來，-l可以顯示完整的程序名和參數(shù)? ~ pidstat -w -t -C “ailaw” -l

這么看來，如果查看單個尤其是多線程的任務時候，pidstat比常用的ps更好使！

1.4

其他

當需要單獨監(jiān)測單個 CPU 情況的時候，除了 htop 還可以使用 mpstat，查看在 SMP 處理器上各個 Core 的工作量是否負載均衡，是否有某些熱點線程占用 Core。? ~ mpstat -P ALL 1

如果想直接監(jiān)測某個進程占用的資源，既可以使用top -u taozj的方式過濾掉其他用戶無關(guān)進程，也可以采用下面的方式進行選擇，ps命令可以自定義需要打印的條目信息：

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

如想理清繼承關(guān)系，下面一個常用的參數(shù)可以用于顯示進程樹結(jié)構(gòu)，顯示效果比pstree詳細美觀的多

? ~ ps axjf

二、磁盤IO類

iotop 可以直觀的顯示各個進程、線程的磁盤讀取實時速率；lsof 不僅可以顯示普通文件的打開信息(使用者)，還可以操作 /dev/sda1 這類設備文件的打開信息，那么比如當分區(qū)無法 umount 的時候，就可以通過 lsof 找出磁盤該分區(qū)的使用狀態(tài)了，而且添加 +fg 參數(shù)還可以額外顯示文件打開 flag 標記。

2.1

iostat

? ~ iostat -xz 1

其實無論使用 iostat -xz 1 還是使用 sar -d 1，對于磁盤重要的參數(shù)是：

avgqu-s：發(fā)送給設備 I/O 請求的等待隊列平均長度，對于單個磁盤如果值>1表明設備飽和，對于多個磁盤陣列的邏輯磁盤情況除外

await(r_await、w_await)：平均每次設備 I/O 請求操作的等待時間(ms)，包含請求排列在隊列中和被服務的時間之和；

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

%util：設備的使用率，表明每秒中用于 I/O 工作時間的占比，單個磁盤當 %util>60% 的時候性能就會下降(體現(xiàn)在 await 也會增加)，當接近100%時候就設備飽和了，但對于有多個磁盤陣列的邏輯磁盤情況除外；

還有，雖然監(jiān)測到的磁盤性能比較差，但是不一定會對應用程序的響應造成影響，內(nèi)核通常使用 I/O asynchronously 技術(shù)，使用讀寫緩存技術(shù)來改善性能，不過這又跟上面的物理內(nèi)存的限制相制約了。

上面的這些參數(shù)，對網(wǎng)絡文件系統(tǒng)也是受用的。

三、網(wǎng)絡類

網(wǎng)絡性能對于服務器的重要性不言而喻，工具 iptraf 可以直觀的現(xiàn)實網(wǎng)卡的收發(fā)速度信息，比較的簡潔方便通過 sar -n DEV 1 也可以得到類似的吞吐量信息，而網(wǎng)卡都標配了最大速率信息，比如百兆網(wǎng)卡千兆網(wǎng)卡，很容易查看設備的利用率。

通常，網(wǎng)卡的傳輸速率并不是網(wǎng)絡開發(fā)中最為關(guān)切的，而是針對特定的 UDP、TCP 連接的丟包率、重傳率，以及網(wǎng)絡延時等信息。

3.1

netstat

? ~ netstat -s

顯示自從系統(tǒng)啟動以來，各個協(xié)議的總體數(shù)據(jù)信息。雖然參數(shù)信息比較豐富有用，但是累計值，除非兩次運行做差才能得出當前系統(tǒng)的網(wǎng)絡狀態(tài)信息，亦或者使用 watch 眼睛直觀其數(shù)值變化趨勢。所以netstat通常用來檢測端口和連接信息的：

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

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

? ~ netstat -antp #列出所有TCP的連接

? ~ netstat -nltp #列出本地所有TCP偵聽套接字，不要加-a參數(shù)

3.2

sar

sar 這個工具太強大了，什么 CPU、磁盤、頁面交換啥都管，這里使用 -n 主要用來分析網(wǎng)絡活動，雖然網(wǎng)絡中它還給細分了 NFS、IP、ICMP、SOCK 等各種層次各種協(xié)議的數(shù)據(jù)信息，我們只關(guān)心 TCP 和 UDP。下面的命令除了顯示常規(guī)情況下段、數(shù)據(jù)報的收發(fā)情況，還包括

TCP? ~ sudo sar -n TCP,ETCP 1

active/s：本地發(fā)起的 TCP 連接，比如通過 connect()，TCP 的狀態(tài)從CLOSED -> SYN-SENT

passive/s：由遠程發(fā)起的 TCP 連接，比如通過 accept()，TCP 的狀態(tài)從LISTEN -> SYN-RCVD

retrans/s(tcpRetransSegs)：每秒鐘 TCP 重傳數(shù)目，通常在網(wǎng)絡質(zhì)量差，或者服務器過載后丟包的情況下，根據(jù) TCP 的確認重傳機制會發(fā)生重傳操作

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

UDP? ~ sudo sar -n UDP 1

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

idgmerr/s(udpInErrors)：除了上面原因之外的本機接收到但卻無法派發(fā)的數(shù)據(jù)報個數(shù)

當然，這些數(shù)據(jù)一定程度上可以說明網(wǎng)絡可靠性，但也只有同具體的業(yè)務需求場景結(jié)合起來才具有意義。