ehcache のようなオンヒープ キャッシュにはどのくらいのデータが多すぎますか?
24GB RAM サーバーを取得しています。おそらく最初は 2 ～ 4 GB をキャッシュに割り当てますが、最終的には 20 GB 程度をキャッシュに割り当てることになるかもしれません。オンヒープ キャッシュの GC に時間がかかりすぎることをどの時点で心配する必要がありますか?
ところで、利用可能なオープン ソースのオフ ヒープ キャッシュは DirectMemory だけですか? プライムタイムの準備はできていますか？
JVM、特に使用するGCによって異なります。特に古いGCは、実際には非常に大きなヒープを処理できませんでしたが、それを修正するための取り組みが増えています。
たとえば、Azulシステムは、特別なGCのおかげで、数百GBのヒープを備えたハードウェアを問題なく販売しています（つまり、gcは30分ではなくmsで一時停止します）。したがって、Java自体の制限はありません。しかし、ホットスポット/IBMが時間の経過とともにどれほど優れているかはわかりません。しかし、24GBのヒープはとにかくそれほど大きくはありません-G1はおそらくそこで十分な仕事をするはずです。
大きなキャッシュの主な問題は、完全な GC 時間です。目安としては、1 GB あたり 1 秒かもしれません (これはアプリケーションによって異なります)。20 GB のキャッシュがあり、アプリケーションが 20 秒ごとに一時停止する場合、それは許容できるでしょうか?
ダイレクト ファイルとメモリ マップ ファイルのファンとして、私はいつデータをヒープから離すのではなく、簡単にするためにヒープを使用するのかを考える傾向があります。;) メモリ マップされたファイルは、サイズに関係なく、完全な GC 時間にほとんど影響しません。
メモリ マップド ファイルを使用する利点の 1 つは、物理メモリよりもはるかに大きくても、十分なパフォーマンスを発揮できることです。これにより、OS は、どの部分をメモリに入れ、何をディスクにフラッシュする必要があるかを判断します。
ところで: より高速な SSD を使用することも役立ちます ;) 大容量のドライブも同様に高速になる傾向があります。実行できる IOP を確認します。
この例では、16 GB のマシンにマップされた 8 TB のファイル メモリを作成します。http://vanillajava.blogspot.com/2011/12/using-memory-mapped-file-for-huge.html
80 GB のファイルの例ではパフォーマンスが向上することに注意してください。8 TB はオーバーキルになる可能性があります。;)
オンヒープ キャッシュの GC に時間がかかりすぎることをどの時点で心配する必要がありますか?
長すぎるってどれくらい？
真面目な話、「スループット」ガベージ コレクターを実行していて、これにより一時停止が長すぎる場合は、一時停止の少ないコレクターに切り替えてみてください。例: CMS または G1。