MinecraftでG1GCを使ったメモ
2GBの Incremental CMS でぼちぼち動いていて、6GBも割り当てるのは避けたいという環境で、G1GCどないやろって試した記録。実用レベルにはなったのでしばらく動かしてみるけど、そこまでメリットは…という感じ。
-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCCause を付けて起動しては GCViewer に食わせて眺めるの繰り返しをしていた。
- 起動完了時に FullGC を手動で実行しているっぽいが、今の構成ではそこまでメリットがないので1secをケチって -XX:+DisableExplicitGC をつける -> いい感じ
- Young:Tenuredをガッと1G:2Gにしてみる -> GC回数やトータルの時間こそ減っても、最大の停止時間が延びてしまった。恐らくレンダリング周りを中心に短命なオブジェクトが多いので、まとめて掃除するよりは頻繁に片づけた方が停止時間は少なくてすむ。それはそう。
-Xmx2G -Xms2G -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:-UseAdaptiveSizePolicy -XX:+DisableExplicitGC -Xmn128m
で、G1GC。
- XX:MaxGCPauseMillisを守ろうと頑張ってくれるのだけど、調子にのってYoungがヒープの半分ほどを持っていってしまうことがあり、移動先がなくてFullGCが走ってしまった。
- -XX:InitiatingHeapOccupancyPercent=30 -XX:G1ReservePercent=30 で積極的にmixedを走らせ余裕も持たせると流石に失敗することはない感じ。でも時々カクつく。やっぱりYoungを絞ることを考えた方がよいのでは。
- -XX:G1MaxNewSizePercent で十分に絞ると心なしか停止時間も短かくなる?
- じゃいっそXmnで固定してもいいのではとなるけど、それならCPU負荷低い分CMSでよくない?という感じが。
- どうせTenuredはなかなか埋まらないので、InitiatingHeapOccupancyPercent は MaxNewSize 近辺かより小さいぐらいでないと意味なさそう。となった時に Young を絞って young GC に仕事してもらう vs InitiatingHeapOccupancyPercent だけ下げて積極的に mixed GC してもらう、みたいなことを思ったけれど、ワーストケースを抑制するにはやはり Young を絞ったほうがいいかなあという感じ。
- 基本的に潤沢なメモリとCPUが前提というか、それを有効活用してスループットや停止時間を改善する感じはある(12Gもあればいい感じに動くのだろうな)
-Xmx2G -Xms2G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:G1MaxNewSizePercent=20 -XX:G1ReservePercent=30 -XX:MaxGCPauseMillis=20 -XX:+DisableExplicitGC
どうせそういう運用になるならと2GBにしてみたけど、主に3とか4とかで試していた。
参考
いろいろ読んだけどよーわからんマン。
GC全般とか
- まじめにJVMチューニング: 第2回 GCログをみる
- JVMのチューニング - ITエンジニアとして生きる
- JVMオプション | Java | 技術メモ | TOYATAKU WEB
- 利用しそうなJava実行時のオプション - なみひらブログ
G1GCの話
- G1 GC おさらいと #jjug_ccc で発表した話 - sugarlife's blog 猫でもわかりそうなスライド
- ガベージファースト・ガベージ・コレクタ Oracleのやつ
- 【Java】G1GCに使用するオプションについて - TASK NOTES
- Controlling GC pauses with the GarbageFirst Collector - Tuning Guidelines for Java Garbage Collection, Part 3 « mgm technology blog
- G1GCのつかいどころメモ - nekop's blog
- JVMチューニング: G1GCの使いどころとCMS GCからのマイグレート