一個依據 Linux 操作體系的效勞器運轉的一起，也會表征出各式各樣參數信息。一般來說運維人員、體系管理員會對這些數據會極為靈敏，可是這些參數關于開發(fā)者來說也十分重要，特別當你的程序非正常作業(yè)的時分，這些蛛絲馬跡往往會協(xié)助快速定位盯梢問題。

這兒僅僅一些簡略的東西檢查體系的相關參數，當然許多東西也是經過剖析加工 /proc、/sys 下的數據來作業(yè)的，而那些愈加詳盡、專業(yè)的功用監(jiān)測和調優(yōu)，可能還需求愈加專業(yè)的東西(perf、systemtap 等)和技能才干完結哦。

究竟來說，體系功用監(jiān)控自身就是個大學識。

?

一、CPU和內存類

1.1 top



榜首行后邊的三個值是體系在之前 1、5、15 的均勻負載，也能夠看出體系負載是上升、平穩(wěn)、下降的趨勢，當這個值超越 CPU 可履行單元的數目，則標明 CPU 的功用現已飽滿成為瓶頸了。

第二行計算了體系的使命狀況信息。running 很天然不用多說，包含正在 CPU 上運轉的和將要被調度運轉的;sleeping 一般是等候工作(比方 IO 操作)完結的使命，細分能夠包含 interruptible 和 uninterruptible 的類型;stopped 是一些被暫停的使命，一般發(fā)送 SIGSTOP 或許對一個前臺使命操作 Ctrl-Z 能夠將其暫停;zombie 僵尸使命，盡管進程停止資源會被主動收回，可是含有退出使命的 task descriptor 需求父進程拜訪后才干開釋，這種進程閃現為 defunct 狀況，不管是因為父進程提早退出仍是未 wait 調用，呈現這種進程都應該分外留意程序是否規(guī)劃有誤。

第三行 CPU 占用率依據類型有以下幾種狀況：

(us) user：CPU 在低 nice 值(高優(yōu)先級)用戶態(tài)所占用的時刻(nice<=0)。正常狀況下只需效勞器不是很閑，那么大部分的 CPU 時刻應該都在此履行這類程序
(sy) system：CPU 處于內核態(tài)所占用的時刻，操作體系經過體系調用(system call)從用戶態(tài)墮入內核態(tài)，以履行特定的效勞;一般狀況下該值會比較小，可是當效勞器履行的 IO 比較密布的時分，該值會比較大
(ni) nice：CPU 在高 nice 值(低優(yōu)先級)用戶態(tài)以低優(yōu)先級運轉占用的時刻(nice>0)。默許新發(fā)動的進程 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 運用率過高狀況下指明晰相應地排查思路：

當 user 占用率過高的時分，一般是某些個其他進程占用了許多的 CPU，這時分很簡略經過 top 找到該程序;此刻如果置疑程序反常，能夠經過 perf 等思路找出熱門調用函數來進一步排查;
當 system 占用率過高的時分，如果 IO 操作(包含終端 IO)比較多，可能會形成這部分的 CPU 占用率高，比方在 file server、database server 等類型的效勞器上，不然(比方>20%)很可能有些部分的內核、驅動模塊有問題;
當 nice 占用率過高的時分，一般是有意行為，當進程的建議者知道某些進程占用較高的 CPU，會設置其 nice 值保證不會吞沒其他進程對 CPU 的運用懇求;
當 iowait 占用率過高的時分，一般意味著某些程序的 IO 操作功率很低，或許 IO 對應設備的功用很低以至于讀寫操作需求很長的時刻來完結;
當 irq/softirq 占用率過高的時分，很可能某些外設呈現問題，導致發(fā)作許多的irq懇求，這時分經過檢查 /proc/interrupts 文件來深究問題所在;
當 steal 占用率過高的時分，黑心廠商虛擬機超售了吧!
第四行和第五行是物理內存和虛擬內存(交流分區(qū))的信息：

total = free + used + buff/cache，現在buffers和cached Mem信息總和到一起了，可是buffers和cached

Mem 的聯(lián)系許多當地都沒說清楚。其實經過比照數據，這兩個值就是 /proc/meminfo 中的 Buffers 和 Cached 字段：Buffers 是針對 raw disk 的塊緩存，首要是以 raw block 的方法緩存文件體系的元數據(比方超級塊信息等)，這個值一般比較小(20M左右);而 Cached 是針關于某些詳細的文件進行讀緩存，以添加文件的拜訪功率而運用的，能夠說是用于文件體系中文件緩存運用。

