結合「性能監視器」 排查、處理性能瓶頸致使應用吞吐率等指標上不去的問題

本文轉自：blog.zhuliang.ltd/2019/08/ser…，轉載請註明出處。

雙11備戰前夕，總繞不過性能壓測環節，TPS 一直上不去 / 不達標，除了代碼上的問題外，服務器環境、配置、網絡、磁盤、CPU 亦是致使性能瓶頸的重要一環，本文旨在分享最近項目性能壓測過程當中的排查經驗，文中的表單你能夠做爲排查手冊保存，若有不對之處，還請在評論區分享、交流你的經驗和觀點：）

經過本文，你能夠了解和掌握：

• 瞭解常見的系統瓶頸的可能緣由。
• 經過性能探查器定位性能瓶頸。
• 幾點關於性能優化的策略。
• 一份關於 windows 性能監視器的部分計數器翻譯及對應的經驗結論。

吞吐量 和 延時的關係

關於吞吐量/吞吐率、延時，你能夠經過 Jmeter中的」聚合報告「和」用表格查看報告「來獲取。

• Throughput 越大，Latency 越差：由於請求過多，系統繁忙致使響應速度下降。
• Latency 的值越小說明能支持的 Throughput 越高：Latency 數值小說明系統處理速度快，天然即可以處理更多的請求。
• Throughput "不用" 經過下降 latency 的方式來提升，排查性能問題的時候，勿在下降 Latency 值上消耗過多時間。

常見系統瓶頸：

• 類型轉換：除了裝箱拆箱外，還要着重看下 JSON 的一些轉換類庫，如 newtown，fastJson 等等，可能會引發 CPU 維持在高位。
• 異步操做：有些異步操做會很是影響性能，尤爲是在網絡較差的狀況下，極可能阻塞業務。
  • 如異步下的狀態通知一般會影響性能。一般而言，異步操做會讓」吞吐率「提高，但會犧牲 延時（latency）。

定位性能瓶頸

定位的方式不必定是程序級別的，一開始能夠先從操做系統的 CPU 使用率，內存使用率，系統 IO 和 網絡 IO，網絡鏈接數 着手分析。

• CPU 使用率不高，可是 throughtput 和 latency 上不去： 說明程序沒有忙於計算，可能問題在 I/O 上。
  • 通常 CPU 和 IO 是反着來的： CPU 沒問題，問題可能在 IO，反之亦然。
• 若是 CPU、IO、內存、網絡帶寬使用都不高，可是系統性能上不去： 說明程序有問題，多是爲資源被鎖，存在鎖競爭關係，程序被阻塞；或者是在上下文切換等等。
• 關於 IO，要看 3 個方面：磁盤IO，網絡IO 以及 內存換頁率。
• 程序級別的性能瓶頸定位：
  • 分段註釋代碼 / 讓一些函數空轉 / 作一些硬編碼的 Mock，而後再測試下 Throughput 和 latency，看是否有好轉，若是有，說明函數是瓶頸，再進一步在這個函數體內註釋代碼，直到找到最耗性能的語句。
• 分析內存：須要用到的計數器：Memory 類別 和 Physical Disk 類別的計數器，步驟以下：
  1. 查看 Memory：Available Mbytes 指標：若是該指標的數據較小，系統可能出現了內存方面的問題，須要繼續下面步驟進一步分析。
  2. 注意 Memory：Pages/sec、Pages Read/sec 和 Page Faults/sec 的值：操做系統會利用磁盤較好的方式提升系統可用內存量或者提升內存的使用效率。這 3 個指標直接反映了 OS 進行磁盤交換的頻度。
     • Pages/sec 值 持續高於幾百，可能內存有問題。Pages/sec 值大不必定就代表內存有問題，多是運行使用內存映射文件的應用致使。
     • Page Faults/sec 越高說明每秒發生頁面次數越多，說明 OS 向內存讀取的次數越多。此時須要查看 Pages Read/sec 的計數值，該值閾值是 5，超過 5，則能夠判斷存在內存方面的問題。
  3. 根據 Physical Disk 計數器的值分析性能瓶頸：須要分析 Page Reads/sec 和 %Disk Time 及 Average Disk Queue Length 的分析。若是 Pages Read/sec 很低，同時 %Disk Time 和 Average Disk Queue Length 的值很高，則可能有磁盤瓶頸。可是，若是隊列長度增長的同時 Pages Read/sec 並未下降，則是內存不足
