系統架構性能優化思路

今天談下業務系統性能問題分析診斷和性能優化方面的內容。這篇文章重點還是談已經上線的業務系統後續出現性能問題後的問題診斷和優化重點。

系統性能問題分析流程

我們首先來分析下如果一個業務系統上線前沒有性能問題，而在上線後出現了比較嚴重的性能問題，那麼實際上潛在的場景主要來自於以下幾個方面。

正是由於這個原因，當我們發現性能問題的時候，首先就需要判斷是單用戶非併發狀態下本身就有性能問題，還是說在併發狀態才存在性能問題。對於單用戶性能問題往往比較容易測試和驗證，對於併發性能問題我們可以在測試環境進行加壓測試和驗證，以判斷併發下的性能。

如果是單用戶本身就存在性能問題，那麼大部分問題都出在程序代碼和 SQL 需要進一步優化上面。如果是併發性能問題，我們就需要進一步分析數據庫和中間件本身的狀態，看是否需要對中間件進行性能調優。

在加壓測試過程中，我們還需要對 CPU，內存和 JVM 進行監控，觀察是否存在類似內存泄漏無法釋放等情況，即併發下性能問題本身也可能是代碼本身原因導致性能異常。

性能問題影響因素分析

對於性能問題影響因素，簡單來說包括了硬件環境，軟件運行環境和軟件程序三個方面的主要內容。下面分別再展開說明下。

硬件環境

硬件環境就是我們常說的計算，存儲和網絡資源。

對於服務器的計算能力，一般來說廠家都會提供 TPMC 參數作爲一個參考數據，但是我們實際看到相同 TPMC 能力下的 X86 服務器能力仍然低於小型機的能力。

除了服務器的計算能力參數，另外一個重點就是我們說的存儲設備，影響到存儲的重點又是 IO 讀寫性能問題。有時候我們監控發現 CPU 和內存居高不下，而真正的瓶頸通過分析反而發現是由於 IO 瓶頸導致，由於讀寫性能跟不上，導致大量數據無法快速持久化並釋放內存資源。

比如在 Linux 環境下，本身也提供了性能監控工具方便進行性能分析。比如常用的 iostat,ps,sar,top,vmstat 等，這些工具可以對 CPU，內存，JVM，磁盤 IO 等進行性能監控和分析，以發現真正的性能問題在哪裏。

比如我們常說的內存使用率持續告警，你就必須發現是高併發調用導致，還是 JVM 內存泄漏導致，還是本身由於磁盤 IO 瓶頸導致。

對於 CPU，內存，磁盤 IO 性能監控和分析的一個思路可以參考：

運行環境 - 數據庫和應用中間件

數據庫和應用中間件性能調優是另外一個經常出現性能問題的地方。

數據庫性能調優

拿 Oracle 數據庫來說，影響數據庫性能的因素包括：系統、數據庫、網絡。數據庫的優化包括：優化數據庫磁盤 I/O、優化回滾段、優化 Rrdo 日誌、優化系統全局區、優化數據庫對象。

要調整首先就需要對數據庫性能進行監控

我們可以在 init.ora 參數文件中設置 TIMED_STATISTICS=TRUE 和在你的會話層設置 ALTER SESSION SET STATISTICS=TRUE 。運行 svrmgrl 用 connect internal 註冊，在你的應用系統正常活動期間，運行 utlbstat.sql 開始統計系統活動，達到一定的時間後，執行 utlestat.sql 停止統計。統計結果將產生在 report.txt 文件中。

數據庫性能優化應該是一個持續性的工作，一個方面是本身的性能和參數巡檢，另外一個方面就是 DBA 也會經常提取最佔用內存的低效 SQL 語句給開發人員進一步分析，同時也會從數據庫本身的以下告警 KPI 指標中發現問題。

比如我們可能會發現 Oracle 數據庫出現內存使用率高的告警，而通過檢查會發現是產生了大量的 Redo 日誌導致，那麼我們就需要從程序上進一步分析爲何會產生如此多的回滾。

應用中間件性能分析和調優

