摘要
本文的目的是以清單的方式提供BEA JRockit JVM的調(diào)優(yōu)信息。從深?yuàn)W的命令行選項(xiàng)到迭代性能測(cè)試，本文涵蓋了許多方面。大部分?jǐn)?shù)據(jù)都是我與用戶合作過程中收集的。您要是也有什么技巧的話，請(qǐng)告訴我，在本文的下一版中，我會(huì)嘗試將它們添加進(jìn)去。
具體的產(chǎn)品版本信息都已在適當(dāng)?shù)牡胤搅谐?；但是，本文所提供的通用指南適用于JRockit的大多數(shù)版本。每個(gè)版本的JRockit都增加了新的設(shè)置和優(yōu)化，所以請(qǐng)查看發(fā)行說明 和 JRockit產(chǎn)品中心。
驗(yàn)證當(dāng)前的JRockit環(huán)境
首先需要確定您的運(yùn)行時(shí)應(yīng)用程序服務(wù)器所使用的JRockit的版本。為此，可以查看相應(yīng)應(yīng)用程序服務(wù)器的日志文件。也可以使用適當(dāng)?shù)哪_本設(shè)置系統(tǒng)環(huán)境，然后執(zhí)行java –version命令來確定JRockit的版本。
接著，收集當(dāng)前JVM標(biāo)志，開發(fā)和/或生產(chǎn)階段需要用到它們：
-server -Xms1024m -Xmx1536m -Xverboselog:gc.log -Xverbose:memory
-Xgcprio:throughput
這將告訴您當(dāng)前JRockit實(shí)例的配置情況。
確定應(yīng)用程序的目標(biāo)
確定應(yīng)用程序的目標(biāo)是什么。是“響應(yīng)快”還是“性能高”？根據(jù)目標(biāo)的不同，需要設(shè)置不同的垃圾收集算法。
例如，如果應(yīng)用程序的目標(biāo)是實(shí)現(xiàn)高性能，則確保設(shè)置了Dynamic Garbage Collector "-Xgcprio:throughput" 選項(xiàng)。如果目標(biāo)是響應(yīng)時(shí)間短，那么需要將-Xgcprio:pausetime -Xpausetarget=XXX'中的pausetarget設(shè)置為最佳值。有關(guān)更多細(xì)節(jié)，請(qǐng)查看JRockit 調(diào)優(yōu)文檔。
收集故障診斷數(shù)據(jù)
如果JVM性能有問題，那么最好是先收集一些分析數(shù)據(jù)。該工作可以由團(tuán)隊(duì)中有相關(guān)經(jīng)驗(yàn)的人員來完成，您也可以將這些信息發(fā)送給BEA Support做進(jìn)一步分析。
首先，出現(xiàn)問題時(shí)需要收集大約10分鐘的運(yùn)行時(shí)JRockit Recording（JRA)數(shù)據(jù)?？梢允褂胘rcmd.sh實(shí)用工具或 JRockit Mission Control（JRMC）完成此操作。請(qǐng)閱讀“性能測(cè)試期間的JRCMD/JRA”和“JRockit Mission Control”兩節(jié)的內(nèi)容。有關(guān)詳細(xì)信息，請(qǐng)參閱 JRockit Mission Control文檔。Latency Analysis一節(jié)提供許多有價(jià)值的內(nèi)容，我們可以從中了解任何潛在的延遲問題（在JRockit中需要一個(gè)許可證就可以使用它）。
然后，需要收集問題發(fā)生時(shí)的一些詳細(xì)日志。方法是在啟動(dòng)服務(wù)器實(shí)例的時(shí)候在JVM命令行輸入以下參數(shù)：
-Xverboselog:perTestGC.log
-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
-Xverbosetimestamp -Xgcreport
這樣會(huì)將有價(jià)值的分析數(shù)據(jù)收集到剛才配置的perTestGC.log文件中。團(tuán)隊(duì)成員和/或BEA Support可以對(duì)這些數(shù)據(jù)進(jìn)行分析。
最后一點(diǎn)：通常，應(yīng)用程序不會(huì)請(qǐng)求執(zhí)行垃圾收集（也就是在應(yīng)用程序代碼中調(diào)用System.gc()）。但如果您懷疑它有問題，那么可以在啟動(dòng)服務(wù)器實(shí)例的時(shí)候，在Java命令行使用-XXnoSystemGC參數(shù)來禁用它。
現(xiàn)在，我將介紹如何通過迭代性能測(cè)試方法解決這些問題。
迭代性能測(cè)試方案及其方法
完成初始數(shù)據(jù)的收集和分析后，我們可以通過迭代方法來調(diào)優(yōu)JVM。此處介紹的測(cè)試方案是在JRockit JVM層執(zhí)行迭代調(diào)優(yōu)的通用方法，可以找到哪些設(shè)置可能有益于特定應(yīng)用程序。假定您有測(cè)量性能結(jié)果的方法；然后，可以將它們與“基準(zhǔn)”（您應(yīng)該已經(jīng)有了） 進(jìn)行比較。
測(cè)試1：線程本地區(qū)域大小和大對(duì)象大小
在本測(cè)試中，我們將查看線程本地區(qū)域大小。這很重要，因?yàn)槿绻@些標(biāo)志的默認(rèn)設(shè)置對(duì)于應(yīng)用程序不是最佳的（多數(shù)情況下是這樣），那么就會(huì)造成堆鎖定，這將對(duì)性能產(chǎn)生影響。將大部分對(duì)象限制在一定范圍內(nèi)對(duì)整體性能有益。
- 分析收集的JRA Recording數(shù)據(jù)
- 分析結(jié)果，查看-XXtlasize和-XXlargeobjectlimit是否需要調(diào)優(yōu)（請(qǐng)記住，對(duì)于多數(shù)應(yīng)用程序，根據(jù)eDocs，線程本地區(qū)域大小應(yīng)該至少是大對(duì)象大小的兩倍）。這些內(nèi)容位于JRA Recording首頁的右上方。請(qǐng)查看下面關(guān)于 tlaSize 和 largeObjectLimit 的信息。在JRockit R27.3之前的多數(shù)情況下，這些都不必調(diào)優(yōu)。
注意：為了確保在穩(wěn)定狀態(tài)下獲取配置文件和度量，應(yīng)用程序需要有足夠的熱啟動(dòng)時(shí)間。要在性能分析過程中檢查是否符要求，可以查看JRA Recording中的優(yōu)化標(biāo)簽，其中性能分析前后的優(yōu)化數(shù)量和優(yōu)化時(shí)間應(yīng)該大致（理論上應(yīng)該是準(zhǔn)確地）相等。
測(cè)試2：鎖性能分析
現(xiàn)在讓我們看一下鎖性能分析，它會(huì)顯示在應(yīng)用程序中是否有過多的鎖定。如果確實(shí)如此的話，那么將對(duì)整體性能造成影響。
- 運(yùn)行測(cè)試（啟用-Djrockit.lockprofiling），分析這些結(jié)果。確定沒有通過JVM啟用的日志。該標(biāo)志大概會(huì)占用5%到10%的系統(tǒng)開銷，一個(gè)單獨(dú)的測(cè)試將收集該數(shù)據(jù)，此時(shí)性能被忽略，唯一做完的分析是鎖定分析。
-server -Xms1536m -Xmx1536m -Djrockit.lockprofiling
- 在相同測(cè)試中，使用jrcmd.sh實(shí)用工具或JRockit Mission Control（JRMC）熱啟動(dòng)應(yīng)用程序后，運(yùn)行10分鐘的JRA Recording。有關(guān)如何使用該工具的信息，請(qǐng)參見電子文檔。
- 使用top和iostat選項(xiàng)監(jiān)控操作系統(tǒng)，如果需要的話還可使用ctrhandler.act文件指定的信息執(zhí)行線程轉(zhuǎn)儲(chǔ)。
- 分析結(jié)果。
測(cè)試3：調(diào)優(yōu)tlaSize和largeObjectLimit
在這個(gè)測(cè)試中，我們將根據(jù)前面測(cè)試的結(jié)果調(diào)優(yōu)線程本地區(qū)域大小和大對(duì)象限制。
- 確定JVM未啟用日志。將 –XxtlaSize和-XXlargeObjectLimit的值設(shè)置較高一點(diǎn)可能會(huì)有所幫助。但是，要驗(yàn)證和比較這點(diǎn)則需要需要長時(shí)間運(yùn)行測(cè)試。對(duì)于 R27.2，將preferredSize設(shè)置為16k可能有所幫助。您可以查看關(guān)于這一問題的 詳細(xì)信息。為此要，更改TLA設(shè)置并使用與測(cè)試1相同的Java命令行選項(xiàng)重新運(yùn)行測(cè)試；增加-XXtlaSize和-XXlargeobjectlimit的TLA值設(shè)置。相關(guān)信息，請(qǐng)參見 tlaSize。注意：在R27.3之前，提高性能通常不需要調(diào)優(yōu)這些標(biāo)志。事實(shí)上，過度調(diào)優(yōu)這些標(biāo)志很可能帶來負(fù)面影響。
- 在相同測(cè)試中，使用jrcmd.sh實(shí)用工具或JRockit Mission Control（JRMC）熱啟動(dòng)應(yīng)用程序后，運(yùn)行10分鐘的JRA Recording。關(guān)于如何使用該工具的信息，請(qǐng)參見電子文檔。
- 使用top和iostat選項(xiàng)監(jiān)控操作系統(tǒng)，如果需要的話還可使用ctrhandler.act文件指定的信息執(zhí)行線程轉(zhuǎn)儲(chǔ)。
- 分析結(jié)果。
測(cè)試4：調(diào)優(yōu)垃圾收集算法
本節(jié)測(cè)試的目的是運(yùn)行各種不同的垃圾收集算法設(shè)置，并查看哪種設(shè)置對(duì)于應(yīng)用程序最佳。關(guān)于 -XXsetGC標(biāo)志 的詳細(xì)令牌，請(qǐng)閱讀以下內(nèi)容。JRockit將以調(diào)優(yōu)的nursery大小運(yùn)行并移除-Xgcprio:throughput標(biāo)志。該 throughput選項(xiàng)將在這些雙版本的垃圾收集器之間自動(dòng)切換，但進(jìn)行直接的選擇可能帶來一些額外的性能上的好處。Nursery調(diào)優(yōu)的目的是使被提 升的對(duì)象保持較少的數(shù)量，因?yàn)檫@是nursery收集中代價(jià)高的部分。通過增加和減小nursery的大小對(duì)其調(diào)優(yōu)。nursery的大小主要依賴于對(duì)象 生存的時(shí)間，因?yàn)槿绻鼈兩嬷?，則在YC期間會(huì)得到提升。運(yùn)行jrcmd <PID>版本查看哪個(gè)當(dāng)前垃圾收集器策略是活動(dòng)的。
- a. 測(cè)試4-1：
- 使用–XxsetGC垃圾收集算法設(shè)置運(yùn)行測(cè)試。該測(cè)試將設(shè)置垃圾收集選項(xiàng)為單倍行距加上并行標(biāo)記算法和并行掃描算法；還要手動(dòng)調(diào)優(yōu)nursery大?。?/li>
-server -Xms1536m -Xmx1536m -Xns:384m -Xverboselog:perTestGC.log
-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
-Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC:singleparpar
- 在相同測(cè)試中，使用jrcmd.sh實(shí)用工具或JRockit Mission Control（JRMC）熱啟動(dòng)應(yīng)用程序后，運(yùn)行10分鐘的JRA Recording。關(guān)于如何使用該工具的信息，請(qǐng)參見電子文檔。
- 使用top和iostat選項(xiàng)監(jiān)控操作系統(tǒng)，如果需要的話還可使用ctrhandler.act文件指定的信息執(zhí)行線程轉(zhuǎn)儲(chǔ)。
- 分析結(jié)果。
- b. 測(cè)試4-2：
- 用 –XxsetGC運(yùn)行一個(gè)使用垃圾收集算法集的測(cè)試。該測(cè)試將設(shè)置垃圾收集選項(xiàng)為分代的（雙倍行距）加上并行標(biāo)記算法和并行掃描算法；還要手動(dòng)調(diào)優(yōu)nursery大?。?/li>
-server -Xms1536m -Xmx1536m -Xns:384m -Xverboselog:perTestGC.log
-Xverbose:opt,memory,gcpause,memdbg,compaction,gc,license
-Xverbosetimestamp -Xgcreport -XXnoSystemGC -XXsetGC:genparpar
- 在做這個(gè)測(cè)試的時(shí)候，使用jrcmd.sh實(shí)用工具或JRockit Mission Control (JRMC)收集應(yīng)用程序熱啟動(dòng)并運(yùn)行后10分鐘的JRA Recording。關(guān)于如何使用該工具，請(qǐng)參見eDocs。
- 使用top、iostat，需要的話，還可用帶有ctrhandler.act文件給定的信息的線程轉(zhuǎn)儲(chǔ)來監(jiān)控正在運(yùn)行的系統(tǒng)。
- 分析結(jié)果。
- c. 測(cè)試4-3：根據(jù)前面的-XXsetGC:genparpar測(cè)試向上或向下調(diào)優(yōu)nursery大小。
- d. 測(cè)試4-4：用-Xgc:gencon -Xns50m（和設(shè)為收集規(guī)格的日志）試試。
- e. 測(cè)試4-5：用-Xgc:parallel -XXcompactratio:1（和設(shè)為收集規(guī)格的日志）試試。
測(cè)試5：調(diào)優(yōu)垃圾收集線程
本測(cè)試的目的是查看gcthreads標(biāo)志設(shè)置對(duì)整體性能的影響。
- 根據(jù)前面的結(jié)果，調(diào)優(yōu)-XXgcthreads標(biāo)志為實(shí)際物理CPU的數(shù)量并重新運(yùn)行測(cè)試(由于這些值默認(rèn)是基于機(jī)器上核心和硬件線程的數(shù)量，所以這應(yīng)該是自動(dòng)調(diào)優(yōu)的)。您可以查看在“收集故障診斷數(shù)據(jù)”一節(jié)收集的詳細(xì)輸出日志來對(duì)其驗(yàn)證。更多細(xì)節(jié)請(qǐng)參見 gcThreads flag。
測(cè)試6：調(diào)優(yōu)鎖爭(zhēng)用
如果在胖鎖（fat lock）上存在鎖爭(zhēng)用，則可以用-XXdisableFatSpin禁止它們，或者用-Djrockit.useAdaptiveFatSpin= true讓JRockit自適應(yīng)地禁止它們。當(dāng)測(cè)試2啟用-Djrockit.lockprofiling時(shí)，可以通過在JRA中查看那個(gè)標(biāo)簽來確定這一 點(diǎn)。更多細(xì)節(jié)，請(qǐng)參見locking in JRockit。
測(cè)試7：調(diào)優(yōu)Xeon硬件
如果運(yùn)行在Xeon硬件之上，那么可以添加-XXallocPrefetch和-XXallocRedoPrefetch，它們與TLA和LargeObjectLimit一起將有助于減少內(nèi)存分配的開銷。有關(guān)詳細(xì)信息，請(qǐng)參見 allocPrefetch標(biāo)志。為了得到最佳的結(jié)果，您可能會(huì)在BIOS中禁用硬件預(yù)取指令。雖然操作方式取決于BIOS的牌子，但參數(shù)的名稱通常都為“Hardware Prefetcher”、“Adjacent Sector Prefetcher”、“Adjacent Cache Line Prefetcher”等。更多信息請(qǐng)參見 Intel on this subject。
測(cè)試8：將堆放入largePage
這會(huì)將堆鎖入內(nèi)存，使操作系統(tǒng)不能將其交換出來。更多信息請(qǐng)參見 largePages標(biāo)志，有關(guān)Linux操作系統(tǒng)端配置的更多信息還可以參考 在Linux上配置-XXlargePages 一節(jié)。在JRockit R27版中，該選項(xiàng)的名稱為-XlargePages。根據(jù)前面的結(jié)果，調(diào)優(yōu)-XlargePages標(biāo)志可能有所幫助，但可能也沒有。使用該標(biāo)志運(yùn)行測(cè)試，查看結(jié)果否對(duì)整體性能有幫助。
測(cè)試9：用-XXaggressive標(biāo)志測(cè)試
本節(jié)中的這些配置將使JVM高速運(yùn)行并盡快達(dá)到穩(wěn)定狀態(tài)。為了實(shí)現(xiàn)此目標(biāo)，JVM在啟動(dòng)時(shí)需要更多內(nèi)部資源；但當(dāng)目標(biāo)一旦達(dá)成，它所需要的自適應(yīng)優(yōu)化將更少。我們推薦您為了那些單獨(dú)工作的、運(yùn)行時(shí)間長的、內(nèi)存敏感的應(yīng)用程序使用這個(gè)選項(xiàng)。更多細(xì)節(jié)請(qǐng)參見 aggressive標(biāo)志。使用-XXaggressive標(biāo)志運(yùn)行測(cè)試，查看結(jié)果否對(duì)整體性能有幫助。
測(cè)試10：用-XX:+UseNewHashFunction標(biāo)志測(cè)試
這個(gè)選項(xiàng)支持一個(gè)新的、更快的HashMap散列函數(shù)，它在Java 5.0 Update 8中引入，從R27.1.0開始也是BEA JRockit的一部分。這個(gè)散列函數(shù)能夠通過改進(jìn)的散列擴(kuò)展提高性能而不改變HashMap中元素存放的順序。更多細(xì)節(jié)請(qǐng)參見 UseNewHashFunction標(biāo)志。使用這個(gè)新的-XX:+UseNewHashFunction運(yùn)行測(cè)試，，查看結(jié)果否對(duì)整體性能有幫助。
測(cè)試11：將暗物質(zhì)減到最少
“暗物質(zhì)”指被浪費(fèi)的堆內(nèi)存，它使堆成為許多碎片。了解如何最大程序地減少暗物質(zhì)，以便當(dāng)堆需要壓縮時(shí)，整體吞吐量不受影響。請(qǐng)看以下選項(xiàng)：
- 使用分代的垃圾收集器 (-Xgc:gencon or -Xgc:genpar)。在初始收集（nursery垃圾收集）期間，在nursery中被發(fā)現(xiàn)生存的對(duì)象被遷移到舊的一代。這樣有好的副作用，當(dāng)遷移對(duì)象時(shí)可以壓縮它們。
- 提高壓縮比（-XXcompactionRatio=nn）。通過將對(duì)象遷移到壓縮塊中、消除它們之間的暗物質(zhì)，壓縮減少了暗物質(zhì)。
- 通 過-XXminBlockSize:<memSize>選項(xiàng)修改規(guī)范（將什么視為暗物質(zhì)？）。堆上小于最小塊大小的塊視為暗物質(zhì)。因此，通過 減小最小塊大小，您最終減少了暗物質(zhì)。但請(qǐng)注意，因?yàn)镴Rockit為了釋放堆空間必須做更細(xì)密的搜索，所以垃圾收集的時(shí)間會(huì)更長。最小塊大小默認(rèn)為2 KB。
進(jìn)一步測(cè)試：調(diào)優(yōu)應(yīng)用程序服務(wù)器層
最后，查看上述調(diào)優(yōu)建議，調(diào)優(yōu)WebLogic Server實(shí)例層。
結(jié)束語
本文提供的信息絕非一個(gè)完整的清單。但它會(huì)讓您開始更好地理解和調(diào)優(yōu)JRockit JVM層！
參考資料
- JRockit調(diào)優(yōu)文檔
- JRocikit參考文檔：X Flags
- JRocikit參考文檔：XX Flags
- Henrik Stahl的Blog（JRockit的產(chǎn)品經(jīng)理）
- Marcus Hirt的dev2dev頁面（JRockit Tool團(tuán)隊(duì)的負(fù)責(zé)人）
附錄
以下內(nèi)容為正文引用過的額外信息。
性能測(cè)試期間的JRCMD/JRA
使用命令行或者基于JRockit Mission Control (JRMC) Eclipse的工具都能夠執(zhí)行JRA Recoding。我們可以使用JRMC連接到多個(gè) JRockit JVM，收集JRA recording，查看JVM的實(shí)時(shí)數(shù)據(jù)，檢測(cè)和排除內(nèi)存泄漏，以及查看應(yīng)用程序內(nèi)的潛伏物（執(zhí)行緩慢“點(diǎn)”）。有關(guān)如何運(yùn)行JRockit Mission Control，請(qǐng)參見下一節(jié)。
- 下載 文檔許可證。
- 將下載的license.bea文件添加到<JROCKIT_HOME>/jre目錄中。這樣，完整路徑將如下所示：<JROCKIT_HOME>/jre/license.bea
- 運(yùn) 行JRCMD如下：jrcmd.sh <PID> jrarecording filename=myrecording.xml time=600（該文件被寫入本地目錄或者指定的完整路徑／文件名）或jrcmd.sh <PID> print_threads。
- 使用脫機(jī)JRA工具分析最后得到的myrecording.xml.zip文件。通過在<JROCKIT_HOME>/bin中執(zhí)行JRA binary，將該JRA工具放入此目錄下。
- 請(qǐng)查看 JRCMD文檔。
JRockit Mission Control
- 使用JRockit將下列內(nèi)容添加到WebLogic Instance的啟動(dòng)行中：java -Xmanagement:autodiscovery=true,ssl=false,authenticate=false,port=7091
- 使用<jrockit-install-directory>/bin/jrmc.exe(sh)啟動(dòng)JRockit Mission Control
- 如有必要，將JR Mission Control的license.bea file文件添加到：<JROCKIT_HOME>/jre/license.bea
- 在Mission Control的幫助下，JRA Recordings、內(nèi)存泄漏、潛伏物探查和監(jiān)控能夠全部在一處完成。
堆/線程的測(cè)試期快照
- 創(chuàng)建一個(gè)簡(jiǎn)單的、名稱ctrhandler.act的文件并將其存放在<JROCKIT_HOME>/jre/bin/jrockit目錄。
- 執(zhí)行線程轉(zhuǎn)儲(chǔ)命令時(shí)，例如，kill -3)，JRockit會(huì)查看此文件并執(zhí)行命令列表。
- ctrlhandler.act文件應(yīng)該包含以下內(nèi)容：
#ctrlhander.act file located in the <JROCKIT_HOME>/jre/bin/jrockit directory
set_filename filename=./jrocket_control_breakoutput.txt append=true
timestamp
print_threads
timestamp
version
print_class_summary
print_object_summary increaseonly=true
print_threads
print_threads nativestack=true
print_utf8pool
timestamp
print_memusage
timestamp
heap_diagnostics
timestamp
# The following is optional and is another way to generate a JRA
recording
jrarecording filename=./myjra.xml time=600
在Linux上配置-XXlargePages
問題：為何使用largePages？
回答：使用largePages的優(yōu)點(diǎn)是可以鎖定堆內(nèi)存，并且不適用頁面交換（還可以減少IOWait和GC）。在實(shí)際內(nèi)存中，訪問堆中的對(duì)象明顯變快了。因此，為了實(shí)現(xiàn)性能目標(biāo)，largePages選項(xiàng)是一個(gè)理想的選擇。
- 如果機(jī)器支持大頁面，則cat /proc/meminfo的輸出將如下所示：
HugePages_Total: xxx
HugePages_Free: yyy
Hugepagesize: zzz KB
如果xxx為0，則沒有分配任何大頁面。
- 如果不為0，則需要使用CONFIG_HUGETLBFS(位于“File systems”下面)和CONFIG_HUGETLB_PAGE（當(dāng)CONFIG_HUGETLBFS被選時(shí)，自動(dòng)被選上）配置選項(xiàng)構(gòu)建Linux kernel。
- 接著，在Linux上分配大頁。注意：只允許根用戶分配大頁面。
- 裝載文件系統(tǒng)。JRockit使用hugepages文件系統(tǒng)，它駐留在內(nèi)存中。這些步驟可以完成文件系統(tǒng)的安裝。每次機(jī)器重啟時(shí)都需要完成實(shí)際裝載和chmod命令，或者也可以將其添加到一個(gè)/etc/rc.d/rc.local類型的文件：
mkdir -p /mnt/hugepages
mount -t hugetlbfs nodev /mnt/hugepages
chmod 777 /mnt/hugepages
- 分配大頁面。這是通過指定應(yīng)該分配的內(nèi)存數(shù)量來自動(dòng)執(zhí)行的。在分配過程中，這些面頁將被保留起來，不能像普通頁面那樣使用。它們的分配和解除分配方式如下：
echo 20 > /proc/sys/vm/nr_hugepages
此處，數(shù)字20指應(yīng)該保留的頁面數(shù)量。要解除分配，可以將分配頁面設(shè)置為0。（注意：請(qǐng)參見后面Q&A部分以確定正確的數(shù)量。）
如果并非所有請(qǐng)求的頁面都被保留，那么可用內(nèi)存就不夠了。如果確要如此，內(nèi)存很可能會(huì)有太多的碎片，那么我們的建議是重啟機(jī)器。請(qǐng)注意，大頁面不能被交換，所以一切都必須放在物理內(nèi)存中。
在RHEL3上，該文件的名稱為/proc/sys/vm/hugetlb_pool，所以可以使用以下命令執(zhí)行：
echo 500 > /proc/sys/vm/hugetlb_pool
這里的數(shù)字500指請(qǐng)求的大小為多少M(fèi)B，而不是頁數(shù)。如果JRockit不能夠直接消除臨時(shí)的大頁文件，請(qǐng)別忘記在執(zhí)行之后進(jìn)行消除。否則， 那些頁在被釋放之前將不可用。這對(duì)RedHat kernel build 2.4.18-e.25.smp適用，而2.4.18-e.12.smp卻不行。
問題：如何確定發(fā)給/proc/sys/vm/nr_hugepages的正確數(shù)量呢？
回答：因?yàn)橐獙⒄麄€(gè)Java堆放入largePages，所以必須根據(jù)堆的大小和頁面大小來確定。為/proc/sys/vm/nr_hugepages確定正確的數(shù)量就像下面的例子那樣簡(jiǎn)單，信息如下：
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)
注意：
盡管動(dòng)態(tài)設(shè)置大頁面的數(shù)量在理論上是可行的，但實(shí)踐中并非如此。減少大頁面的數(shù)量決不會(huì)有問題，但是增加大頁面的數(shù)量就會(huì)產(chǎn)生問題。原因是，為了創(chuàng)建一個(gè)大頁，Linux需要在內(nèi)存中找到足夠大的連續(xù)的區(qū)域。如果找不到，就不能創(chuàng)建大頁面。
剛啟動(dòng)系統(tǒng)時(shí)，內(nèi)存的碎片還不是很多，所以要找到足夠大的連續(xù)的區(qū)域并不是問題。但機(jī)器運(yùn)行時(shí)間一長，內(nèi)存會(huì)產(chǎn)生更多的碎片。所以，如果要確保能夠分配足夠大的頁面，就必須在啟動(dòng)剛完成時(shí)通過啟動(dòng)腳本或手動(dòng)設(shè)置它們。
原文出處：http://dev2dev.bea.com/pub/a/2007/12/jrockit-tuning.html
