http://www.oracle.com/technology/global/cn/pub/articles/brahms-tuning.html?_template=/ocom/print

作者：Carl Brahms

自動執行負載生成和性能優化過程為什么可以節省大量的時間和精力。

2008 年 9 月發布

優化可能是一項非常艱巨而費時的工作，尤其對于需要最佳性能的環境來說更是如此。優化所帶來的好處是使環境更穩定、故障更少、總體性能更佳。也許您 幸運地擁有內部性能優化人員和專門的性能優化環境，如此優越的條件是非常罕見的。如果您像其他人一樣，需要在有限的時間內完成性能優化，本文將為您講述自 動執行調優過程如何比手動調優更輕松、更快捷、更全面。

性能優化的基本原則

Java 性能優化是一個持續不斷的、通常歷時很長且令人沮喪的過程。調優很少會一次性解決性能問題。有時，不管您添加了多少硬件，或者花了多長時間試圖調整晦澀難 懂的內存參數，可能都難以達到理想性能。要獲得最佳性能，需要明確的性能目標、深思熟慮的設計、堅實的執行情況，并且最終要執行徹底的性能優化。

首先要制定明確的性能目標

在采取任何步驟優化性能之前，首先要確定性能目標。這是因為預期的行為和用戶數、數據量以及請求大小在很大程度上決定著您將作出什么類型的優化決策。每個環境都是唯一的，清楚地了解應用程序和環境的限制以及您希望達到的性能和負載水平，對于您日后深入過程將有所幫助。

優化 WebLogic Server 設置

可以調整的 WebLogic 設置差不多有幾百個：池大小、調整連接積壓緩沖、緩存、JDBC 和 JMS 設置、使用工作管理器設置優先級、集群等。您可以先從查看 WebLogic Server 的幾大優化建議 開始。

查找瓶頸

問題并不總是與 JVM 或 WebLogic 設置有關。請確保正確調整操作系統和網絡設置以滿足應用程序要求，尤其在使用 UNIX 或 Linux 時。在負載狀態下監視服務器的磁盤和網絡 I/O 以及 CPU 利用情況。如果數據庫性能不佳，還應檢查您的數據庫塊大小、池大小和其他特定于供應商的性能優化設置。任何基礎資源限制都可能導致顯著的性能下降。

請記住，最終目的只是達到您的性能目標，而不是清除每一個瓶頸。系統中將始終存在一個瓶頸或最慢部分，但最要緊的是達到您的性能目標并使客戶滿意。

優化應用程序代碼

設計應用程序時需要考慮性能因素，這一點是顯而易見的。在當前的 SOA 環境中，應用程序很容易變得過于復雜，并存在很多影響性能的問題。設計不良的應用程序可能會引發系統資源、網絡或數據庫瓶頸。請使用經過驗證的性能模式來設計應用程序，并使應用程序盡量簡單。

優化堆

無論使用什么應用程序，如果堆不足或花費大量時間進行垃圾收集，您都應該嘗試調整整個堆及其新生代的大小。可用堆的大小通常會顯著提高或降低應用程序的性能。

為 WebLogic 服務器確定合適的堆大小對于提高性能非常重要。作為確定大小的一般規則，您希望在每次垃圾收集結束時釋放大約一半的堆空間。換言之，即堆的大小應至少是其活動對象的兩倍。

也許最基本的堆性能優化步驟是將最小堆大小設置成與最大堆大小相同。此建議同樣適用于新生代（在 Sun HotSpot 中為 New generation，在 Oracle JRockit 中為 Nursery）大小的設置。默認情況下，經常出現堆擴展和堆收縮時 JVM 會浪費資源。

您盡可以將堆大小設置為系統可以處理的最大值（除去操作系統和其他應用程序所需的內存）。較大的堆會降低垃圾收集的頻率，但可能需要花費較長時間來執行較大的垃圾收集。

VM 用于處理本地庫和 permGen（如果使用 Sun HotSpot）的內存始終大于堆大小，因此請注意，不要超出物理 RAM 的總大小。操作系統將內存分頁到磁盤時將顯著降低性能。