• 分析處理器：
  1. 排查 System：%Total Processor Time 計數器的數值：該值體現的是服務器 CPU 的總體利用率，對於多核系統而言，該值體現的是全部 CPU 的平均利用率。
     • 若是該值持續超過 90%，說明整個系統面臨着處理器方面的瓶頸，須要增長處理器來提升性能。
     • P.S.：多核下，若是該數據不大，可是各個 CPU 的 負載不均衡，也能夠認爲是 CPU 產生了瓶頸。
  2. 排查每一個 CPU 的 Processor：%Processor Time 和 %User Time 和 %Privileged Time：
     • %Processor Time 很高時，通常 CPU 都阻塞着，可是反之並不亦然。
     • %User Time：非系統內核操做消耗的 CPU 時間（如調用系統自己資源--網絡、IO等），若該值較大，能夠考慮優化代碼、優化算法；若是該服務器是數據庫 Server，則該值較大的話多是數據庫的」排序「或是」函數操做「消耗了過多的 CPU 時間，此時可考慮對 DB 進行優化。
     • %Privileged Time：系統內核操做消耗的 CPU 時間
  3. 驗證是否系統 CPU 瓶頸：
     • 查看 System：Processor Queue Length 計數器：若是該值大於 CPU 數量的總數 + 1 的時候，說明產生了處理器阻塞。
• 分析磁盤I/O：
  1. 若是計算得出每一個磁盤的I/O 超過了磁盤自己的I/O能力，則能夠確認磁盤是引發瓶頸的因素之一。
  2. 與 Processor：%Privileged Time 聯合分析：若是 Physical Disk：%Disk Time 較大，其餘值比較適中，則硬盤多是瓶頸，若幾個值都比較大，且持續超過 80%，則多是內存泄漏。
  3. 分析 Disk sec/Transfer：通常來講，該值小於 15ms 爲最佳，15~30ms 爲良好，30~60ms 爲可接受，超過 60ms 則須要考慮更換硬盤或者更換 raid 方式了。
• 分析進程：
  • 查看 Process：%Processor Time的值：每一個進程的該值反映的是進程消耗 CPU 的時間。
  • 查看 Process：%Page Failures/sec 和 Memory：%Page Failures/sec 的比值，過濾出是哪一個進程產生的最多的頁錯誤，通常這個進程是須要大量內存的進程，或者是很是活躍的進程（即在壓測狀況下，就是你要壓測的進程）
  • Process：%Private Bytes：該計數器指進程所佔有的私有數據（單位字節），即沒法與其餘進程共享的數據量，能夠利用該值來判斷應用是否存在內存泄漏。
    • 對於 IIS 進程，能夠重點監控下 INetInfo進程的 Private Bytes，若是在壓測過程當中，該值不斷增長，或是在壓測結束後，該值仍然處於一個高水平，則說明應用存在內存泄漏
• 分析網絡：
  • Network Interface：Bytes Total/sec 爲發送和接收字節的速率，能夠經過該計數器值來判斷網絡連接速度是不是瓶頸，具體操做方法是用該計數器的值和目前網絡的帶寬進行比較。
  • 聯合 Processor：%Privileged Time 進行分析：若是 Physical Disk：%Disk Time比較大，其餘值比較適中，則硬盤多是瓶頸，若幾個值都比較大，且持續超過 80%，則可能存在內存泄漏。

性能優化的幾個策略

• 應用層面：
  • 善用 CDN，緩存，冗餘數據，SLB。
  • 若是瓶頸在網絡傳輸，那麼須要對傳輸數據進行壓縮（須要注意，壓縮算法是很耗時的，只在瓶頸是網絡傳輸的時候再考慮，你須要根據測試數據自行權衡。）。
  • 並行處理的時候須要注意下宿主機是不是多核。若是宿主機是單核的，而程序代碼是多進程、多線程的，那麼對於高計算密集型的應用會拔苗助長，反而更慢。
• 優化代碼：
  • 減小循環層數、減小遞歸。
  • 在循環體中少作聲明變量、分配 / 釋放內存的操做：把循環體內的表達式抽離到循環體外。
  • 注意函數調用在棧上的開銷。
  • 合理使用 try-catch：不要用拋異常做爲常規業務的失敗流程（如進行業務報錯）。
  • 字符串處理需注意：減小沒必要要的聲明實例（.net core 出了一個 Span 類型，能夠用來替代 Substring。）
  • 不一樣的語言和代碼庫，對於複雜度是不同的，這個須要注意：如應該用 List.Count==0 來代替List.Any() 來判斷是否有數據。
    • 關於這點，你可使用計數器來判斷、測試本身寫的代碼在」耗時、Cpu Cycle，0/1/2代 GC回收「等數據的差別，擇優而定。
