官方JRockit JVM調優文檔

摘要

本文的目的是以清單的方式提供BEA JRockit JVM的調優信息。從深奧的命令行選項到迭代性能測試，本文涵蓋了許多方面。大部分數據都是我與用戶合作過程中收集的。您要是也有什麼技巧的話，請告訴我，在本文的下一版中，我會嘗試將它們添加進去。

具體的產品版本信息都已在適當的地方列出；但是，本文所提供的通用指南適用於JRockit的大多數版本。每個版本的JRockit都增加了新的設置和優化，所以請查看發行說明和 JRockit產品中心。

驗證當前的JRockit環境

首先需要確定您的運行時應用程序服務器所使用的JRockit的版本。爲此，可以查看相應應用程序服務器的日誌文件。也可以使用適當的腳本設置系統環境，然後執行java –version命令來確定JRockit的版本。

接着，收集當前JVM標誌，開發和/或生產階段需要用到它們：

-server -Xms1024m -Xmx1536m -Xverboselog:gc.log -Xverbose:memory -Xgcprio:throughput

這將告訴您當前JRockit實例的配置情況。

確定應用程序的目標

確定應用程序的目標是什麼。是“響應快”還是“性能高”？根據目標的不同，需要設置不同的垃圾收集算法。

例如，如果應用程序的目標是實現高性能，則確保設置了Dynamic Garbage Collector "-Xgcprio:throughput" 選項。如果目標是響應時間短，那麼需要將-Xgcprio:pausetime -Xpausetarget=XXX’中的pausetarget設置爲最佳值。有關更多細節，請查看JRockit 調優文檔。

收集故障診斷數據

如果JVM性能有問題，那麼最好是先收集一些分析數據。該工作可以由團隊中有相關經驗的人員來完成，您也可以將這些信息發送給BEA Support做進一步分析。

首先，出現問題時需要收集大約10分鐘的運行時JRockit Recording（JRA)數據。可以使用jrcmd.sh實用工具或JRockit Mission Control（JRMC）完成此操作。請閱讀“性能測試期間的JRCMD/JRA”和“JRockit Mission Control”兩節的內容。有關詳細信息，請參閱 JRockit Mission Control文檔。Latency Analysis一節提供許多有價值的內容，我們可以從中瞭解任何潛在的延遲問題（在JRockit中需要一個許可證就可以使用它）。

然後，需要收集問題發生時的一些詳細日誌。方法是在啓動服務器實例的時候在JVM命令行輸入以下參數：

-Xverboselog:perTestGC.log-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license-Xverbosetimestamp -Xgcreport

這樣會將有價值的分析數據收集到剛纔配置的perTestGC.log文件中。團隊成員和/或BEA Support可以對這些數據進行分析。

最後一點：通常，應用程序不會請求執行垃圾收集（也就是在應用程序代碼中調用System.gc()）。但如果您懷疑它有問題，那麼可以在啓動服務器實例的時候，在Java命令行使用-XXnoSystemGC參數來禁用它。

現在，我將介紹如何通過迭代性能測試方法解決這些問題。

迭代性能測試方案及其方法

完成初始數據的收集和分析後，我們可以通過迭代方法來調優JVM。此處介紹的測試方案是在JRockit JVM層執行迭代調優的通用方法，可以找到哪些設置可能有益於特定應用程序。假定您有測量性能結果的方法；然後，可以將它們與“基準”（您應該已經有了）進行比較。

測試1：線程本地區域大小和大對象大小

在本測試中，我們將查看線程本地區域大小。這很重要，因爲如果這些標誌的默認設置對於應用程序不是最佳的（多數情況下是這樣），那麼就會造成堆鎖定，這將對性能產生影響。將大部分對象限制在一定範圍內對整體性能有益。

分析收集的JRA Recording數據