試用垃圾收集器

垃圾收集是用于從不再使用的對象中回收堆空間的一種機制。有多種垃圾收集模式（從 JVM 到 JVM），這些模式都以不同方式使用系統資源。您在優化過程中的工作是確定什么類型的垃圾收集模式最適用于您的特定應用程序和性能目標。選擇收集器時的目 標就是使垃圾收集暫停時間盡量縮短，從而提高垃圾收集吞吐量。

有關如何使用 JRockit 垃圾收集模式的信息，請參見“選擇和優化垃圾收集器”部分。有關 Sun HotSpot VM 可用的垃圾收集模式的詳細概述，請參見 Sun 的 Tuning Garbage Collection with the 5.0 Java Virtual Machine （使用 5.0 Java 虛擬機優化垃圾收集）。

其他注意事項

JRockit 和 Hotspot JVM 提供了許多特定的 JVM 性能選項。影響性能的 WebLogic 設置非常多。要進行有效優化，最重要的是使開發人員、架構師、系統工程師、QA 測試網絡工程師和 DBA 作為一個團隊進行協作。在優化過程中實現跨學科參與可以精簡工作，獲得更佳結果，從而最終降低優化所需的成本和時間。

自動化的優點

我們已經了解了 WebLogic 性能優化的幾個基本原則，現在來看一下自動執行這些任務如何真正使性能優化更容易、更省時、更有效。

快速更改，頻繁優化

我曾多次看到，自動執行性能優化過程所產生的結果比專家獨自執行優化所產生的結果更好。這主要是因為，自動過程可以快速執行更改并確定和衡量更改對 性能的影響，比神經最興奮的人還要快，還要周到。另外，由于調優變成一個省力的過程，您還可以針對每次代碼發布進行優化，從而與應用程序更改取得同步。對 應用程序功能的細微更改都會導致很多預料不到的性能問題。

另外，很多人錯誤地認為調優是可做可不做的事情，因為他們當前的響應時間很充裕。人們很容易忽略這樣一個事實，即正確的調整可以提高服務器的穩定性和持久性。不調整或錯誤調整可能會導致故障，而經過正確調整的環境運行起來更具可預測性且更穩定。

節省時間，挖掘性能潛力

我們在優化服務器上通常做得不夠頻繁或不夠徹底，僅僅因為這一過程非常費時。當您自動執行此過程時，手動執行需要幾天時間的工作現在在無人干預的情況下一晚上即可完成。以前花無數個小時進行調優的人員現在可以節省這些時間做更有意義的事情。

隨著故障減少、性能提高、正確利用硬件、“繁重工作”減少以及可以利用節省的時間做更多工作，自動執行 Java 優化所帶來的財務結余將會快速增長。在當今苛刻的環境中，性能上的細小收益通常都會帶來顯著的資源節省。

邊看邊學

了解代碼更改和不同調優變量如何影響性能非常具有啟發作用。自動執行優化和分析允許您嘗試更多不同的設置組合，并且通過適當的監視，您可以同時看到結果。這就像站在性能專家團隊的肩膀上；您開始了解為何作出某些優化決策，在這個過程中您能夠學到很多知識。

您還能夠針對每次代碼發布輕松地優化服務器，這也算是一個很不錯的意外收獲吧。由于知道將不會有驚喜，因此在部署生產時，您會擁有一個比較平和的心態。

逐步執行自動優化

在本部分中，您將了解使用 Arcturus Applicare 優化向導查找最佳 JVM 設置的過程。為了節省時間，我將演示測試各種垃圾收集設置的過程。

簡單來講，優化向導將啟動負載測試、監視服務器、分析行為、基于嵌入式智能作出決策、優化配置并回彈服務器。此過程將重復執行，自動優化各種 JVM、操作系統和 WebLogic 設置，直至找到最佳組合。以下是每個步驟的分解內容。

