性能瓶頸分析思路

時間 2019-11-29

標籤性能瓶頸分析思路欄目系統性能简体版

原文原文鏈接

性能瓶頸分析思路

性能分析是一個大課題，不一樣的架構、不一樣的應用場景、不一樣的程序語言分析的方法各有差別，抽象一下大體分爲二類：linux

自底向上：經過監控硬件及操做系統性能指標（CPU、內存、磁盤、網絡等硬件資源的性能指標）來分析性能問題（配置、程序等的問題）。由於用戶請求最終是由計算機硬件設備來完成的，作事的是 CPU。ios

自頂向下：經過生成負載來觀察被測試的系統性能，好比響應時間、吞吐量；而後從請求起點由外及裏一層一層的分析，從而找到性能問題所在。算法

不論是自底向上仍是自頂向下，關鍵點就是生成負載、監控性能指標。上面咱們說了兩種方法，你們會問哪種方法更好呢？哪一種方法更簡單一點呢？我想說的是方法無所謂好壞，只是一個思路。數據庫

對於沒有經驗的性能測試工做者，提倡自底向上；對於經驗豐富的性能測試工做者，先用自頂向下的方式解決掉明顯性能問題，再接合自底向上的方式分析更深層次的問題。apache

性能分析流程

從性能測試工程師的角度來說解一下一般的性能分析過程（操做系統以Linux爲例）。緩存

序號 tomcat	步驟名稱服務器	說明網絡
1.0架構	檢查RT	模擬用戶發起負載後，採用自頂向下的方式首先分析RT（響應時間）。 1.若是RT小，TPS大，說明性能良好。 2.若是RT小，TPS小，檢查負載機資源佔用狀況，肯定是否要加大負載。 3.若是RT大，TPS小，檢查負載機的資源消耗，確保不是負載機的性能緣由致使的RT變大。
1.1	檢查TPS	1.TPS大時RT小，說明性能良好 2.TPS小時RT大，檢查負載機的資源消耗，確保不是負載機的性能緣由致使的RT變大。
2.0	檢查負載機資源消耗耗	1.檢查CPU使用率，CPU負載（LoadAverage）確認是用戶CPU佔用高仍是系統CPU佔用高？確認測試腳本沒有性能問題，不會形成結果統計的不許確 2.檢查內存使用狀況，確認併發內存泄露風險，不會形成結果統計的不許確。 3.檢查網絡佔用帶寬。你們能夠作個小實驗，一臺併發100用戶，一臺運行一個用戶，比較二者的響應時間是否在同一個數量級，從而評估負載機對性能的影響。
2.1	判下負載機是否有性能問題	排除負載機的性能問題，確保測試結果可參考。
3.0	檢查Web 服務器的資源消耗	1.檢查CPU使用率，確認用戶CPU與系統CPU佔用狀況 1.1系統CPU佔用多，檢查系統調用狀況，找出是哪一個進程或線程，確認調用是否正常？好比濫寫日誌，致使系統CPU利用率高。 1.2用戶CPU高，找出進程或線程，定位到程序，確認是否調用正常？通常來講Web服務程序不涉及到運算的，CPU利用率高要確認是不是其它資源等待致使的CPU利用率高。 1.2.1好比IO等待會帶來CPU利用率高，CPU因爲等待IO，而頻繁的進行上下文切換。 1.2.2好比事務過程較長，須要鎖定的資源較多，而請求也較多時，CPU須要不停的中斷、上下文切換去處理獲取到資源的請求。 2.檢查內存使用狀況，找出佔內存多的進程或線程 3.檢查磁盤使用狀況，找出IO量大的進程或線程 4.檢查佔用的帶寬 5.分析Web頁面響應的時間組成
3.1	確認是否 Web服務器瓶頸	從3.0監控指標判斷是不是Web服務器硬件性能瓶頸。
3.2	檢查中間件配置	1.檢查中間件線程池活動鏈接數，確認是不是此配置問題。 2.檢查Heap配置，確認gc的影響。
3.3	是不是中間件限制	1.監控線程池活動鏈接數，確認線程池夠用。 2.監控線程狀態，若是長期是Blocked狀態，多是響應慢，有可能會致使死鎖，Dump線程棧找到疑問程序。 3.監控JVM，關注GC，評估Heap空間是否夠用。
4.0	檢查APP 服務器資源消耗	分析方法同3.0。
4.1	確認是否 App服務器瓶頸	從3.0監控指標判斷是不是App服務器硬件性能瓶頸
4.2	檢查中間件配置	1.檢查中間件線程池。 2.檢查數據庫鏈接池。 3.檢查Heap配置。
4.3	是不是中間件限制	1.監控線程池，確認線程池夠用。 2.監控線程狀態，若是長期是Blocked狀態，表明響應慢，有可能會致使死鎖。 3.監控與數據庫的鏈接數，確認數據庫鏈接池是否夠用。 4.監控JVM，關注GC，評估Heap空間是否夠用。能夠藉助JVisualVM、 Jprofiler來分析，也可使用Jdk自帶的監控命令。
5.0	數據庫服務器資源消耗分析	1.CPU消耗，CPU負載。 2.內存消耗。 3.IO繁忙程度。 4.數據庫監控 4.1慢查詢。 4.2對DB不熟悉的讀者能夠找DBA幫忙監控分析。
5.1	是不是DB 性能問題	由5.0的監控結果來判斷是不是DB性能問題。

