在日常性能測試中，我們需要掌握一些常用的策略以及有必要了解和掌握查看服務器性能的命令，來排查診斷服務器性能。

今天，就和大家分享一下在壓測過程中，采用分段排查法快速利用命令去診斷服務器的性能。

Linux服務器分段排查的方法，按照CPU、內存、磁盤IO、網絡的先后順序依次排除。參考流程圖如下：

分析步驟:

Step1 用top查看系統大致情況：

關注cpu(sys+us)使用率，若此值持續大于80%，可以觀察進程視圖，是否是非核心應用進程占用大量CPU資源，若能排除非核心應用進程的影響，則基本能確定該系統cpu資源面臨短缺，此時結合vmstat監控觀察到proc列r值應該較大;同理，當cpu利用率很低，但運行進程隊列(r值)卻很大時，表面cpu存在阻塞

關注%idle(cpu 空閑時間的百分比)，若此值較高但系統響應卻很慢時，有可能是CPU在等待分配內存，此時應關注內存使用情況(見step3);如果空閑時間%idle持續為0并且系統時間(cpu sy)是用戶時間(cpu us)的兩倍 ，系統則面臨著CPU資源的短缺.

關注%wait(cpu等待 IO 的時間的百分比)，在cpu資源尚未耗盡情況下，若此值持續很高表示系統存儲IO可能存在瓶頸;問題原因可能是：(1)系統存在一個應用程序問題(應用本身有許多IO請求);(2)物理內存不足; (3)低效的 I/O 子系統配置; 此時應先排查是否是應用程序問題，然后檢查系統內存使用情況，若是交換分頁多，則確定是由物理內存不足引發的磁盤IO問題(見step3);若不是，則檢查系統磁盤，結合iostat來驗證此現象是由應用IO過多造成(見step4).

Step2 結合vmstat、sar監控cpu：

主要關注報告中的4個cpu列和2個procs(內核線程)列

r：等待在CPU資源的進程數。這個數據比平均負載更加能夠體現CPU負載情況，數據中不包含等待IO的進程。如果這個數值大于系統中的邏輯CPU核數，表示系統現在運行比較慢,有多數的進程等待CPU，那么系統的CPU資源已經飽和。

us, sy, id, wa, st：這些都代表了CPU時間的消耗，它們分別表示用戶時間(user)、系統(內核)時間(sys)、空閑時間(idle)、IO等待時間(wait)和被偷走的時間(stolen，一般被其他虛擬機消耗)。上述這些CPU時間，可以讓我們很快了解CPU是否出于繁忙狀態。一般情況下，如果用戶時間和系統時間相加非常大，CPU出于忙于執行指令。如果IO等待時間很長，那么系統的瓶頸可能在磁盤IO。

sar –P ALL : 對cpu分開查詢，統計每個cpu的使用情況，檢查多個cpu的負載是否平衡

通過前兩步，已能基本確定cpu是否存在瓶頸：

若cpu資源不足，可以調整應用程序對CPU的占用情況，使得應用程序能夠更有效的使用CPU，同時可以考慮增加更多的CPU;

若cpu不是瓶頸，則著重查看系統內存。

Step3 用vmstat查看內存使用情況:

每行會輸出一些系統核心指標，這些指標可以讓我們更詳細的了解系統狀態。后面跟的參數1，表示每秒輸出一次統計信息，參數2，表示一共輸出2次統計信息。表頭提示了每一列的含義，這只介紹一些和內存性能調優相關的列：

Memory區域

swpd：表示切換到內存交換區的內存大小，即虛擬內存已使用的大小(單位KB)，如果大于0，表示你的機器物理內存不足了，如果不是程序內存泄露的原因，那么你該升級內存了或者把耗內存的任務遷移到其他機器。

free：表示當前空閑的物理內存(以千字節為單位), 如果剩余內存不足，也會導致系統性能問題。

buff：表示baffers cached內存大小，也就是緩沖大小，一般對塊設備的讀寫才需要緩沖。

Cache：表示page cached的內存大小，也就是緩存大小，一般作為文件系統進行緩沖，頻繁訪問的文件都會被緩存，如果cache值非常大說明緩存文件比較多，如果此時io中的bi比較小，說明文件系統效率比較好。

Swap區域

si：表示有磁盤調入內存，也就是內存進入內存交換區的內存大小;通俗的講就是 每秒從磁盤讀入虛擬內存的大小，如果這個值大于0，表示物理內存不夠用或者內存泄露了，要查找耗內存進程解決掉。

so：表示由內存進入磁盤，也就是由內存交換區進入內存的內存大小。

注意：一般情況下si、so的值都為0，如果si、so的值長期不為0，則說明系統內存不足，需要增加系統內存。

