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

作者：Carl Brahms

自動執(zhí)行負(fù)載生成和性能優(yōu)化過程為什么可以節(jié)省大量的時間和精力。

2008 年 9 月發(fā)布

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

性能優(yōu)化的基本原則

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

首先要制定明確的性能目標(biāo)

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

優(yōu)化 WebLogic Server 設(shè)置

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

查找瓶頸

問題并不總是與 JVM 或 WebLogic 設(shè)置有關(guān)。請確保正確調(diào)整操作系統(tǒng)和網(wǎng)絡(luò)設(shè)置以滿足應(yīng)用程序要求，尤其在使用 UNIX 或 Linux 時。在負(fù)載狀態(tài)下監(jiān)視服務(wù)器的磁盤和網(wǎng)絡(luò) I/O 以及 CPU 利用情況。如果數(shù)據(jù)庫性能不佳，還應(yīng)檢查您的數(shù)據(jù)庫塊大小、池大小和其他特定于供應(yīng)商的性能優(yōu)化設(shè)置。任何基礎(chǔ)資源限制都可能導(dǎo)致顯著的性能下降。

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

優(yōu)化應(yīng)用程序代碼

設(shè)計應(yīng)用程序時需要考慮性能因素，這一點(diǎn)是顯而易見的。在當(dāng)前的 SOA 環(huán)境中，應(yīng)用程序很容易變得過于復(fù)雜，并存在很多影響性能的問題。設(shè)計不良的應(yīng)用程序可能會引發(fā)系統(tǒng)資源、網(wǎng)絡(luò)或數(shù)據(jù)庫瓶頸。請使用經(jīng)過驗證的性能模式來設(shè)計應(yīng)用程序，并使應(yīng)用程序盡量簡單。

優(yōu)化堆

無論使用什么應(yīng)用程序，如果堆不足或花費(fèi)大量時間進(jìn)行垃圾收集，您都應(yīng)該嘗試調(diào)整整個堆及其新生代的大小?？捎枚训拇笮⊥ǔ@著提高或降低應(yīng)用程序的性能。

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

也許最基本的堆性能優(yōu)化步驟是將最小堆大小設(shè)置成與最大堆大小相同。此建議同樣適用于新生代（在 Sun HotSpot 中為 New generation，在 Oracle JRockit 中為 Nursery）大小的設(shè)置。默認(rèn)情況下，經(jīng)常出現(xiàn)堆擴(kuò)展和堆收縮時 JVM 會浪費(fèi)資源。

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

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

試用垃圾收集器

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

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

其他注意事項

JRockit 和 Hotspot JVM 提供了許多特定的 JVM 性能選項。影響性能的 WebLogic 設(shè)置非常多。要進(jìn)行有效優(yōu)化，最重要的是使開發(fā)人員、架構(gòu)師、系統(tǒng)工程師、QA 測試網(wǎng)絡(luò)工程師和 DBA 作為一個團(tuán)隊進(jìn)行協(xié)作。在優(yōu)化過程中實(shí)現(xiàn)跨學(xué)科參與可以精簡工作，獲得更佳結(jié)果，從而最終降低優(yōu)化所需的成本和時間。

自動化的優(yōu)點(diǎn)

我們已經(jīng)了解了 WebLogic 性能優(yōu)化的幾個基本原則，現(xiàn)在來看一下自動執(zhí)行這些任務(wù)如何真正使性能優(yōu)化更容易、更省時、更有效。

快速更改，頻繁優(yōu)化

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

另外，很多人錯誤地認(rèn)為調(diào)優(yōu)是可做可不做的事情，因為他們當(dāng)前的響應(yīng)時間很充裕。人們很容易忽略這樣一個事實(shí)，即正確的調(diào)整可以提高服務(wù)器的穩(wěn)定性和持久性。不調(diào)整或錯誤調(diào)整可能會導(dǎo)致故障，而經(jīng)過正確調(diào)整的環(huán)境運(yùn)行起來更具可預(yù)測性且更穩(wěn)定。

節(jié)省時間，挖掘性能潛力

我們在優(yōu)化服務(wù)器上通常做得不夠頻繁或不夠徹底，僅僅因為這一過程非常費(fèi)時。當(dāng)您自動執(zhí)行此過程時，手動執(zhí)行需要幾天時間的工作現(xiàn)在在無人干預(yù)的情況下一晚上即可完成。以前花無數(shù)個小時進(jìn)行調(diào)優(yōu)的人員現(xiàn)在可以節(jié)省這些時間做更有意義的事情。

隨著故障減少、性能提高、正確利用硬件、“繁重工作”減少以及可以利用節(jié)省的時間做更多工作，自動執(zhí)行 Java 優(yōu)化所帶來的財務(wù)結(jié)余將會快速增長。在當(dāng)今苛刻的環(huán)境中，性能上的細(xì)小收益通常都會帶來顯著的資源節(jié)省。

邊看邊學(xué)

了解代碼更改和不同調(diào)優(yōu)變量如何影響性能非常具有啟發(fā)作用。自動執(zhí)行優(yōu)化和分析允許您嘗試更多不同的設(shè)置組合，并且通過適當(dāng)?shù)谋O(jiān)視，您可以同時看到結(jié)果。這就像站在性能專家團(tuán)隊的肩膀上；您開始了解為何作出某些優(yōu)化決策，在這個過程中您能夠?qū)W到很多知識。

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

逐步執(zhí)行自動優(yōu)化

在本部分中，您將了解使用 Arcturus Applicare 優(yōu)化向?qū)Р檎易罴?JVM 設(shè)置的過程。為了節(jié)省時間，我將演示測試各種垃圾收集設(shè)置的過程。