由于自動執行時優化變得非常容易，因此您可能很快就希望進行微調和試驗。在優化向導中，有很多可用于控制資源利用的高級選項，我將在后面進行詳細介紹。與 在任何性能優化過程中一樣，您需要對應用程序行為有所了解。如果應用程序有預熱時間或初始緩存時間段，必須確保運行足夠時間的負載才能獲取精確結果。

選擇負載測試設置

優化向導與 Apache JMeter、HP Load Runner 和 The Grinder 負載生成工具進行了集成，它還能夠觸發您自己的自定義 Java 應用程序和 shell 腳本所生成的負載。我還沒有生成負載工具設置或任何負載腳本，因此我使用 JMeter（系統自帶）并遵循以下指令來記錄測試腳本。

啟動優化向導時，我指定了負載腳本，它允許自定義要模擬的用戶數。在本次測試中我選擇了 70 個用戶，因為根據以前的測試我知道，當用戶數達到此數值時我的應用程序性能開始下降。

第一次優化服務器時，您可能不了解您的應用程序處理多少用戶才會導致性能下降。如果我不清楚我的環境可以處理多少用戶，我可能會使用一個稱為“容量 確定”的簡潔功能（圖 2），而不必進行猜測和購買更多服務器。容量確定的目的是找到良好吞吐量的最佳平衡，而不超出您的資源利用限制。容量確定允許您設置初始用戶數和將要嘗試 的最大用戶數，在優化時它將增加負載，直至在吞吐量和資源利用之間找到平衡點。

選擇測試條件

接下來，您需要選擇每個優化會話要采用的監視樣例數，以及這些會話之間的時間間隔。正如我在前面提到的，如果您的應用程序有預熱時間或初始緩存時間 段，則此時您可以通過優化設置來確保測試時間足夠長，以便得到精確的基準值。我選擇每個會話采用 20 個樣例，時間間隔為 60 秒。

開始“執行”

現在您可以坐下來放松一下。您還可以安排在任意時間開始優化，這樣，如果您要在以后的非高峰時間進行優化，則不必親臨現場。優化向導將嘗試其中每個設置，當優化結束后，優化向導會生成報表，給出有關哪些設置提供最佳性能的建議。

當服務器處于負載狀態下時，優化向導將監視服務器的性能和運行情況。向導通過查看吞吐量、堆信息、CPU 利用情況、線程、等待者、隊列（基本上包括了您所觀察的全部內容 — 如果您親自運行負載測試的話）完成此任務。在啟動優化會話時可以設置和自定義樣例之間的頻率和時間間隔。

這是優化向導和 Applicare 其他功能最具吸引力、最有價值的一個方面。它隨制定智能化性能優化決策的人工智能引擎一起提供。根據性能優化顧問的綜合經驗、經過驗證的優化方法和最佳實 踐構建了知識庫。可以查看負載測試過程中生成的數據，并對下一步將要優化的內容作出明智的決策。優化向導在達到最佳可能組合后，將結束優化過程。

我可以在 Applicare 控制臺中實時查看進度表，也可以等到測試結束后查看報表。如果您要查看數據以便得出自己的結論，可以參考大量的報表和圖表，它們針對每個優化設置的行為提供了完整的詳細信息。

結果

在這里，我簡要討論優化結果，顯示 Applicare 創建的一些有關優化會話的圖表，并討論 Applicare 給出的一些其他建議。這不是詳盡的優化練習，但它顯示了優化向導在少量負載狀態下可以在短時間內完成的任務。優化過程歷時 4 小時完成，它嘗試了 9 個不同的設置組合，并優化了 JVM 設置和其他設置，包括線程、JDBC 設置等。優化向導查找過小或過大的配置區域并進行適當設置。根據我為優化向導提供嘗試的參數，最佳設置如下：

    -Xms512m -Xmx512m -XX:CompileThreshold=8000 -XX:PermSize=48m 
-XX:MaxPermSize=128m  -Xverify:none -XX:NewRatio=3 
-XX:SurvivorRatio=6 -XX:+UseParallelGC 

  