分析結果，查看-XXtlasize和-XXlargeobjectlimit是否需要調優（請記住，對於多數應用程序，根據eDocs，線程本地區域大小應該至少是大對象大小的兩倍）。這些內容位於JRA Recording首頁的右上方。請查看下面關於 tlaSize 和largeObjectLimit 的信息。在JRockit R27.3之前的多數情況下，這些都不必調優。

注意：爲了確保在穩定狀態下獲取配置文件和度量，應用程序需要有足夠的熱啓動時間。要在性能分析過程中檢查是否符要求，可以查看JRA Recording中的優化標籤，其中性能分析前後的優化數量和優化時間應該大致（理論上應該是準確地）相等。

測試2：鎖性能分析

現在讓我們看一下鎖性能分析，它會顯示在應用程序中是否有過多的鎖定。如果確實如此的話，那麼將對整體性能造成影響。

運行測試（啓用-Djrockit.lockprofiling），分析這些結果。確定沒有通過JVM啓用的日誌。該標誌大概會佔用5%到10%的系統開銷，一個單獨的測試將收集該數據，此時性能被忽略，唯一做完的分析是鎖定分析。

-server -Xms1536m -Xmx1536m -Djrockit.lockprofiling

在相同測試中，使用jrcmd.sh實用工具或JRockit Mission Control（JRMC）熱啓動應用程序後，運行10分鐘的JRA Recording。有關如何使用該工具的信息，請參見電子文檔。
使用top和iostat選項監控操作系統，如果需要的話還可使用ctrhandler.act文件指定的信息執行線程轉儲。
分析結果。

測試3：調優tlaSize和largeObjectLimit

在這個測試中，我們將根據前面測試的結果調優線程本地區域大小和大對象限制。

確定JVM未啓用日誌。將 –XxtlaSize和-XXlargeObjectLimit的值設置較高一點可能會有所幫助。但是，要驗證和比較這點則需要需要長時間運行測試。對於 R27.2，將preferredSize設置爲16k可能有所幫助。您可以查看關於這一問題的詳細信息。爲此要，更改TLA設置並使用與測試1相同的Java命令行選項重新運行測試；增加-XXtlaSize和-XXlargeobjectlimit的TLA值設置。相關信息，請參見 tlaSize。注意：在R27.3之前，提高性能通常不需要調優這些標誌。事實上，過度調優這些標誌很可能帶來負面影響。
在相同測試中，使用jrcmd.sh實用工具或JRockit Mission Control（JRMC）熱啓動應用程序後，運行10分鐘的JRA Recording。關於如何使用該工具的信息，請參見電子文檔。

使用top和iostat選項監控操作系統，如果需要的話還可使用ctrhandler.act文件指定的信息執行線程轉儲。

分析結果。

測試4：調優垃圾收集算法

本節測試的目的是運行各種不同的垃圾收集算法設置，並查看哪種設置對於應用程序最佳。關於 -XXsetGC標誌的詳細令牌，請閱讀以下內容。JRockit將以調優的nursery大小運行並移除-Xgcprio:throughput標誌。該 throughput選項將在這些雙版本的垃圾收集器之間自動切換，但進行直接的選擇可能帶來一些額外的性能上的好處。Nursery調優的目的是使被提升的對象保持較少的數量，因爲這是nursery收集中代價高的部分。通過增加和減小nursery的大小對其調優。nursery的大小主要依賴於對象生存的時間，因爲如果它們生存着，則在YC期間會得到提升。運行jrcmd <PID>版本查看哪個當前垃圾收集器策略是活動的。

a. 測試4-1：

使用–XxsetGC垃圾收集算法設置運行測試。該測試將設置垃圾收集選項爲單倍行距加上並行標記算法和並行掃描算法；還要手動調優nursery大小：

-server -Xms1536m -Xmx1536m -Xns:384m  -Xverboselog:perTestGC.log-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license-Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC:singleparpar

