對hbase調優，是很必要的，明顯提升響應性能。下面曬下GC調優的成果，是原來CMS GC峰值的10%，曆史均值的20%左右 ，調優後GC穩定在200ms左右。
之前是CMS GC不過忘了記錄原始的GC配置了。
Parallel GC : Throughput friendly 目前處于維護模式，趕緊放棄吧
CMS GC: low latency for heap < 32GB 将會被G1GC取代
G1 GC: low latency 一鍵GC 調優，自适應，通用性強。
G1GC 并發标記 ，自動compaction， 調優簡單，低延遲+可預測的延遲時間。
下面是采用G1 GC調優之後的結果圖，不用說，很犀利。
可以采用 YCSB client進行 各 50%讀寫壓力測試
分時GC時間
月度GC時間
目前regionserver 40% BlockCache 40% Memstore .
JVM 參數，官方指出JVM參數對于負載影響比較小，建議添加參數進行監控。
-XX:+UseG1GC #開啟G1GC
-XX:InitiatingHeapOccupancyPercent=70 #當達到heap大小的70%時進行提前啟動标記周期進入Mixed GC
-XX:+PrintFlagsFinal -XX:+PrintReferenceGC # 列印GC辨別,引用
-XX:+UnlockExperimentalVMOptions -XX:-ResizePLAB # 取消 記憶體整理，G1GC 天生優勢
-XX:G1NewSizePercent=3 # 3-9Minimum size for Eden each epoch, differs by cluster
-XX:MaxGCPauseMillis=200 # 期待的最大停留時間，未必滿足
-XX:+UnlockDiagnosticVMOptions
-XX:+G1SummarizeConcMark
-XX:+ParallelRefProcEnabled #Helps keep a lid on reference processing time issues were were seeing
-XX:+PrintGCDetails
-XX:+PrintAdaptiveSizePolicy # 自适應政策，調節Young Old Size
-XX:G1HeapRegionSize=32M # hbase heap > 32G時
-XX:G1HeapWastePercent=20 #Exclude most expensive Mixed GC by increase waste percent (default=5%)
-XX:ConcGCThreads=8 # concurrent marking phase can be completed early enough to avoid full GC
-XX:ParallelGCThreads=13 # 8+(logical_processor -8)*(5/8)
配置GClog 日志
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime # 列印應用停留時間
-XX:+PrintTenuringDistribution # 老年代分布
-Xloggc:./region-server-gc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=2
-XX:GCLogFileSize=512M
下面的參數是jmx監控使用的
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.port=22222
借鑒了衆多G1GC調優得到的結果。
G1 GC常用參數
我在這裡所羅列的參數的預設值都是基于JDK8u45，是以可能後續的JDK版本會有些值不一樣，這個讀者可以直接通過JDK的官方幫助文檔擷取最新預設值資訊。
-XX：+UseG1GC：啟用G1 GC。JDK7和JDK8要求必須顯示申請啟動G1 GC，JDK可能會設定G1 GC為預設GC選項，也有可能會退到早期的Parallel GC，這個也請關注吧，JDK9預計2017年正式釋出；
-XX：G1NewSizePercent：初始年輕代占整個Java Heap的大小，預設值為5%；
-XX：G1MaxNewSizePercent：最大年輕代占整個Java Heap的大小，預設值為60%；
-XX：G1HeapRegionSize：設定每個Region的大小，機關MB，需要為1，2，4，8，16，32其一，預設是堆記憶體的1/2000。前面我們講過大對象概念，如果這個值設定比較大，那麼大對象就可以進入Region了，同樣地，這樣做的壞處是直接幹預了各年齡代的配置設定大小；
-XX：ConcGCThreads：與Java應用一起執行的GC線程數量。預設是Java線程的1/4。減少這個參數的數值可能會提升并行回收的效率，即提高系統内部吞吐量（系統是一個整體，CPU資源大家都需要占用），不過如果這個數值過低，也會導緻并行回收機制耗時加長；
-XX：+InitiatingHeapOccupancyPercent(簡稱IHOP)：G1内部并行循環啟動的設定值，預設為Java Heap的45%。這個可以了解為老年代空間占用的空間，GC收集後需要低于45%的占用率。這個值主要是為了決定在什麼時間啟動老年代的并行回收循環，這個循環從初始化并行回收開始，可以避免Full GC的發生；
-XX：G1HeapWastePercent：G1不會回收的記憶體大小，預設是堆大小的5%。GC會收集所有的Region，如果值達到5%，就會停下來不再收集了； -XX：G1MixedGCCountTarget：設定并行循環之後需要有多少個混合GC啟動，預設值是8個。老年代Regions的回收時間通常比年輕代的收集時間要長一些，是以如果混合收集器比較多，可以允許G1延長老年代的收集時間；
-XX：+G1PrintRegionLivenessInfo：這個參數需要和-XX：+UnlockDiagnosticVMOptions配合啟動，這可以了解，它們本身就是屬于VM的調試資訊。如果開啟了，VM會列印堆記憶體裡每個Region的存活對象資訊。這個資訊在标記循環結束後可以列印出來；
-XX：G1ReservePercent：這個值是為了保留一些空間用于年代之間的提升，預設值是堆空間的10%。注意這個空間保留後就不會用在年輕代了，大家可以看到GC日志裡輸出顯示，我們大量執行的是年輕代回收，是以如果你的應用裡面有比較大的堆記憶體空間、比較多的大對象存活，那還是減少一點保留白間吧，這樣會給年輕代更多的預留白間、GC之間更長的處理時間；
-XX：+G1SummarizeRSetStats：這個也是一個VM的調試資訊。如果啟用，會在VM推出的時候列印出RSets的詳細總結資訊。如果啟用-XX：G1SummaryRSetStatsPeriod參數，就會階段性地列印RSets資訊；
-XX：+G1TraceConcRefinement：這個也是一個VM的調試資訊。如果啟用，并行回收階段的日志就會被詳細列印出來；
-XX：+GCTimeRatio：大家知道，GC的有些階段是需要Stop-the-World，即停止應用線程的，這個參數就是計算花在Java應用線程上和花在GC線程上的時間比率，預設是9。這個參數主要的目的是讓使用者可以控制花在應用上的時間，G1的計算公式是100/（1+GCTimeRatio），這樣如果采用9，則最多10%的時間會花在GC工作上面。Parallel GC的預設值是99，表示1%的時間被用在GC上面，這是因為Parallel GC貫穿整個GC，而G1則根據Region來進行劃分，不需要全局性掃描Java Heap；
-XX：+UseStringDeduplication：手動開啟Java String對象的分割工作，這個是JDK8u20之後新增的參數，主要用于相同String避免重複申請記憶體，節約Region的使用；
-XX：MaxGCPauseMills：G1停止執行的一個目标值，機關是毫秒，預設是200毫秒，這個值不一定真的會達到。這個參數會通過控制年輕代的大小來實作目标。
線上GC日志分析 http://gceasy.io
線上dump檔案分析 http://fastthread.io/
http://blog.jobbole.com/109170/
https://blogs.apache.org/hbase/entry/tuning_g1gc_for_your_hbase
counter