Step4 用iostat查看磁盤IO

tps：該設備每秒的傳輸次數(Indicate the number of transfers persecond that were issued to the device.)。"一次傳輸"意思是"一次I/O請求"。多個邏輯請求可能會被合并為"一次I/O請求"。"一次傳輸"請求的大小是未知的。

kB_read/s：每秒從設備(drive expressed)讀取的數據量;

kB_wrtn/s：每秒向設備(drive expressed)寫入的數據量;

kB_read：讀取的總數據量;

kB_wrtn：寫入的總數量數據量;這些單位都為Kilobytes

關注%iowait，如果 CPU 和內存受限的情況不存在，并且%iowait 長時間大于25%，則認為IO存在瓶頸。

收集磁盤IO數據吞吐量(iostat –d -k)，大致估計系統數據吞吐量與應用負載是否相匹配，排查是否有與業務無關的大量IO操作。

Step5 使用sar –d 查看磁盤讀寫：

其中：

tps:每秒從物理磁盤I/O的次數.多個邏輯請求會被合并為一個I/O磁盤請求,一次傳輸的大小是不確定的。

rd_sec/s:每秒讀扇區的次數。

wr_sec/s:每秒寫扇區的次數。

avgrq-sz:平均每次設備I/O操作的數據大小(扇區)。

avgqu-sz:磁盤請求隊列的平均長度。

await:從請求磁盤操作到系統完成處理，每次請求的平均消耗時間，包括請求隊列等待時間，單位是毫秒(1秒=1000毫秒)。

svctm:系統處理每次請求的平均時間，不包括在請求隊列中消耗的時間。

%util:I/O請求占CPU的百分比，比率越大，說明越飽和。

正常情況下avserv應該是小于avwait值的, 如果avserv的值與avwait很接近，表示幾乎沒有I/O等待，磁盤性能很好;如果avwait的值遠高于avserv的值，則表示I/O隊列等待太長，系統上運行的應用程序將變慢，磁盤IO為系統瓶頸。

Step6 使用netstat查看網絡：

1、通過ping命令檢測網絡的連通性

2、通過netstat –nltp組合檢測網絡接口狀況

-u (udp)僅顯示udp相關選項

-l 僅列出有在 Listen (監聽) 的服務狀態

-n 拒絕顯示別名，能顯示數字的全部轉化成數字。

-t (tcp)僅顯示tcp相關選項

-p 顯示建立相關鏈接的程序名,

3、通過netstat –r組合檢測系統的路由表信息

總結：

cpu瓶頸常見征兆：

很慢的響應時間

cpu空閑時間為零

過高的用戶占用cpu時間

過高的系統占用cpu時間

長時間的有很長的運行進程隊列

cpu調優方法：

平衡系統負載——在不同的期間運行進程，從而更有效地利用每天的24小時。

使用 nice 或 renice 優化調度程序——可為運行進程分配不同的優先級，以避免占用大量cpu資源。

增加資源——添加更多的cpu

內存瓶頸常見征兆：

很高的換頁率

交換空間使用率很高

進程進入不活動狀態;

交換區所有磁盤的活動次數很高;

很高的全局系統CPU利用率;

內存不夠出錯

內存調優方法：

保證交換空間分配合理(分配足夠多的交換空間、每個交換空間大小相同、每個交換空間分配在不同的硬盤上)

參數調整，調整內存參數閥值

增加內存資源

IO瓶頸常見征兆：

過高的磁盤利用率

太長的磁盤等待隊列

等待磁盤I/O的時間所占的百分率太高

太高的物理I/O速率

過低的緩存命中率

太長的運行進程隊列，但CPU卻空閑

IO調優方法：

一般來說，高的%iowait 表明系統至少存在一個應用程序問題、缺少內存問題或低效的 I/O 子系統配置;

應檢查應用程序產生大量IO請求是否正常;

檢查是否是由于內存交換空間頻繁換頁引起的IO問題;

檢查磁盤配置情況是否合理

針對磁盤IO本身的優化來說，盡管存在一些 I/O 優化參數的虛擬內存等價項，但是提高磁盤 I/O 性能的最佳方法仍然是正確地配置Linux系統，而不僅僅是優化相關的參數。

最后

排查Linux服務器性能問題還有很多工具，上面介紹的一些命令，可以幫助我們快速的定位問題。在以后，實踐工作中，如果你掌握的shell命令多了之后，你就可以根據自己的工作需要，寫一些腳本，去輔助自己的測試工作，例如數據監控、數據收集、數據處理等等，然后和其他工具結合，就可以形成一套解決方案了。

注意：本文旨在學習交流，涉及到部分參數指標可能與實際項目有出入，僅為以后的Linux服務器系統性能分析工作提供參考。