java - -Xmxの大きな値は、ガベージコレクションを延期しますか？

Question

32GBの物理メモリと32GBの仮想メモリを備えたLinuxRedhatで多くのJVMを実行しています。これらのJVMは、Xmxの合計値が32GBを超えるように構成されており、Linuxが仮想メモリを使用している可能性があります。
私の質問は、必要なヒープサイズよりも多くのXmxを指定すると、ガベージコレクションが遅延し、その結果、必要以上のヒープサイズが割り当てられるということです。そのため、OSは仮想メモリからメモリを割り当て、パフォーマンスが低下します。

Answer 1

JVM は、起動時に最大ヒープ サイズ (および他のメモリ領域) を予約します。これは、最大ヒープ サイズが 32 GB の場合、共有ライブラリ スレッドなどを含む約 33 ～ 35 GB の仮想メモリを使用することを意味します。

最大ヒープ サイズを 32 GB にすると、64 ビット参照を使用する必要があり、最大ヒープが 24 GB の JVM よりも使用可能なメモリが少なくなる可能性があり、32 ビット参照を使用します。一部の人々は、ヒープ サイズを 32 GB 以上にすると、使用可能なメモリを増やすために 48 GB に増やす必要があると見積もっています。

マシンのサイズを考慮して、ヒープを 24 GB (またはそれ以下) に制限し、可能な場合はオフ ヒープ メモリを使用することをお勧めします。これにより、パフォーマンス上の利点とスケーラビリティの両方が得られるからです。

GC プログラムが少なく、コレクションを避けたい場合は、大規模な Eden サイズを作成し、GC を 1 日または 1 週間に 1 回行うことができます。これを行うには、ガベージを最小限に抑える必要があり、たとえば 20 GB の Eden サイズを作成できます。この場合、1 日に 20 GB 未満を作成すると、GC (マイナーなものであっても) のトリガーを回避して実行できます。夜間の保守作業としての完全な GC。たとえば、午前 2 時。

大きなヒープを使用する場合は、スワップの使用を絶対に避けたいと考えています。これは、GC がヒープへのランダム アクセスを必要とし、スワップするのに十分な大きさのトリガーが 1 つトリガーされるとすぐに、マシンがかなり長い時間 (場合によっては数時間) スラッシングし、ロックアップする可能性があるためです。マシンを正常に動作させるために再起動する必要がある場合もあります。(このような状態のプロセス/マシンを強制終了することは困難です)