• 算法調優：
  • 哈希算法並不高效，使用時候還需注意。
  • 善用預處理和份量分次分批處理：像月報表之類的執行頻率低，但每次執行都很耗資源的，你能夠嘗試預先天天/每週處理，不用等到每個月才執行。
• 多線程調優：
  • 多線程的瓶頸主要在互斥和同步鎖上，以及線程上下文切換的成本上：你應儘可能少用甚至不用鎖，或者用樂觀鎖替代現有直接用 Lock 的鎖。
• 內存分配：當內存出現碎片時，會至關耗時。
  • 在編碼的時候，意識上儘量少的進行內存的分配。
• 池化技術對於一些短做業來講至關有效：如 HttpClientFactory 就是用了 http 池，能夠用來減小對象建立、線程建立的開銷。
• 網絡調優：
  • TCP 很耗資源，對系統開銷很大：你能夠搜索關鍵字：TCP Tuning 進行相關調優
  • TCP 和 HTTP 要配置下 Keep-Alive，尤爲是像 http 這樣的短鏈接，這也能夠在必定程度上防止 DDoS攻擊。
  • 對於 TCP 的 TIME_WAIT，這個狀態默認會持續 4 分鐘（持續 2 個 MSL--Max Segment Lifetime），TIME_WAIT 狀態下的資源不能回收，有大量 TIME_WAIT 鏈接的狀況通常是在 HTTP 服務器上。
    • 你能夠在註冊表中新建、設置 TCP 的 TcpTimedWaitDelay 和 MaxUserPort 項，來增長 TCP 鏈接釋放時間和臨時端口數。
  • TCP 一旦發生丟包，TCP 的帶寬使用率會受到影響（盲目減半），再丟包，再減半；何時不丟包了，就會逐步恢復。
• CPU 調優：
  • CPU0 很關鍵， 它通常擔任着調節功能（如內核和非內核操做，上下文切換等），若是 0 號 CPU 被用得過狠的話，別的 CPU 性能也會降低。
    • windows 下可在「任務管理器」中，右鍵「進程」選擇「設置相關性」來設置該進程能夠運行在哪些核上。

      • 

    • linux：使用 taskset 命令來設置（能夠經過安裝 schedutils 來安裝這個命令） 。

性能監視器

在服務器上最直觀監視性能的方式就是直接使用系統自帶的」性能監視器「。

>perfmon #直接在 "運行" 中輸入 perfmon 便可打開
複製代碼

• 若要進一步監控內存，可結合使用 RAMMap 和 VMMap 。

windows 下計數器說明：

類別	計數器名稱	描述	結論
Memory	Available M bytes	當前空閒物理內存。	當這個數值變小時，說明 windows 開始頻繁地調用磁盤頁面文件，若是這個數值很小（如小於 5Mb，系統會將大部分時間消耗在操做頁面文件上），通常要保留 10% 的可用內存，此值太小多是內存不足或者內存泄漏。
	Pages/sec	是 Pages Input/sec 和 Pages Output/sec 總和。	Pages/sec 推薦 0-20，若是服務器沒有足夠的內存處理其工做符合，此值數值將會一直很高，若是大於 80 ，表示有問題（太多的讀寫數據要訪問磁盤，可考慮增長內存或優化讀寫數據的算法），該系列的值比較低，說明請求響應比較快，不然多是服務器內存短缺引發（也多是緩存太大，致使系統內存太少。）通常若是Pages/sec 持續高於幾百，那麼應該進一步研究頁交換活動。有可能須要增長內存，以減小換頁的需求。Pages/sec 的值很大不必定代表內存有問題，而多是運行使用內存映射文件的程序所致。計數器的比率高表示分頁過多。
	Pages Read/sec	讀取磁盤，以提取解決頁錯誤所需頁的次數。	其閾值爲 5，該值越低越好（越低，說明響應時間越短）；該值大表示磁盤讀，而非緩存讀。 若是 Page Reads/sec 持續保持爲 5，表示可能內存不足。
	Page Faults/sec	該值表示頁錯誤的個數： 當處理器向內存指定位置請求一頁（多是數據，也多是代碼）出現錯誤時，這就構成了一個「頁錯誤」。若是該頁在內存的其餘位置，該錯誤就被稱爲軟錯誤（用 Transition Fault/sec衡量）；若是該頁必須從硬盤上從新讀取時，被稱爲硬錯誤。	許多處理器能夠在有大量軟錯誤的狀況下繼續操做，而硬錯誤會致使明顯的拖延。當進程使用的數據所處的內存頁不在內存中時，就會產生該值。若是某頁已經在主內存中，或者它正被共享此頁的其餘進程使用，那麼就不會從磁盤調入該頁。
	Cache Bytes	分配在RAM中的駐留頁面數。	默認狀況下爲 50% 的可用內存。
	Committed Bytes	指以字節表示的確認虛擬內存，是磁盤頁面文件上保留空間的物理內存。	不超過物理內存的 75% 。