而 avail Mem 是一個新的參數值，用于指示在不進行交流的狀況下，能夠給新敞開的程序多少內存空間，大致和 free + buff/cached 適當，而這也印證了上面的說法，free + buffers + cached Mem才是真實可用的物理內存。并且，運用交流分區(qū)不見得是壞工作，所以交流分區(qū)運用率不是什么嚴峻的參數，可是頻頻的 swap in/out 就不是好工作了，這種狀況需求留意，一般標明物理內存緊缺的狀況。

最終是每個程序的資源占用列表，其間 CPU 的運用率是一切 CPU core 占用率的總和。一般履行 top 的時分，自身該程序會許多的讀取 /proc 操作，所以根本該 top 程序自身也會是獨占鰲頭的。

top 盡管十分強壯，可是一般用于控制臺實時監(jiān)測體系信息，不適合長時刻(幾天、幾個月)監(jiān)測體系的負載信息，一起關于短壽的進程也會遺失無法給出計算信息。

1.2 vmstat

vmstat 是除 top 之外另一個常用的體系檢測東西，下面截圖是我用-j4編譯boost的體系負載。



r 標明可運轉進程數目，數據大致相符;而b標明的是 uninterruptible 睡覺的進程數目;swpd 標明運用到的虛擬內存數量，跟 top-Swap-used 的數值是一個含義，而如手冊所說，一般狀況下 buffers 數目要比 cached Mem 小的多，buffers 一般20M這么個數量級;io 域的 bi、bo 標明每秒鐘向磁盤接納和發(fā)送的塊數目(blocks/s);system 域的 in 標明每秒鐘的體系中止數(包含時鐘中止)，cs標明因為進程切換導致上下文切換的數目。

提到這兒，想到曾經許多人糾結編譯 linux kernel 的時分 -j 參數究竟是 CPU Core 仍是 CPU Core+1?經過上面修正 -j 參數值編譯 boost 和 linux kernel 的一起敞開 vmstat 監(jiān)控，發(fā)現兩種狀況下 context switch 根本沒有改變，且也只要明顯添加 -j 值后 context switch 才會有明顯的添加，看來不用過于糾結這個參數了，盡管詳細編譯時刻長度我還沒有測驗。材料說如果不是在體系發(fā)動或許 benchmark 的狀況，參數 context switch>100000 程序必定有問題。

1.3 pidstat

如果想對某個進程進行全面詳細的追尋，沒有什么比 pidstat 更適宜的了——?？臻g、缺頁狀況、主被迫切換等信息盡收眼底。這個指令最有用的參數是-t，能夠將進程中各個線程的詳細信息羅列出來。

-r： 閃現缺頁過錯和內存運用狀況，缺頁過錯是程序需求拜訪映射在虛擬內存空間中可是還尚未被加載到物理內存中的一個分頁，缺頁過錯兩個首要類型是

minflt/s 指的 minor faults，當需求拜訪的物理頁面因為某些原因(比方同享頁面、緩存機制等)現已存在于物理內存中了，僅僅在當時進程的頁表中沒有引證，MMU 只需求設置對應的 entry 就能夠了，這個價值是適當小的
majflt/s 指的 major faults，MMU 需求在當時可用物理內存中懇求一塊閑暇的物理頁面(如果沒有可用的閑暇頁面，則需求將其他物理頁面切換到交流空間去以開釋得到閑暇物理頁面)，然后從外部加載數據到該物理頁面中，并設置好對應的 entry，這個價值是適當高的，和前者有幾個數據級的差異
-s：棧運用狀況，包含 StkSize 為線程保存的?？臻g，以及 StkRef 實際運用的棧空間。運用ulimit -s發(fā)現CentOS 6.x上面默許?？臻g是10240K，而 CentOS 7.x、Ubuntu系列默許?？臻g巨細為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 其他

當需求獨自監(jiān)測單個 CPU 狀況的時分，除了 htop 還能夠運用 mpstat，檢查在 SMP 處理器上各個 Core 的作業(yè)量是否負載均衡，是否有某些熱門線程占用 Core。

? ~ mpstat -P ALL 1

如果想直接監(jiān)測某個進程占用的資源，既能夠運用top -u taozj的方法過濾掉其他用戶無關進程，也能夠選用下面的方法進行挑選，ps指令能夠自定義需求打印的條目信息：

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