應用中間件容器即我們常說的 Weblogic, Tomcat 等應用中間件容器或 Web 容器。應用中間件調優一個方面是本身的配置參數優化設置，一個方面就是 JVM 內存啓動參數調優。

對於應用中間件本身的參數設置，主要包括了 JVM 啓動參數設置，線程池設置，連接數的最小最大值設置等。如果是集羣環境，還涉及到集羣相關的配置調優。

對於 JVM 啓動參數調優，往往也是應用中間件調優的一個關鍵點，但是一般 JVM 參數調優會結合應用程序一起進行分析。

比如我們常見的 JVM 堆內存溢出，如果程序代碼沒有內存泄漏問題的話，我就需要考慮調整 JVM 啓動時候堆內存設置。在 32 位操作系統下只能夠設置到 4G，但是在 64 位操作系統下已經可以設置到 8G 甚至更大的值。

其中 JVM 啓動的主要控制參數說明如下:

-Xmx  #設置最大堆空間
-Xms  #設置最小堆空間
-XX:MaxNewSize #設置最大新生代空間
-XX:NewSize    #設置最小新生代空間
-XX:MaxPermSize  #設置最大永久代空間(注：新內存模型已經替換爲Metaspace)
-XX:PermSize     #設置最小永久代空間(注：新內存模型已經替換爲Metaspace)
-Xss   #設置每個線程的堆棧大小

那麼這些值究竟設置多大合適，具體來講：

Java 整個堆大小設置，Xmx 和 Xms 設置爲老年代存活對象的 3-4 倍，即 FullGC 之後的老年代內存佔用的 3-4 倍。永久代 PermSize 和 MaxPermSize 設置爲老年代存活對象的 1.2-1.5 倍。

年輕代 Xmn 的設置爲老年代存活對象的 1-1.5 倍。

老年代的內存大小設置爲老年代存活對象的 2-3 倍。

注意在新的 JVM 內存模型下已經沒有 PermSize 而是變化爲 Metaspace，因此需要考慮 Heap 內存和 Metaspace 大小的配比，同時還需要考慮相關的垃圾回收機制是採用哪種類型等。

對於 JVM 內存溢出問題，我前面寫過一篇專門的分析文章可以參考。

從表象到根源 - 一個軟件系統 JVM 內存溢出問題分析解決全過程‍

軟件程序性能問題分析

在這裏首先要強調的一點就是，當我們發現性能問題後首先想到的就是擴展資源，但是大部分的性能問題本身並不是資源能力不夠導致，而是我們程序實現上出現明顯缺陷。

比如我們經常看到的大量循環創建連接，資源使用了不釋放，SQL 語句低效執行等。

爲了解決這些性能問題，最好的方法仍然是在事前控制。其中包括了事前的代碼靜態檢查工具的使用，也包括了開發團隊對代碼進行的 Code Review 來發現性能問題。

所有已知的問題都必須形成開發團隊的開發規範要求，避免重複再犯。

業務系統性能問題擴展思考

對於業務系統的性能優化，除了上面談到的標準分析流程和分析要素外，再談下其它一些性能問題引發的關鍵思考。

上線前的性能測試是否有用？

有時候大家可能覺得奇怪，爲何我們系統上線前都做了性能測試，爲何上線後還是會出現系統性能問題。那麼我們可以考慮下實際上我們上線前性能測試可能存在的一些無法真實模擬生產環境的地方，具體爲：

而實際上我們在做性能測試的時候以上幾個點都很難真正做到，因此要想完全模擬出生產真實環境是相當困難的，這也導致了很多性能問題是在真正上線後才發現。

系統本身水平彈性擴展是否完全解決性能問題？

第二個點也是我們經常談的比較多的點，就是我們的業務系統在進行架構設計的時候，特別是面對非功能性需求，我們都會談到系統本身的數據庫，中間件都採用了集羣技術，能夠做到彈性水平擴展。那麼這種彈性水平擴展能力是否又真正解決了性能問題？

實際上我們看到對於數據庫往往很難真正做到無限的彈性水平擴展，即使對於 Oracle RAC 集羣往往也是最多擴展到單點的 2 到 3 倍性能。對於應用集羣往往可以做到彈性水平擴展，當前技術也比較成熟。