Applicare 提供一組顯示優化結果的圖表，為了節省空間，我給出了顯示優化前后變化的吞吐量和堆圖表。您可以看到堆的利用率較低，并且主要垃圾收集的暫停時間較短。您 還可以看到，在主要垃圾收集發生時吞吐量下降，這表明優化前的初始設置在主要垃圾收集期間會導致很長的暫停時間。

其他建議

Applicare 還檢測到應用程序運行時行為和服務器配置方面的問題。它檢測出 EJB 緩存配置不當，并建議增加緩存大小。

另外，Applicare 的診斷結果還指出，在優化過程中打開的會話數太多以致于影響了性能（有時超出 17,000 個會話）。它指出了一些實例，在這些實例中對我的應用程序的某些 Web 應用程序的會話失效間隔秒數設置過高，并建議進行重新評估，以免非活動會話打開時間過長。

幸運的是，我不必猜測或查找這些瓶頸，因為工具已將這些瓶頸清晰地顯示出來。

高級選項

優化向導提供了一些預定義的選項，供每個 WebLogic 支持的 JVM 試用，以便找到適用于您的環境的最佳垃圾收集器，但它也為高級用戶提供了嘗試任意所需選項的靈活性。在此次測試中，我嘗試了一些我自己的設置，向導僅用幾 個小時就找到了最佳設置，為我節省了很多精力。

    applicare.jvmparams.param6= -Xmn256m -Xss128k -XX\:+UseConcMarkSweepGC 
-XX\:+UseParNewGC -XX\:SurvivorRatio\=8 -XX\:TargetSurvivorRatio\=90 
-XX\:MaxTenuringThreshold\=3 -Xms512m -Xmx512m -XX:CompileThreshold=8000 
-XX:PermSize=48m  -XX:MaxPermSize=128m  -Xverify:none 
applicare.jvmparams.param5= -Xmn256m -Xss128k -XX\:+UseParallelGC 
-XX\:+UseParallelOldGC -XX\:+UseBiasedLocking -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param4= -Xmn256m -Xss128k 
-XX\:+UseParallelGC -XX\:+UseParallelOldGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param3= -XX\:NewRatio\=3 
-XX\:SurvivorRatio\=6 -XX\:+UseConcMarkSweepGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param2=-XX\:NewRatio\=3 
-XX\:SurvivorRatio\=6 -XX\:+UseParallelGC -Xms512m -Xmx512m 
-XX:CompileThreshold=8000 -XX:PermSize=48m  -XX:MaxPermSize=128m  
-Xverify:none applicare.jvmparams.param1=-XX\:+UseParallelGC 
-XX\:MaxGCPauseMillis\=3 -Xms512m -Xmx512m -XX:CompileThreshold=8000 
-XX:PermSize=48m  -XX:MaxPermSize=128m  -Xverify:none

  

您還可以配置在容量確定優化運行期間要利用的 CPU 數量。通常情況下，多個受管理服務器共處同一環境中，因此您自然希望限制負載狀態下每個過程所占用的硬件空間。通過對可接受的隊列長度、等待者數量和其他可配置選項進行限制，可以使工具滿足您環境的獨特優化需求。

結論

優化 WebLogic 的過程保持不變，只是運行負載、分析性能、適當更改和重新啟動 WebLogic Server 這些繁瑣的工作全部無縫地自動完成。優化向導是一個自動執行負載生成和性能優化的省時工具。

我已經在本文中介紹了 JVM 自動優化功能，但 Applicare 還會自動進行配置分析、問題檢測、根本原因檢測，并提供一系列旨在提高性能和可用性的其他功能。

參考資料

• BEA 的 JVM 優化指南 — 介紹 JRockit 和 HotSpot 優化注意事項
• EJB 優化 — WebLogic Server EJB 優化指南
• 優化向導 — 有關 Arcturus 優化向導的更多信息
• 請求演示 — 您可以請求 Applicare 演示并試用它

自動執行 Java 性能優化