茫茫網海中的冷日 - 對這文章發表回應
茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1671308 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
IMG_00062.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

對這文章發表回應

發表限制: 非會員 可以發表

發表者: 冷日 發表時間: 2019/6/11 14:23:37

Linux 服務器性能出問題,排查下這些參數指標

這裡只是一些簡單的工具查看系統的相關參數,當然很多工具也是通過分析加工 /proc、/sys 下的數據來工作的,而那些更加細緻、專業的性能監測和調優,可能還需要更加專業的工具(perf、systemtap 等)和技術才能完成哦。


畢竟來說,系統性能監控本身就是個大學問。



一、CPU和內存類



1.1

top


➜ ~ top

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

第三行 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 使用率過高情況下指明了相應地排查思路:

  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 佔用率過高的時候,黑心廠商虛擬機超售了吧!

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


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


1.2

vmstat


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


說到這裡,想到以前很多人糾結編譯 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: 顯示缺頁錯誤和內存使用狀況,缺頁錯誤是程序需要訪問映射在虛擬內存空間中但是還尚未被加載到物理內存中的一個分頁,缺頁錯誤兩個主要類型是

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

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

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

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


1.4

其他



如果想直接監測某個進程佔用的資源,既可以使用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 還是使用 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

  • active/s:本地發起的 TCP 連接,比如通過 connect(),TCP 的狀態從CLOSED -> SYN-SENT

  • passive/s:由遠程發起的 TCP 連接,比如通過 accept(),TCP 的狀態從LISTEN -> SYN-RCVD

  • retrans/s(tcpRetransSegs):每秒鐘 TCP 重傳數目,通常在網絡質量差,或者服務器過載後丟包的情況下,根據 TCP 的確認重傳機制會發生重傳操作

➜ ~ sudo sar -n UDP 1 

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

當然,這些數據一定程度上可以說明網絡可靠性,但也只有同具體的業務需求場景結合起來才具有意義。


3.3

tcpdump


tcpdump 不得不說是個好東西。大家都知道本地調試的時候喜歡使用 wireshark,但是線上服務端出現問題怎麼弄呢?


下面就是一個小的測試,可見 Chrome 啟動時候自動向 Webserver 發起建立了三條連接,由於這裡限制了 dst port 參數,所以服務端的應答包被過濾掉了,拿下來用 wireshark 打開,SYNC、ACK 建立連接的過程還是很明顯的!在使用 tcpdump 的時候,需要盡可能的配置抓取的過濾條件,一方面便於接下來的分析,二則 tcpdump 開啟後對網卡和系統的性能會有影響,進而會影響到在線業務的性能。

本文完!


原文出處:马哥Linux运维:Linux 服务器性能出问题,排查下这些参数指标
內容圖示
url email imgsrc image code quote
樣本
bold italic underline linethrough   












 [詳情...]
validation picture

注意事項:
預覽不需輸入認證碼,僅真正發送文章時才會檢查驗證碼。
認證碼有效期10分鐘,若輸入資料超過10分鐘,請您備份內容後,重新整理本頁並貼回您的內容,再輸入驗證碼送出。

選項

Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|