如想理清承繼聯(lián)系，下面一個常用的參數能夠用于閃現進程樹結構，閃現作用比pstree詳細漂亮的多

? ~ ps axjf

二、磁盤IO類

iotop 能夠直觀的閃現各個進程、線程的磁盤讀取實時速率;lsof 不只能夠閃現一般文件的翻開信息(運用者)，還能夠操作 /dev/sda1 這類設備文件的翻開信息，那么比方當分區(qū)無法 umount 的時分，就能夠經過 lsof 找出磁盤該分區(qū)的運用狀況了，并且添加 +fg 參數還能夠額定閃現文件翻開 flag 符號。

2.1 iostat

? ~ iostat -xz 1

其實不管運用 iostat -xz 1 仍是運用 sar -d 1，關于磁盤重要的參數是：

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 作業(yè)時刻的占比，單個磁盤當 %util>60% 的時分功用就會下降(體現在 await 也會添加)，當挨近100%時分就設備飽滿了，但關于有多個磁盤陣列的邏輯磁盤狀況在外;
還有，盡管監(jiān)測到的磁盤功用比較差，可是不必定會對應用程序的呼應形成影響，內核一般運用 I/O asynchronously 技能，運用讀寫緩存技能來改進功用，不過這又跟上面的物理內存的約束相制約了。

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

三、網絡類

網絡功用關于效勞器的重要性顯而易見，東西 iptraf 能夠直觀的實際網卡的收發(fā)速度信息，比較的簡練便利經過 sar -n DEV 1 也能夠得到相似的吞吐量信息，而網卡都標配了最大速率信息，比方百兆網卡千兆網卡，很簡略檢查設備的利用率。

一般，網卡的傳輸速率并不是網絡開發(fā)中最為關懷的，而是針對特定的 UDP、TCP 銜接的丟包率、重傳率，以及網絡延時等信息。

3.1 netstat

? ~ netstat -s

閃現自從體系發(fā)動以來，各個協(xié)議的整體數據信息。盡管參數信息比較豐富有用，可是累計值，除非兩次運轉做差才干得出當時體系的網絡狀況信息，亦或許運用 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 等各種層次各種協(xié)議的數據信息，我們只關懷 TCP 和 UDP。下面的指令除了閃現慣例狀況下段、數據報的收發(fā)狀況，還包含

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 的承認重傳機制會發(fā)作重傳操作
isegerr/s(tcpInErrs)：每秒鐘接納到犯錯的數據包(比方 checksum 失利)
UDP

? ~ sudo sar -n UDP 1

noport/s(udpNoPorts)：每秒鐘接納到的可是卻沒有應用程序在指定意圖端口的數據報個數
idgmerr/s(udpInErrors)：除了上面原因之外的本機接納到但卻無法派發(fā)的數據報個數
當然，這些數據必定程度上能夠闡明網絡可靠性，但也只要同詳細的事務需求場景結合起來才具有含義。

3.3 tcpdump

tcpdump 不得不說是個好東西。我們都知道本地調試的時分喜愛運用 wireshark，可是線上效勞端呈現問題怎么弄呢?

附錄的參考文獻給出了思路：恢復環(huán)境，運用 tcpdump 進行抓包，當問題復現(比方日志閃現或許某個狀況閃現)的時分，就能夠完畢抓包了，并且 tcpdump 自身帶有 -C/-W 參數，能夠約束抓取包存儲文件的巨細，當到達這個這個約束的時分保存的包數據主動 rotate，所以抓包數量整體仍是可控的。爾后將數據包拿下線來，用 wireshark 想怎么看就怎么看，豈不樂哉!tcpdump 盡管沒有 GUI 界面，可是抓包的功用一點點不弱，能夠指定網卡、主機、端口、協(xié)議等各項過濾參數，抓下來的包完好又帶有時刻戳，所以線上程序的數據包剖析也能夠這么簡略。

下面就是一個小的測驗，可見 Chrome 發(fā)動時分主意向 Webserver 建議樹立了三條銜接，因為這兒約束了 dst port 參數，所以效勞端的應對包被過濾掉了，拿下來用 wireshark 翻開，SYNC、ACK 樹立銜接的進程仍是很明顯的!在運用 tcpdump 的時分，需求盡可能的裝備抓取的過濾條件，一方面便于接下來的剖析，二則 tcpdump 敞開后對網卡和體系的功用會有影響，進而會影響到在線事務的功用。



本文完!