JVM用に巨大なヒープスペースを正しく割り当てる方法

Question

私はしばらくの間、私を悩ませている問題を回避しようとしています。一言で言えば、リソースホギングアプリケーションのために最大限のヒープスペースを割り当てるべきベースはどれですか？また、タイが大きすぎるために欠点がありますか？

巨大な医療データを視覚化するためにアプリケーションを使用しています。イメージングボリュームをいくつか並べて開くと、最大数ギガバイトのメモリを消費する可能性があります。流暢なワークフローには、表示するデータをキャッシュすることが不可欠です。このソフトウェアはWindowsワークステーションでサポートされており、ヒープサイズを割り当ててメインアプリケーションを起動するブートローダで起動します。メインアプリケーションが必要とする実際のメモリは、表示されるデータに正比例し、データを読み込む必要があり、最終的には時間がかかりすぎるため、ブートローダでは判別できません。

したがって、起動時に十分なメモリが確保されるように、現在の設計では、ワークステーションの最大物理メモリに基づいてxmxを大きく設定します。しかし、これには何か欠点がありますか？私はネイティブプロセスが余分なヒープスペースを掘り下げて実行時にメモリエラーを引き起こす可能性があることを（2008年の記事から）読んだことがあります。ヒープスペースを割り当てる前に、無料の仮想メモリまたはページングファイルサイズを調べるべきでしょうか？このような状況にどう対処しますか？

ああ、これは私のこれらのフォーラムへの最初の投稿です。あなたにすべてお会いして、穏やかになってよかった！ :)

更新日：すべての答えのための

感謝。私は私の言葉を正しく置くかどうか分からないが、私の問題は、私はこのソフトウェアが実行されるハードウェアについての知識はないが、それにもかかわらず、可能な限り多くのヒープスペースを割り当てること。

利用可能な仮想メモリが十分にある場合は、物理メモリの70％のヒープを割り当てる方法がありました。

Answer 1

ラージオブジェクトを使用すると、ヒープサイズは約28 GBになり、パフォーマンスにほとんど影響しません。

ヒープサイズは100 GBでも可能ですが、主に停止時間が長いためです。 Azul Zingを使用すると、ヒープサイズを大幅に大きくすることができます。

主な制限は、メモリのサイズです。ヒープがそれを超えると、アプリケーションとコンピュータは非常に遅くなり、使用できなくなります。

マッピングソフトウェア（これらの問題を回避するための標準的な方法）は、画像をタイルに分割することです。この方法では、1つの画面（または画面上にある部分）のみを表示することができます。ズームインとズームアウトが必要な場合は、2〜4段階のスケールでデータを保存する必要があります。このアプローチを使用すると、世界中の地図を携帯電話で表示できます。

Answer 2

JVMの最大メモリをワークステーションのメモリの60〜70％を超えないように設定するのが最善です。まず、JVMが物理マシン上で消費するものは、GCメカニックによってヒープよりも20％以上大きくなる可能性があります。第2に、JVMヒープ内の特定のデータエンティティの表現は、マシンのRAM内のそのエンティティの唯一の物理コピーではない可能性があります.OSには、これらのオブジェクトを取得するさまざまなIOデバイスの周りにキャッシュやバッファなどがあります。