簡單來講，優(yōu)化向?qū)迂?fù)載測試、監(jiān)視服務(wù)器、分析行為、基于嵌入式智能作出決策、優(yōu)化配置并回彈服務(wù)器。此過程將重復(fù)執(zhí)行，自動優(yōu)化各種 JVM、操作系統(tǒng)和 WebLogic 設(shè)置，直至找到最佳組合。以下是每個步驟的分解內(nèi)容。

由于自動執(zhí)行時優(yōu)化變得非常容易，因此您可能很快就希望進(jìn)行微調(diào)和試驗。在優(yōu)化向?qū)е校泻芏嗫捎糜诳刂瀑Y源利用的高級選項，我將在后面進(jìn)行詳細(xì)介紹。與 在任何性能優(yōu)化過程中一樣，您需要對應(yīng)用程序行為有所了解。如果應(yīng)用程序有預(yù)熱時間或初始緩存時間段，必須確保運(yùn)行足夠時間的負(fù)載才能獲取精確結(jié)果。

選擇負(fù)載測試設(shè)置

優(yōu)化向?qū)c Apache JMeter、HP Load Runner 和 The Grinder 負(fù)載生成工具進(jìn)行了集成，它還能夠觸發(fā)您自己的自定義 Java 應(yīng)用程序和 shell 腳本所生成的負(fù)載。我還沒有生成負(fù)載工具設(shè)置或任何負(fù)載腳本，因此我使用 JMeter（系統(tǒng)自帶）并遵循以下指令來記錄測試腳本。

啟動優(yōu)化向?qū)r，我指定了負(fù)載腳本，它允許自定義要模擬的用戶數(shù)。在本次測試中我選擇了 70 個用戶，因為根據(jù)以前的測試我知道，當(dāng)用戶數(shù)達(dá)到此數(shù)值時我的應(yīng)用程序性能開始下降。

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

選擇測試條件

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

開始“執(zhí)行”

現(xiàn)在您可以坐下來放松一下。您還可以安排在任意時間開始優(yōu)化，這樣，如果您要在以后的非高峰時間進(jìn)行優(yōu)化，則不必親臨現(xiàn)場。優(yōu)化向?qū)L試其中每個設(shè)置，當(dāng)優(yōu)化結(jié)束后，優(yōu)化向?qū)蓤蟊?，給出有關(guān)哪些設(shè)置提供最佳性能的建議。

當(dāng)服務(wù)器處于負(fù)載狀態(tài)下時，優(yōu)化向?qū)⒈O(jiān)視服務(wù)器的性能和運(yùn)行情況。向?qū)ㄟ^查看吞吐量、堆信息、CPU 利用情況、線程、等待者、隊列（基本上包括了您所觀察的全部內(nèi)容 — 如果您親自運(yùn)行負(fù)載測試的話）完成此任務(wù)。在啟動優(yōu)化會話時可以設(shè)置和自定義樣例之間的頻率和時間間隔。

這是優(yōu)化向?qū)Ш?Applicare 其他功能最具吸引力、最有價值的一個方面。它隨制定智能化性能優(yōu)化決策的人工智能引擎一起提供。根據(jù)性能優(yōu)化顧問的綜合經(jīng)驗、經(jīng)過驗證的優(yōu)化方法和最佳實(shí) 踐構(gòu)建了知識庫?？梢圆榭簇?fù)載測試過程中生成的數(shù)據(jù)，并對下一步將要優(yōu)化的內(nèi)容作出明智的決策。優(yōu)化向?qū)г谶_(dá)到最佳可能組合后，將結(jié)束優(yōu)化過程。

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

結(jié)果

在這里，我簡要討論優(yōu)化結(jié)果，顯示 Applicare 創(chuàng)建的一些有關(guān)優(yōu)化會話的圖表，并討論 Applicare 給出的一些其他建議。這不是詳盡的優(yōu)化練習(xí)，但它顯示了優(yōu)化向?qū)г谏倭控?fù)載狀態(tài)下可以在短時間內(nèi)完成的任務(wù)。優(yōu)化過程歷時 4 小時完成，它嘗試了 9 個不同的設(shè)置組合，并優(yōu)化了 JVM 設(shè)置和其他設(shè)置，包括線程、JDBC 設(shè)置等。優(yōu)化向?qū)Р檎疫^小或過大的配置區(qū)域并進(jìn)行適當(dāng)設(shè)置。根據(jù)我為優(yōu)化向?qū)峁﹪L試的參數(shù)，最佳設(shè)置如下：

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

  

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

其他建議

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

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

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

高級選項

優(yōu)化向?qū)峁┝艘恍╊A(yù)定義的選項，供每個 WebLogic 支持的 JVM 試用，以便找到適用于您的環(huán)境的最佳垃圾收集器，但它也為高級用戶提供了嘗試任意所需選項的靈活性。在此次測試中，我嘗試了一些我自己的設(shè)置，向?qū)H用幾 個小時就找到了最佳設(shè)置，為我節(jié)省了很多精力。

    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

  

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

結(jié)論

優(yōu)化 WebLogic 的過程保持不變，只是運(yùn)行負(fù)載、分析性能、適當(dāng)更改和重新啟動 WebLogic Server 這些繁瑣的工作全部無縫地自動完成。優(yōu)化向?qū)且粋€自動執(zhí)行負(fù)載生成和性能優(yōu)化的省時工具。

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

參考資料

• BEA 的 JVM 優(yōu)化指南 — 介紹 JRockit 和 HotSpot 優(yōu)化注意事項
• EJB 優(yōu)化 — WebLogic Server EJB 優(yōu)化指南
• 優(yōu)化向?qū)? — 有關(guān) Arcturus 優(yōu)化向?qū)У母嘈畔?
• 請求演示 — 您可以請求 Applicare 演示并試用它

自動執(zhí)行 Java 性能優(yōu)化