在相同測試中，使用jrcmd.sh實用工具或JRockit Mission Control（JRMC）熱啓動應用程序後，運行10分鐘的JRA Recording。關於如何使用該工具的信息，請參見電子文檔。
使用top和iostat選項監控操作系統，如果需要的話還可使用ctrhandler.act文件指定的信息執行線程轉儲。
分析結果。

b. 測試4-2：

用 –XxsetGC運行一個使用垃圾收集算法集的測試。該測試將設置垃圾收集選項爲分代的（雙倍行距）加上並行標記算法和並行掃描算法；還要手動調優nursery大小：

-server -Xms1536m -Xmx1536m -Xns:384m  -Xverboselog:perTestGC.log

-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license

-Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC:genparpar

在做這個測試的時候，使用jrcmd.sh實用工具或JRockit Mission Control (JRMC)收集應用程序熱啓動並運行後10分鐘的JRA Recording。關於如何使用該工具，請參見eDocs。
使用top、iostat，需要的話，還可用帶有ctrhandler.act文件給定的信息的線程轉儲來監控正在運行的系統。
分析結果。

c. 測試4-3：根據前面的-XXsetGC:genparpar測試向上或向下調優nursery大小。
d. 測試4-4：用-Xgc:gencon -Xns50m（和設爲收集規格的日誌）試試。
e. 測試4-5：用-Xgc:parallel -XXcompactratio:1（和設爲收集規格的日誌）試試。

測試5：調優垃圾收集線程

本測試的目的是查看gcthreads標誌設置對整體性能的影響。

根據前面的結果，調優-XXgcthreads標誌爲實際物理CPU的數量並重新運行測試(由於這些值默認是基於機器上核心和硬件線程的數量，所以這應該是自動調優的)。您可以查看在“收集故障診斷數據”一節收集的詳細輸出日誌來對其驗證。更多細節請參見 gcThreads flag。

測試6：調優鎖爭用

如果在胖鎖（fat lock）上存在鎖爭用，則可以用-XXdisableFatSpin禁止它們，或者用-Djrockit.useAdaptiveFatSpin= true讓JRockit自適應地禁止它們。當測試2啓用-Djrockit.lockprofiling時，可以通過在JRA中查看那個標籤來確定這一點。更多細節，請參見locking in JRockit。

測試7：調優Xeon硬件

如果運行在Xeon硬件之上，那麼可以添加-XXallocPrefetch和-XXallocRedoPrefetch，它們與TLA和LargeObjectLimit一起將有助於減少內存分配的開銷。有關詳細信息，請參見 allocPrefetch標誌。爲了得到最佳的結果，您可能會在BIOS中禁用硬件預取指令。雖然操作方式取決於BIOS的牌子，但參數的名稱通常都爲“Hardware Prefetcher”、“Adjacent Sector Prefetcher”、“Adjacent Cache Line Prefetcher”等。更多信息請參見 Intel on this subject。

測試8：將堆放入largePage

這會將堆鎖入內存，使操作系統不能將其交換出來。更多信息請參見 largePages標誌，有關Linux操作系統端配置的更多信息還可以參考在Linux上配置-XXlargePages 一節。在JRockit R27版中，該選項的名稱爲-XlargePages。根據前面的結果，調優-XlargePages標誌可能有所幫助，但可能也沒有。使用該標誌運行測試，查看結果否對整體性能有幫助。

測試9：用-XXaggressive標誌測試

本節中的這些配置將使JVM高速運行並儘快達到穩定狀態。爲了實現此目標，JVM在啓動時需要更多內部資源；但當目標一旦達成，它所需要的自適應優化將更少。我們推薦您爲了那些單獨工作的、運行時間長的、內存敏感的應用程序使用這個選項。更多細節請參見 aggressive標誌。使用-XXaggressive標誌運行測試，查看結果否對整體性能有幫助。

測試10：用-XX:+UseNewHashFunction標誌測試