Process	%Processor Time	處理器消耗的處理器時間，若是專用於某種特定應用（如數據庫服務器和應用服務器），則可用應用相關進程 %Process Time 進行衡量。	可接受的上限通常不超過 85% 。
	Page Faults/sec	將進程產生的頁故障與系統產生的相比較，以判斷該進程對系統頁故障產生的影響。
	Working Set	表示進程正在使用的物理內存的量。（至因而具體進程仍是全部進程，須要看監控實例是具體的仍是全部的。）	系統在工做集中的內存頁進行尋址的時候，不會引起 Page Fault。另外，若是服務器有足夠的空閒內存，頁就會留在工做集中，而當空閒內存少於一個特定的閾值時，頁就會被清除出工做集中。
	Private Bytes	此進程所分配的沒法與其餘進程共享的當前字節數量。若是系統性能隨着時間而下降，則此計數器能夠是內存泄漏的最佳指示器。
Processor	%Processor Time	指處理器執行非閒置線程時間的百分比。此計數器能夠做爲處理器活動的主要指示器。（%Processor Time = 100% - Idle Process時間比例）	若是該值持續超過95%，代表瓶頸是 CPU，能夠考慮增長或更換更快的處理器。正常狀況下，保持在 80%±5% 比較好，太低說明 CPU 利用率不高，太高表示是瓶頸是 CPU。雖然該計數器高不必定是壞事，但若是其餘處理器相關的計數器（如 Privileged Time 或者 Processor Queue Length）線性增長的話，高 CPU 使用率就值得調查了。
	%User Time	非內核操做耗費的CPU時間。通常來講，若是系統中使用了大量的算法或者複雜的計算操做，該值就會比較大。
	%Privileged Time	這個計數器表示一個線程在特權模式下所使用的時間比例，當你的程序調用操做系統的方法（如文件操做，I/O 或者分配內存）時，這些操做系統的方法就是在特權模式下運行的。	若是數值持續大於 75% 就表示存在瓶頸。
	%DPC Time	CPU 消耗在網絡處理上的時間。	該值越小越好。若是持續高 %DPC 時間，則可能存在 CPU 瓶頸或應用程序或硬件相關問題。
	%Interrupt Time	表示 CPU 接收、處理硬件中斷所使用的時間比例。	閾值取決於處理器。通常，當該值 >15% 的時候說明可能存在硬件問題。 這個值間接指出產生中斷的硬件設備活動，好比網絡變化。這個計數器顯著增長的話表示硬件可能存在問題
	Interrupts/sec	中斷率，表示每秒設備中斷 CPU 的次數，能夠產生中斷的裝置包括：系統定時器，鼠標，數據通信聯網，網絡卡以及其餘外部設備等。中斷操做在後臺完成。	該值閾值取決於處理器，但越低越好，不宜超過 1000，若是該值顯著增長而系統活動沒有相應的增長，則代表存在硬件問題，須要檢查引發中斷的網絡適配器、磁盤或其餘硬件。
