VisualVMはメモリ使用量を監視します

Question

Tomcat の起動時に、 -xms 、 -xmx を 1GB に設定しました。メモリを監視するときに VisualVM 内で

1. メモリのサンプリングを行うと、「スナップショット」を押してメモリを利用している Java クラスが正しいパターンとインスタンスのカウントを表示するまで、正確なメモリ使用量は表示されません。なぜこのような？

2. また、Tomcat のメモリを 1GB に設定すると、メモリは zip-zat で増加し続け、約 960MB になります。「perform gc」を押してメモリが 200mb に戻るまで。

3. 毎日深夜に jvm 上で Perform.gc() を強制的にヒットさせるスケジューラーを作成する必要があると思いますか?

私の説明からのコメント

Answer 1

ここでわかるのは、ガベージ コレクターが若い世代のクリーンアップを同時に実行していることですが、ヒープが常に撹拌されているため、古い世代のコレクションのすべての参照を取得できないということです。[GC 実行] ボタンを押すと、すべてのスレッドをブロックし、ヒープをフリーズして、より大規模なコレクションが発生できるようにする「stop-the-world」コレクションが実行されます。ここでの私の主な懸念は、大規模なコレクションが (x 時間後) 発生するかどうかです。ヒープが小さいと OutOfMemory エラーが発生しますか?

1) 自動更新ボタンがオンになっていますか?また、プロファイラーがスナップショットを取得する前に小さな GC (Eden スペース) を実行する可能性もあります。

2) これは完全に正常です。ガベージ コレクションには時間とリソース (プロセッサ サイクル) がかかります。ヒープを大きなサイズに設定した場合、そのサイズの一定の割合に達するまで、ガベージ コレクション自体がトリガーされるまで待機します。デフォルトの空き領域とライブ オブジェクトの比率は 40% から 70% の間だと思います。Tomcat がバージョン 5 あたりでガベージ コレクションの方法を特に変更したことは知っています。Tomcat v4 はガベージ コレクターの実行に多くの時間を費やしたため、パフォーマンスの問題がありました。ここで調査を行って、Tomcat にカスタム ガベージ コレクション オプションがあるかどうかを確認してください。

3) いいえ。ほぼ完全なヒープこそがあなたが目指しているものです。フルガベージコレクションにそれほど時間がかからないように、ヒープを小さくするのが合理的かもしれません。これは、大量のガベージ コレクション (一時停止) と長時間のガベージ コレクション (長い一時停止) の間のトレードオフです。アプリごとに異なるため、通常はデフォルトから開始し、必要に応じて微調整します。興味があれば、ガベージ コレクション (および代替コレクター) のオプションがたくさんあります。

Java 5

Java6 よくある質問, 白書