linux主機瓶頸閥值分析

CPU定位分析

模塊

類型

度量方法

衡量標準

CPU

使用

狀況

經過vmstat 統計1-id 的計數
經過top統計1-id的計數

注意>=50% 告警>=70% 嚴重>=90%

CPU

滿載

vmstat 的r計數 > CPU邏輯顆數
top, "load average" > CPU邏輯顆數

運行的隊列大於cpu邏輯顆數時，證實已經有必定的負載了，不過這個計數也不絕對，需進一步分析其餘的資源狀況來判定是否

CPU已經滿負荷運做

咱們能夠用的命令有vmstat， top ,sar，dstat， mpstat, ps 等命令來進行統計分析。

vmstat 字段含義說明：

類別	項目	含義	說明
Procs（進程）	r	等待執行的任務數	展現了正在執行和等待cpu資源的任務個數。當這個值超過了cpu個數，就會出現cpu瓶頸。
Procs（進程）	B	等待IO的進程數量
Memory(內存)	swpd	正在使用虛擬的內存大小，單位k
	free	空閒內存大小
	buff	已用的buff大小，對塊設備的讀寫進行緩衝
	cache	已用的cache大小，文件系統的cache
Swap	si	每秒從交換區寫入內存的大小（單位：kb/s）
Swap	so	每秒從內存寫到交換區的大小
IO	bi	每秒讀取的塊數（讀磁盤）	如今的Linux版本塊的大小爲1024bytes
IO	bo	每秒寫入的塊數（寫磁盤）
system	in	每秒中斷數，包括時鐘中斷	這兩個值越大，會看到由內核消耗的cpu時間會越多
system	cs	每秒上下文切換數	這兩個值越大，會看到由內核消耗的cpu時間會越多
CPU（以百分比表示）	Us	用戶進程執行消耗cpu時間(user time)	us的值比較高時，說明用戶進程消耗的cpu時間多，可是若是長期超過50%的使用，那麼咱們就該考慮優化程序算法或其餘措施了
	Sy	系統進程消耗cpu時間(system time)	sys的值太高時，說明系統內核消耗的cpu資源多，這個不是良性的表現，咱們應該檢查緣由。
	Id	空閒時間(包括IO等待時間)
	wa	等待IO時間	Wa太高時，說明io等待比較嚴重，這多是因爲磁盤大量隨機訪問形成的，也有多是磁盤的帶寬出現瓶頸。

內存定位分析

模塊	類型	度量方法	衡量標準
內存	使用狀況	free命令查看使用狀況 vmstat命令查看使用狀況	注意>=50% 告警>=70% 嚴重>=80%
內存	滿載	vmstat 的 si/so 比例輔助 swapd和free利用 sar –W 查看次缺頁數查看內核日誌有無 OOM 機制 kill進程 dmesg \| grep killed	OOM機制

咱們能夠用的命令有 vmstat，sar，dstat， free, top , ps 等命令來進行統計分析。

free 字段含義說明：

參數	釋義
total	內存總數，物理內存總數
used	已經使用的內存數
free	空閒的內存數
shared	多個進程共享的內存總額
buffers/cache	緩存內存數
available	可用內存數
Swap	交換分區，虛擬內存

網絡定位分析