這個選項支持一個新的、更快的HashMap散列函數，它在Java 5.0 Update 8中引入，從R27.1.0開始也是BEA JRockit的一部分。這個散列函數能夠通過改進的散列擴展提高性能而不改變HashMap中元素存放的順序。更多細節請參見UseNewHashFunction標誌。使用這個新的-XX:+UseNewHashFunction運行測試，，查看結果否對整體性能有幫助。

測試11：將暗物質減到最少

“暗物質”指被浪費的堆內存，它使堆成爲許多碎片。瞭解如何最大程序地減少暗物質，以便當堆需要壓縮時，整體吞吐量不受影響。請看以下選項：

使用分代的垃圾收集器 (-Xgc:gencon or -Xgc:genpar)。在初始收集（nursery垃圾收集）期間，在nursery中被發現生存的對象被遷移到舊的一代。這樣有好的副作用，當遷移對象時可以壓縮它們。
提高壓縮比（-XXcompactionRatio=nn）。通過將對象遷移到壓縮塊中、消除它們之間的暗物質，壓縮減少了暗物質。
通過-XXminBlockSize:<memSize>選項修改規範（將什麼視爲暗物質？）。堆上小於最小塊大小的塊視爲暗物質。因此，通過減小最小塊大小，您最終減少了暗物質。但請注意，因爲JRockit爲了釋放堆空間必須做更細密的搜索，所以垃圾收集的時間會更長。最小塊大小默認爲2 KB。

進一步測試：調優應用程序服務器層

最後，查看上述調優建議，調優WebLogic Server實例層。

結束語

本文提供的信息絕非一個完整的清單。但它會讓您開始更好地理解和調優JRockit JVM層！

參考資料

附錄

以下內容爲正文引用過的額外信息。

性能測試期間的JRCMD/JRA

使用命令行或者基於JRockit Mission Control (JRMC) Eclipse的工具都能夠執行JRA Recoding。我們可以使用JRMC連接到多個 JRockit JVM，收集JRA recording，查看JVM的實時數據，檢測和排除內存泄漏，以及查看應用程序內的潛伏物（執行緩慢“點”）。有關如何運行JRockit Mission Control，請參見下一節。

下載文檔許可證。
將下載的license.bea文件添加到<JROCKIT_HOME>/jre目錄中。這樣，完整路徑將如下所示：<JROCKIT_HOME>/jre/license.bea
運行JRCMD如下：jrcmd.sh <PID> jrarecording filename=myrecording.xml time=600（該文件被寫入本地目錄或者指定的完整路徑／文件名）或jrcmd.sh <PID> print_threads。
使用脫機JRA工具分析最後得到的myrecording.xml.zip文件。通過在<JROCKIT_HOME>/bin中執行JRA binary，將該JRA工具放入此目錄下。
請查看 JRCMD文檔。

JRockit Mission Control

使用JRockit將下列內容添加到WebLogic Instance的啓動行中：java -Xmanagement:autodiscovery=true,ssl=false,authenticate=false,port=7091
使用<jrockit-install-directory>/bin/jrmc.exe(sh)啓動JRockit Mission Control
如有必要，將JR Mission Control的license.bea file文件添加到：<JROCKIT_HOME>/jre/license.bea
在Mission Control的幫助下，JRA Recordings、內存泄漏、潛伏物探查和監控能夠全部在一處完成。

堆/線程的測試期快照

創建一個簡單的、名稱ctrhandler.act的文件並將其存放在<JROCKIT_HOME>/jre/bin/jrockit目錄。
執行線程轉儲命令時，例如，kill -3)，JRockit會查看此文件並執行命令列表。
ctrlhandler.act文件應該包含以下內容：