當中間件能夠做到完全彈性擴展的時候，實際上仍然可能存在性能問題，即隨着我們系統的運行和業務數據量的不斷積累增值。實際上你可以看到往往非併發狀態下的單用戶訪問本身就很慢，而不是說併發上來後慢。因此也是我們常說的要給點，即：

業務系統性能診斷的分類

對於業務系統性能診斷，如果從靜態角度我們可以考慮從以下三個方面進行分類

那麼一個業務系統應用功能出現問題了，我們當然也可以從動態層面來看實際一個應用請求從調用開始究竟經過了哪些代碼和硬件基礎設施，通過分段方法來定位和查詢問題。

比如我們常見的就是一個查詢功能如果出現問題了，首先就是找到這個查詢功能對應的 SQL 語句在後臺查詢是否很慢，如果這個 SQL 本身就慢，那麼就要優化優化 SQL 語句。如果 SQL 本身快但是查詢慢，那就要看下是否是前端性能問題或者集羣問題等。

軟件代碼的問題往往是最不能忽視的一個性能問題點

對於業務系統性能問題，我們經常想到的就是要擴展數據庫的硬件性能，比如擴展 CPU 和內存，擴展集羣，但是實際上可以看到很多應用的性能問題並不是硬件性能導致的，而是由於軟件代碼性能引起的。對於軟件代碼常見的性能問題我在以往的博客文章裏面也談過到，比較典型的包括了。

以上都是常見的一些軟件代碼性能問題點，而這些往往需要通過我們進行 Code Review 或代碼評審的方式才能夠發現出來。因此如果要做全面的性能優化，對於軟件代碼的性能問題排查是必須的。

通過 IT 資源監控或 APM 應用工具來發現性能問題

對於性能問題的發現一般有兩條路徑，一個就是通過我們 IT 資源的監控，APM 的性能監控和預警來提前發現性能問題，一個是通過業務用戶在使用過程中的反饋來發現性能問題。

APM 應用性能管理主要指對企業的關鍵業務應用進行監測、優化，提高企業應用的可靠性和質量，保證用戶得到良好的服務，降低 IT 總擁有成本 (TCO)。

資源池 -》應用層 -》業務層

這個可以理解爲 APM 的一個關鍵點，原有的網管類監控軟件更多的是資源和操作系統層面，包括計算和存儲資源的使用和利用率情況，網絡本身的性能情況等。但是當要分析所有的資源層問題如何對應到具體的應用，對應到具體的業務功能的時候很難。

傳統模式下，當出現 CPU 或內存滿負荷的時候，如果要查找到具體是哪個應用，哪個進程或者具體哪個業務功能，哪個 sql 語句導致的往往並不是容易的事情。在實際的性能問題優化中往往也需要做大量的日誌分析和問題定位，最終纔可能找到問題點。

比如在我們最近的項目實施中，結合 APM 和服務鏈監控，我們可以快速的發現究竟是哪個服務調用出現了性能問題，或者快速的定位出哪個 SQL 語句有驗證的性能問題。這個都可以幫助我們快速的進行性能問題分析和診斷。

資源上承載的是應用，應用本身又包括了數據庫和應用中間件容器，同時也包括了前端；在應用之上則是對應到具體的業務功能。因此 APM 一個核心就是要將資源 -》應用 -》功能之間進行整合分析和銜接。

而隨着 DevOps 和自動化運維的思路推進，我們更加希望是通過 APM 等工具主動監控來發現性能問題，對於 APM 工具最大的好處就是可以進行服務全鏈路的性能分析，方便我們發現性能問題究竟發生在哪裏。比如我們提交一個表單很慢，通過 APM 分析我們很容易發現究竟是調用哪個業務服務慢，或者是處理哪個 SQL 語句慢。這樣可以極大的提升我們性能問題分析診斷的效率。

作者：常見 - youmen

來源：www.cnblogs.com/you-men/p/14058806.html

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/iz3T5B6fthJOslBVRtMeDg

猜你喜歡