模塊	類型	度量方法	衡量標準
網絡	使用狀況	ifstat 的收發計數大於網卡上限 iftop RX/TX帶寬超過網卡上限 nicstat的 util 基本滿負荷
網絡	滿載	ifconfig dropped 有計數 netstat –s "segments retransmited"有計數	統計的丟包有計數證實已經滿了
網絡	錯誤	ifconfig, "errors" netstat -i, "RX-ERR"/"TX-ERR"	錯誤有計數

衡量系統網絡的使用狀況，咱們可使用的命令有ifstat,iftop,netstat以及查看net的速率，經過查看發現收發包的吞吐速率達到網卡的最大上限，網絡數據報文有由於這類緣由而引起的丟包

阻塞等都證實當前網絡可能存在瓶頸。在進行性能測試時爲了減少網絡的影響，通常咱們都是在局域網中進行測試執行。

nicstat命令詳解

磁盤IO定位分析

模塊	類型	度量方法	衡量標準
IO	使用狀況	iostat –xz , "%util" iotop 的利用率很高	注意>=40% 告警>=60% 嚴重>=80%
IO	滿載	iostat -xnz 1, "avgqu-sz" >1 iostat await > 70	IO 已經有滿載嫌疑
IO	錯誤	dmesg 查看io 錯誤 smartctl /dev/sda	有信息

衡量系統IO的使用狀況，咱們可使用的命令有sar, iostat,iotop等命令進行系統級的IO監控分析。當發現IO的利用率大於40%時候，就須要注意了，當使用率大於60%則處於告警階段，大於80%IO就會出現阻塞了。

iostat -x命令詳解

選項	說明
rrqm/s	每秒對該設備的讀請求被合併次數，文件系統會對讀取同塊(block)的請求進行合併
wrqm/s	每秒對該設備的寫請求被合併次數
r/s	每秒完成的讀次數
w/s	每秒完成的寫次數
rkB/s	每秒讀數據量(kB爲單位)
wkB/s	每秒寫數據量(kB爲單位)
avgrq-sz	平均每次IO操做的數據量(扇區數爲單位)
avgqu-sz	平均等待處理的IO請求隊列長度
await	平均每次IO請求等待時間(包括等待時間和處理時間，毫秒爲單位)
svctm	平均每次IO請求的處理時間(毫秒爲單位)
%util	採用週期內用於IO操做的時間比率，即IO隊列非空的時間比率

tomcat 性能監控和分析

鏈接器（Connector）的參數配置

HTTP/1.1：默認值，使用的協議與Tomcat版本有關
org.apache.coyote.http11.Http11Protocol：BIO
org.apache.coyote.http11.Http11NioProtocol：NIO
org.apache.coyote.http11.Http11Nio2Protocol：NIO2
org.apache.coyote.http11.Http11AprProtocol：APR

Attribute	描述
maxConnections	服務器在任何給定時間接受和處理的最大鏈接數。當達到這個數字時，服務器將接受一個進一步的鏈接，但不會處理。這個附加鏈接將被阻塞，直到正在處理的鏈接數降到maxConnections如下，服務器再次開始接受並從新處理新的鏈接。
acceptCount	全部可能的請求處理線程正在使用時，傳入鏈接請求的最大隊列長度。當隊列滿時收到的任何請求都將被拒絕。默認值爲100。
connectionTimeout	鏈接器在接受鏈接後等待的請求URI行的毫秒數。使用值-1表示無（即無窮大）超時。默認值爲60000（即60秒），但請注意Tomcat附帶的標準server.xml將其設置爲20000（即20秒）。除非disableUploadTimeout設置爲false，不然讀取請求主體（若是有的話）也將使用此超時。
keepAliveTimeout	鏈接器在關閉鏈接以前等待另外一個HTTP請求的毫秒數。默認值是使用爲connectionTimeout屬性設置的值。使用值-1表示無（即無窮大）超時。
maxKeepAliveRequests	在服務器關閉鏈接以前能夠進行流水線處理的最大HTTP請求數。將此屬性設置爲1將禁用HTTP / 1.0保持活動狀態，以及HTTP / 1.1保持活動狀態和流水線狀態。將其設置爲-1將容許無限量的流水線或保持活動的HTTP請求。若是未指定，則此屬性設置爲100。
executor	對Executor元素中的名稱的引用。若是設置了此屬性，而且命名的執行程序存在，則鏈接器將使用執行程序，而且全部其餘線程屬性將被忽略。請注意，若是未爲鏈接器指定共享執行程序，則鏈接器將使用專用的內部執行程序來提供線程池。