JAVA虛擬機JVM優化重要性,昨天JAVA虛擬機JVM參數優化(1)文章中已經描述,今天我們來討論JAVA虛擬機在不同性能要求下如何選擇三種垃圾收集算法。
JVM內部結構如下圖所示:
串行收集用于單個線程執行垃圾收集的情況,在這種情況下相對它是有效的,因為它不需要和其他線程進行通訊。它適用于單個處理器機器,或者在多處理器情況下數據量小于100MB。串行收集通過參數?-XX:+UseSerialGC聲明工作。
并行收集通過并行較小的收集來降低整個垃圾收集周期。中等或者大型數據量的應用運行在多處理和多線程建議采用并行收集,它通過參數-XX:+UseParallelGC聲明工作。并行壓縮是允許并行收集器并行執行主要集合的功能。如果不進行并行壓縮,則使用單個線程執行主要集合,這會顯著限制可伸縮性。如果指定了-xx:+useParallelGC選項,則默認情況下啟用并行壓縮。關閉它的選項是-xx:-UseParallelOldGC。
大多數并發收集器同時執行其大部分工作(例如,當應用程序仍在運行時),以縮短垃圾收集暫停時間。它是為具有中型到大型數據集的應用程序設計的,在這些數據集中,響應時間比總吞吐量更重要,通過用于最小化暫停的技術會降低應用程序性能。Java熱點VM提供了兩個主要并行收集器之間的選擇;參見大多數并發收集器。使用選項-xx:+UseConcMarkSweepGC啟用CMS收集器或-xx:+UseG1GC啟用g1收集器。
選擇收集器
除非應用程序有相當嚴格的暫停時間要求,否則首先運行應用程序并允許VM選擇一個收集器。如有必要,請調整堆大小以提高性能。如果性能仍然不符合您的目標,那么使用以下準則作為選擇收集器的起點。
如果應用程序有一個小的數據集(高達大約100 MB),則
使用選項-xx:+UseSerialGC選擇串行收集器。
如果應用程序將在單個處理器上運行,并且沒有暫停時間要求,那么讓虛擬機選擇收集器,或者使用選項-xx:+UseSerialGC選擇串行收集器。
如果(a)應用程序性能峰值是第一優先級,并且(b)沒有暫停時間要求,或者可以接受1秒或更長的暫停,那么讓虛擬機選擇收集器,或者使用-xx:+useParallelGC選擇并行收集器。
如果響應時間比總吞吐量更重要,并且垃圾收集暫停時間必須保持短于約1秒,則使用-xx:+useConcMarkSweepgc或-xx:+UseG1GC選擇并發收集器。
這些準則僅為選擇收集器提供了一個起點,因為性能取決于堆的大小、應用程序維護的活動數據量以及可用處理器的數量和速度。暫停時間對這些因素特別敏感,因此前面提到的1秒閾值只是近似值:在許多數據大小和硬件組合上,并行收集器將經歷超過1秒的暫停時間;相反,在某些組合上,并發收集器可能無法保持低于1秒的暫停時間。
如果推薦的收集器沒有達到所需的性能,請首先嘗試調整堆和生成大小以滿足所需的目標。如果性能仍然不足,請嘗試其他收集器:使用并發收集器減少暫停時間,并使用并行收集器增加多處理器硬件上的總吞吐量。
SPEC JBB2015MULTI測試結果分析
選取SPEC JBB2015MULTI測試結果中Java HotSpot 64-bit Server VM,version 1.8.0_131,廠商報告Cisco思科、DELL戴爾、H3C華三、HP、Inspur浪潮、Levovo聯想、Quanta臺灣廣達。
我們選取每個廠商中得分最高的測試結果,并且按使用堆內存數量大小升序排,如下所示。
Inspur Corporation Inspur NF5280M4 256GB/29GB 39635
-server -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:+UseLargePages -XX:+UseParallelOldGC -Xms29g -Xmx29g -Xmn27g -XX:SurvivorRatio=28 -XX:TargetSurvivorRatio=95 -XX:ParallelGCThreads=22 -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
Quanta Computer Inc. QuantaGrid D52B-2U 384GB/30GB 40874
-showversion -server -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:+UseParallelOldGC -XX:SurvivorRatio=28 -XX:TargetSurvivorRatio=95 -XX:MaxTenuringThreshold=15 -Xms30g -Xmx30g -Xmn27g -XX:ParallelGCThreads=28
PowerEdge R640 786GB/180GB 69059
-showversion -server -XX:+AlwaysPreTouch -XX:+UseParallelOldGC -XX:-UseAdaptiveSizePolicy -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:-UseBiasedLocking -XX:+AggressiveOpts -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:SurvivorRatio=26 -XX:TargetSurvivorRatio=95 -Xms180g -Xmx180g -Xmn178g -XX:ParallelGCThreads=28 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
Lenovo Global Technology ThinkSystem SR650 768GB/350GB 114309
-server -Xms350g -Xmx350g -Xmn340g -XX:SurvivorRatio=40 -XX:MaxTenuringThreshold=15 -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+UseParallelOldGC -Xnoclassgc -XX:+AggressiveOpts -XX:+AlwaysPreTouch -XX:-UseAdaptiveSizePolicy -XX:-UsePerfData -XX:TargetSurvivorRatio=98 -XX:ParallelGCThreads=56 -XX:-UseBiasedLocking -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps
H3C UniServer R4900 G3 1536GB/710GB 120287
-XX:+UseParallelOldGC -Xms710g -Xmx710g -Xmn690g -XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:SurvivorRatio=48 -XX:TargetSurvivorRatio=90 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15
Hewlett Packard Enterprise ProLiant DL380 Gen10 1536GB/735GB 117090
-XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:+UseParallelOldGC -Xms735g -Xmx735g -Xmn681g -XX:SurvivorRatio=68 -XX:TargetSurvivorRatio=48 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseRTMLocking -XX:InlineSmallCode=10k -XX:MaxGCPauseMillis=300
Cisco UCS C240 M5 1536GB/710GB jOPS:118551
-XX:+UseParallelOldGC -Xms710g -Xmx710g -Xmn690g -XX:-UsePerfData -server -XX:AllocatePrefetchInstr=2 -XX:LargePageSizeInBytes=2m -XX:+AggressiveOpts -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UseBiasedLocking -XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256m -XX:+UseLargePages -XX:SurvivorRatio=48 -XX:TargetSurvivorRatio=90 -XX:ParallelGCThreads=56 -XX:MaxTenuringThreshold=15
從上面數據可以得知SPEC JBB2015都是為了達到吞吐量最大化,再優化響應時間性能,因此所有廠商都不約而同選擇了-server 默認并行收集,同時關閉默認并行壓縮算法,開啟-XX:+UseParallelOldGC;垃圾收集并行線程數-XX:ParallelGCThreads 設置為服務器總核數 56 28,加快并行收集效率
在堆劃分-XX:-UseAdaptiveSizePolicy 采用系統自動適應策略;-XX:SurvivorRatio=28 48 ,盡可能把堆留給年輕對象;-XX:MaxTenuringThreshold=15對象被計數15次才會分配到老年;-XX:TargetSurvivorRatio=95
測試機器都普遍內存多,因此都使用了XX:+UseLargePages -XX:LargePageSizeInBytes=2m 優化大內存
另外-XX:+AggressiveOpts -XX:+AlwaysPreTouch -XX:-UseBiasedLocking這3個指令所有廠商也都不約而同使用
HP惠普還使用-XX:MaxGCPauseMillis=300參數,限制最大一次垃圾收集停頓時間。
總結:JVM調優中最重要還是堆內存的準確預估,可以通過JVM監控來掌握,選擇并行垃圾收集普通情況下優于其他串行和并發收集。通過SPEC測試分析可以了解JVM并行收集影響性能最重要的參數,大部分廠商使用的參數基本相同。
文章參考: