読書会(Javaパフォーマンス)第3回議事録
[ 戻る ]
=====================================================================================
Java読書会BOF 「Javaパフォーマンス」を読む会 第3回
=====================================================================================
.. csv-table:: 開催概要
"日時", "2015年08月22日 10:00 - 17:00"
"場所", "川崎市教育文化会館 第３会議室"
"出席者(敬称略)", "高橋(徹)、高橋(智)、遠藤、根本、後藤、岩室、吉本、若菜、川崎、小棚木、村山、門脇、中澤(書記)"
5.1.3.2 ガベージコレクションのアルゴリズムとスループットの測定
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* TPS=transactions per second
* ここでのtransactionとは1requestのことか、1responseのことか?
* concurrent mode failure
* 辞書によるとfailureは不足のような意味もある
* この間はアプリケーションスレッドが止まる
* これは致命的で失敗といっていいのでは
5.1.3.3 ガベージコレクションのアルゴリズムとレスポンスタイムの測定
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* スループット型
* リクエスト数50個になると、レスポンスタイムの99パーセンタイル値が一気に悪化している
5.1.3.4 CMSとG1の測定
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* アプリケーションを分割すれば、一つ一つのヒープサイズは小さく出来る
* EclipseやNetBeansなどのGUIアプリはレスポンスタイムが悪化しにくいCMSの方がよいだろう
* Java9ではG1GCがデフォルトになるとアナウンスされている
5.2 ガベージコレクターの基本的なチューニング
--------------------------------------------------------------------------------
5.2.1 ヒープサイズの変更
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Linux/Solarisの64bitJVMのデフォルトの最大ヒープサイズ候補が32GBとかなり大きい
* 圧縮ポインタで管理できる上限に合わせているのでは
5.2.2 各領域のサイズ設定
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5.2.3 permanent領域とメタスペースのサイズ変更
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* permanent領域のトラブルは意外とある
* Eclipseの初期値は小さい
* DIを多発させる設計だとクラスオブジェクトを大量に生成してしまい
* 古いクラスローダが残ってしまう場合は、nativeメモリの開放もしておいたほうがよい
* JNIが多用する環境でnativeメモリが足りなくなっていても、out of memoryも出ないので原因解析がしにくい
* 3,4回auto deployが走るとout of memoryが発生するようなことがあった
* auto deployは開発時だけにしておいたほうが良さそう
5.2.4 並列度の指定
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* デフォルトのGCスレッド数は大きくなりがち(特に1マシンで複数JVMが稼働している場合)
* オプションでGCスレッド数を指定すべき
5.2.5 adaptive sizing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5.3 ガベージコレクション関連のツール
--------------------------------------------------------------------------------
5.4 まとめ
--------------------------------------------------------------------------------
* GCViewerより、GC Histogramの方がviewerの種類が豊富で見やすい
* 実務でGCの種類とヒープサイズ以外のチューニングをやることはあまりない
6章 ガベージコレクションのアルゴリズム
================================================================================
6.1 スループット型ガベージコレクターを理解する
--------------------------------------------------------------------------------
* マイナーGCの場合でも、survivorがいっぱいだと、edenからoldに直接移動する場合もある
* JDK添付のjvisualvmにプラグイン"Visual GC"を入れると、GCの挙動がGUIで見れるようになる
* デフォルトではsurvivorはedenの3分の1くらいのサイズ
* なるべくeden領域から他の領域に移動しないでオブジェクトが廃棄された方が、世代別GCとしては効率が良い
6.1.1 適応的あるいは静的なヒープサイズのチューニング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* GCTimeRatioはアプリケーションスレッドの処理時間が、GCスレッドの処理時間の何倍かを表す
* これをどの程度の値にすべきか決めるのは難しそう
6.2 CMSガベージコレクターを理解する
--------------------------------------------------------------------------------
* コンカレントフェーズでも、young領域からold領域への移動があり得る
* GCの起点 -> rootオブジェクトを全て探すが、それらを参照するオブジェクトのマークはまだ行わない
* scrub string tableは、Stringのinternが関係しそう
* precleanフェーズは最初のマーク後に、増減したオブジェクトの検知する処理か?
* コンカレントサイクルはold領域を解放するものだが、initial markではyoung領域のオブジェクトも考慮する必要がある
* sweepフェーズ中でもマイナーGCであれば割り込んでも大丈夫
* これからsweepするold領域のcompactionは実施されないため
* "old領域には504メガバイト..."
* 6.1や6.2の説明からすると、504メガバイトはヒープ全体のサイズでは?
6.2.1 concurrent mode failureを回避するためのチューニング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.2.1.1 バックグラウンドのスレッドの実行頻度を上げる
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6.2.1.2 バックグラウンドのスレッドを増やす
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
* CPU数を数えるのはJVM起動時か?
* hot plugで動的に、物理的にCPUを増やすことは可能なマシンもあるが、OSやJVMから見て増えるのか?
6.2.2 permanent領域のためのCMSのチューニング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.2.3 iCMS
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.3 G1ガベージコレクターを理解する
--------------------------------------------------------------------------------
* 巨大な割当とは、1つのオブジェクトが1つのリージョンのサイズを超えるような場合か?
* CMSと比較したとき、G1の優位性は?
* リージョンに分けていることで、ヒープが大きくなってもGCの停止時間が大きくなりにくい
6.3.1 G1のチューニング
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.3.1.1 バックグラウンドのスレッドのチューニング
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6.3.1.2 G1の実行頻度を増減させる
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6.3.1.3 混合ガベージコレクションのチューニング
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6.4 高度なチューニング
--------------------------------------------------------------------------------
* どのような場合に昇格の禁止すべきか?
* IOTなどの組み込みとか?
* -XX:NeverTenureは"never"とあるが、old領域に絶対移動しない訳でなく、なるべく移動しないようになるだけ
6.4.1 昇格とsurvivor空間
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.4.2 大きなオブジェクトの割り当て
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6.4.2.1 TLAB
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. note:: 次回は、p.179「6.4.2.2 TLABのサイズ変更」から。
[ 戻る ]