Physical Disk	%Disk Time	指所選磁盤驅動器忙於讀/寫入請求所用的時間百分比。	正常值<10，此值過大表示耗費太多時間來訪問磁盤，可考慮增長內存、更換更快的硬盤、優化讀寫數據的算法。若數值持續超過 80（此時處理器和網絡並無飽和），則多是內存泄漏。
	Current Disk Queue Length	是在收集性能數據時磁盤上當前的請求數量。它還包括在收集時處於服務的請求。這是瞬態的快照，不是時間間隔的平均值。此計數器會反映暫時的高或低的隊列長度，可是若是磁盤驅動器被迫持續運行，它有可能一直處於高的狀態。	請求的延遲與此隊列的長度減去磁盤的軸數成正比。爲了提升性能，此差應該平均小於 2。
	Average Disk Queue Length	指讀取和寫入請求的平均數。該值不該超過磁盤數的 1.5~2倍。要提升性能，可增長磁盤。注意，一個Raid Disk 實際有多個磁盤。	正常值應小於 5，此值持續過大表示磁盤 IO 太慢，要更換更快的硬盤。建議結合 Pages /sec 一塊兒分析，看是內存分頁過多致使磁盤一直在讀寫仍是就是磁盤問題。
	Average Disk Read/Write Queue Length	指讀取/寫入請求（隊列）的平均數。
	DiskRead(Writes)/sec	物理磁盤上每秒磁盤讀、寫的次數。	二者相加，應該小於磁盤設備最大容量。
	Average Disk sec/Read	指以秒計算的在磁盤上讀取數據所需的平均時間。
	Average Disk sec/Write	指以秒計算的在磁盤上寫入數據所需的平均時間。
Network Interface	Bytes Total/sec	爲發送和接受字節的速率，包括幀字符在內。判斷網絡鏈接速度是不是瓶頸，能夠用該計數器的值和目前網絡的帶寬比較。	建議不要超過帶寬的 50% 。
System	%Total Processor Time	系統上全部處理器都忙於執行非空閒線程的平均時間的百分比，該值反映了用於有用做業上的時間的比率。對單處理器系統來講，該值很容易理解；對多處理器來上，該值體現了全部處理器的平均繁忙程度。eg：若是全部處理器都繁忙，此值爲 100%，若是有一半的處理器繁忙，另外一半處理器徹底空閒，此值爲 50%。
	File Data Operation/sec	計算機對文件系統設備執行讀取和寫入操做的速率。本計數器的計數不包括文件控制文件。
	Processor Queue Length	處理器隊列的線程數量，該計數器顯示的是等待中的線程數量，不包括正在運行的線程數量。	在 CPU 利用率 80~90% 的系統中，該值應爲 "[1,3] * 處理器數量"：如在一臺 8 核處理器，該值在 [8, 24] 區間範圍內算正常；而在 CPU 利用率較低的系統上，該值應爲 [0,1]，若持續大於 2，就有可能碰到了問題資源，須要進一步排查。
	Call/sec	指運行在計算機上的全部處理器調用操做系統服務例行程序的綜合速率，這些例行程序執行全部在計算機上的如安排和同步活動等基本的程序，並提供對非圖形設備、內存管理和名稱空間管理的訪問。	該值跟 Processor.Interrupts/sec 聯合使用，若是 Processor.Interrupts/sec 大於 Call/sec，則說明系統中某一硬件產生了過多的終端。
	Context Switches/sec	進程切換率，指計算機上的全部處理器所有從一個線程切換到另外一個線程的綜合速率。產生上下文的可能狀況：當正在運行的線程自動放棄處理器時出現上下文切換；一個有更高優先級的線程取代一個正在運行的低優先級線程的時候會發生上下文切換；在用戶模式和內核模式之間切換時產生上下文切換。	通常，該值小於 5000/秒/CPU 是不須要擔憂的。若是Context 該值達到 15000/秒/CPU 的話就是一個制約因素了，須要看下是否代碼致使（如過多的異步操做）。P.S.：上下文切換一樣會發生在許多線程擁有相同優先級的狀況，若是 CPU 使用率不高且 Context Swtich 很是低，那麼可能線程被堵塞。
Web Service	Current Connections	當前鏈接數（針對到 IIS 實例）。	結合壓測用戶/線程數進行分析。
	Current Anonymous Users	當前匿名鏈接數。	結合壓測用戶/線程數進行分析。
	Current NonAnonymous Users	當前非匿名用戶/匿名鏈接數。	結合壓測用戶/線程數進行分析。
	Get/Put/Post Requests/sec	使用Get/Put/Post 方式 HTTP 請求的速率。

參考

• Processor queue length：social.msdn.microsoft.com/Forums/vstu…

• Interrupt Time 說明：docs.microsoft.com/en-us/previ…

• 性能計數器：www.appadmintools.com/documents/w…