visualvmのヒープグラフを理解する

Question

私は本質的にディスクから多くのファイル（通常は10MB + XMLサイズのKb未満の混在したPDF）を読み込み、レガシーシステムに一度に1つずつアップロードするプログラムを持っています。週末には視覚的に動かして、今朝はヒープの使い方が、プログラムを実行するのにかかった時間にむしろ不均一であることを示すグラフに戻りました。私は時間の経過とともにヒープの使用量がほぼ均等になることを期待していました。

私はこれについての説明を探しています。これは、4コアi5-2400（ハイパースレッディングなし）で32 GBのRAMを搭載したUbuntu 17.04（デスクトップではなくサーバー）上の64ビットOracle JVMです。このプログラムは本質的にコアの約50％を利用するシングルスレッドであり、実行する予定の時間がかかりました。

メモリが完全に使用されていないと、時間の経過と共に解放されることを理解します。私は負荷がかなり均等に分散されるべきであるので、使用量が時間の経過と共に低下することを理解していません。システムがアイドル状態になっているときにCPUスロットルの結果が表示されますか？ JVMの最適化が始まっていますか？

Answer 1

実際のGCログが役立ちますが、スループットを満たして時間の目標を一時停止するために、若いヒープサイズと古いヒープサイズに関する決定を調整するのはおそらくGCヒューリスティックです。

JVMに制限を設けない限り、プログラムの実行を維持するために、喜んで最小限のメモリより多くのメモリを使用します。それがなければ非常に頻繁で非効率的なGCが発生します。すなわち、ヒープサイズ= n *ライブオブジェクトセットサイズn> 1.使用するコレクタによっては、ParallelGCはデフォルトでMaxHeapFreeRatioが100になり、G1が70を使用するため、使用可能なメモリ以外のnの上限はありません。

ヒューリスティックは完璧ではありませんが、いくつかのエッジケースでコーナーにペイントしたり、さまざまな平衡点の間で不必要に変動したりする可能性があります。しかし、グラフそのものは問題を示すものではありません。