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

• 2019 年 10 月 3 日
• 筆記

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

原文地址（樣式排版上更好點） ：https://blog.zhuliang.ltd/2019/08/Performance/test-with-perfmon.html

通過本文，你可以了解和掌握：

• 了解常見的系統瓶頸的可能原因。
• 通過性能探查器定位性能瓶頸。
• 幾點關於性能優化的策略。
• 一份關於 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 下計數器說明：

參考

• 提高 IIS/P2P 並發數，請參見：(通過設置註冊表提高 P2P/IIS 並發數)[https://blog.zhuliang.ltd/2019/09/Performance/tcpip-max-limit.html]

• Processor queue length：https://social.msdn.microsoft.com/Forums/vstudio/en-US/356b87a3-e8b1-48ad-9355-e68ce3eef754/processor-queue-length?forum=vstest

• Interrupt Time 說明：https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc718984(v=msdn.10)

• 性能計數器：http://www.appadmintools.com/documents/windows-performance-counters-explained/