#ctrlhander.act file located in the <JROCKIT_HOME>/jre/bin/jrockit directoryset_filename filename=./jrocket_control_breakoutput.txt append=truetimestampprint_threadstimestampversionprint_class_summaryprint_object_summary increaseonly=trueprint_threadsprint_threads nativestack=trueprint_utf8pooltimestampprint_memusagetimestampheap_diagnosticstimestamp# The following is optional and is another way to generate a JRArecordingjrarecording filename=./myjra.xml time=600

在Linux上配置-XXlargePages

問題：爲何使用largePages？

回答：使用largePages的優點是可以鎖定堆內存，並且不適用頁面交換（還可以減少IOWait和GC）。在實際內存中，訪問堆中的對象明顯變快了。因此，爲了實現性能目標，largePages選項是一個理想的選擇。

如果機器支持大頁面，則cat /proc/meminfo的輸出將如下所示：

HugePages_Total: xxxHugePages_Free:  yyyHugepagesize:    zzz KB

如果xxx爲0，則沒有分配任何大頁面。

如果不爲0，則需要使用CONFIG_HUGETLBFS(位於“File systems”下面)和CONFIG_HUGETLB_PAGE（當CONFIG_HUGETLBFS被選時，自動被選上）配置選項構建Linux kernel。
接着，在Linux上分配大頁。注意：只允許根用戶分配大頁面。
- 裝載文件系統。JRockit使用hugepages文件系統，它駐留在內存中。這些步驟可以完成文件系統的安裝。每次機器重啓時都需要完成實際裝載和chmod命令，或者也可以將其添加到一個/etc/rc.d/rc.local類型的文件：

                 mkdir -p  /mnt/hugepages        mount -t hugetlbfs nodev /mnt/hugepages        chmod 777 /mnt/hugepages

分配大頁面。這是通過指定應該分配的內存數量來自動執行的。在分配過程中，這些面頁將被保留起來，不能像普通頁面那樣使用。它們的分配和解除分配方式如下：

echo 20 > /proc/sys/vm/nr_hugepages

此處，數字20指應該保留的頁面數量。要解除分配，可以將分配頁面設置爲0。（注意：請參見後面Q&A部分以確定正確的數量。）

如果並非所有請求的頁面都被保留，那麼可用內存就不夠了。如果確要如此，內存很可能會有太多的碎片，那麼我們的建議是重啓機器。請注意，大頁面不能被交換，所以一切都必須放在物理內存中。

在RHEL3上，該文件的名稱爲/proc/sys/vm/hugetlb_pool，所以可以使用以下命令執行：

echo 500 > /proc/sys/vm/hugetlb_pool

這裏的數字500指請求的大小爲多少MB，而不是頁數。如果JRockit不能夠直接消除臨時的大頁文件，請別忘記在執行之後進行消除。否則，那些頁在被釋放之前將不可用。這對RedHat kernel build 2.4.18-e.25.smp適用，而2.4.18-e.12.smp卻不行。

問題：如何確定發給/proc/sys/vm/nr_hugepages的正確數量呢？

回答：因爲要將整個Java堆放入largePages，所以必須根據堆的大小和頁面大小來確定。爲/proc/sys/vm/nr_hugepages確定正確的數量就像下面的例子那樣簡單，信息如下：

JVM Max Heap = 1536MB (1572864 KB approx)HPAGE_SIZE = 2 MB then  the value sent to /proc/sys/vm/nr_hugepages would be approximately 7.7.  (1572864 MB / 2 MB)

注意：

儘管動態設置大頁面的數量在理論上是可行的，但實踐中並非如此。減少大頁面的數量決不會有問題，但是增加大頁面的數量就會產生問題。原因是，爲了創建一個大頁，Linux需要在內存中找到足夠大的連續的區域。如果找不到，就不能創建大頁面。

剛啓動系統時，內存的碎片還不是很多，所以要找到足夠大的連續的區域並不是問題。但機器運行時間一長，內存會產生更多的碎片。所以，如果要確保能夠分配足夠大的頁面，就必須在啓動剛完成時通過啓動腳本或手動設置它們。