第一に、これほど多くのアドレス空間のプレッシャーがあるときに 32 ビット OS を実行するのは気が狂っています。64 ビット Linux 上の 64 ビット JVM に移行します。64 ビット システムのより大きなアドレス空間で解決されると最初から疑っていたに違いないこの問題を診断しようとして、すでにどれだけの時間を無駄にしましたか?
第二に、すべての Linux ベンダーの中で Red Hat が最も多くのカーネル エンジニアをスタッフに抱えており、RHEL 製品のカーネルにいくつかの重大な調整を行っていることはよく知られています。これらには、多くの場合、あなたのような大規模なワークロード用のパッチが含まれています (まあ、これは 32 ビット システムの大きなワークロードであり、64 ビットでは特別なことではありません)。したがって、最終的には、RHEL には他の顧客があなたと同じクレイジーなことをしており、それらの顧客をサポートするために彼らが行った仕事から利益を得ている可能性があります。
最後に、32 ビットの SuSE でこれを行う方法を見つけようとしていると思われるので、Linux は 32 ビットの x86 でさまざまなアドレス空間のトレードオフを提供していることを指摘しておきます。それは可能です。 (確かではありませんが) あなたの SuSE システムでは異なるトレードオフが選択されているだけです。実行中のカーネルの構成 (多くの場合 /boot/config.... にあります) を表示できる場合は、HIGHMEM などの設定を比較できます。
数年前までの従来のオプションは 2:2 分割でした。つまり、ユーザー空間は 2GiB のアドレス空間に制限されており、プログラムするのが簡単なソリューションであり、適切な効率がありますが、このシナリオでは、要求されたヒープを取得できないことは明らかです。プログラムテキスト、スタックなどのためのスペースを残しません。最近の傾向は 3:1 (Windows の /3GB スイッチに似ています) であり、OS カーネル自体をより少ないスペースに詰め込むという犠牲を払ってユーザー空間のアドレス空間を拡張します。独自の問題を引き起こします。これはうまくいくかもしれませんが、非常に窮屈になるので、あなたの仕事にうまくいかなくても驚かないでしょう. 最後に、新しい Linux カーネルは、4GiB 32 ビットのユーザー空間を取得するオプションも提供します。これは、ジョブを確実に実行するのに十分な場合があります。
これを試すには、新しいカーネルが必要です。SuSE が提供するものをインストールするだけでよい場合もあれば (たとえば、「PAE」オプションなど、他に選択肢があるかどうかを確認してください)、独自にコンパイルする必要がある場合もあります。その場合、サポート契約が無効になる可能性があります。
しかし、実際には、オプション 1 を使用して、64 ビット JVM に切り替えて、準備を整える必要があります。