Java開始の拒否-オブジェクトヒープに十分なスペースを予約できませんでした
バックグラウンド
約20個のLinuxブレードのプールがあります。一部はSuseを実行しており、一部はRedhatを実行しています。すべての共有NAS以下の3つのフォルダーを含むスペース：
- / NAS/app/Java-Java JDK。現在バージョン1.5.0_10のインストールを指すシンボリックリンク
- / NAS/app/lib-アプリケーションのバージョンを指すシンボリックリンク。
- / NAS/data-出力が書き込まれるディレクトリ
すべてのマシンには、4GBの物理メモリと4GBのスワップスペースを持つ2つのプロセッサ（ハイパースレッド）が搭載されています。各マシンが所定の時間に処理できる「ジョブ」の数を6に制限します（この数はおそらく変更する必要がありますが、現在の問題には入らないため、当面は無視してください）。
一部のジョブでは、最大ヒープサイズを512MBに設定していますが、他のジョブでは、最大ヒープサイズを2048MBに予約しています。繰り返しますが、ヒープサイズが2048に設定された同じマシンで6つのジョブが開始された場合、使用可能なメモリを超えることができますが、私たちの知る限り、これはまだ発生していません。
問題
時々、ジョブはすぐに失敗し、次のメッセージが表示されます。
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
以前は、同じマシンで同時に実行されているジョブが多すぎるため、これをチョークで書きました。問題はまれにしか発生せず（[〜＃〜] maybe [〜＃〜]月に1回）、再起動するだけで問題はありません。
この問題は最近、さらに悪化しています。 2048mの最大ヒープサイズを要求するすべてのジョブは、ほぼ毎回すぐに失敗し、完了する前に数回再起動する必要があります。
私たちは個々のマシンに出かけ、それらを手動で実行して同じ結果を得ました。
デバッグ
問題はSuSEボックスにのみ存在することがわかりました。より頻繁に発生している理由は、より多くのマシンを追加しているためです。新しいマシンはSuSEです。
SuSEボックスの「cat/proc/version」を使用すると、次のことがわかります。
Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005
RedHatボックスの「cat/proc/version」を使用すると、次のことがわかります。
Linux version 2.4.21-32.0.1.ELsmp ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)) #1 SMP Tue May 17 17:52:23 EDT 2005
'uname -a'は、両方のタイプのマシンで以下を提供します。
UTC 2005 i686 i686 i386 GNU/Linux
マシン上で実行中のジョブはなく、他のプロセスは多くのメモリを使用していません。現在実行中のすべてのプロセスmightは合計100MBを使用しています。
「トップ」には現在次のものが表示されます。
Mem: 4146528k total, 3536360k used, 610168k free, 132136k buffers
Swap: 4194288k total, 0k used, 4194288k free, 3283908k cached
「vmstat」は現在次を示しています。
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 610292 132136 3283908 0 0 0 2 26 15 0 0 100 0
次のコマンドライン（最大ヒープ1850mb）でジョブを開始すると、正常に開始されます。
Java/bin/Java -Xmx1850M -cp helloworld.jar HelloWorld
Hello World
最大ヒープサイズを1875mbに増やすと失敗します。
Java/bin/Java -Xmx1875M -cp helloworld.jar HelloWorld
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
現在使用されているメモリがバッファリング/キャッシュ用であることは明らかであり、そのため「空き」として表示されるものはほとんどありません。明確ではないのは、1850mbの魔法のような行がある理由です。これより高いものは、Javaが開始できないことを意味します。
どんな説明でも大歓迎です。
32ビットOSを使用しているため、そのために合計サイズに制限があります。他の答えはこれをより詳細にカバーしているので、私は彼らの情報を繰り返すことを避けます。
サーバーで最近気づいた動作は、-Xmxで最小ヒープサイズを指定せずに-Xmsで最大ヒープサイズを指定すると、JavaサーバーVMがすぐに試行されることです。最大ヒープサイズに必要なすべてのメモリを割り当てます。確かに、アプリがそのヒープサイズに達すると、それが必要なメモリ量になります。ただし、可能性としては、アプリが比較的小さなヒープで開始され、may後で大きなヒープが必要になる場合があります。さらに、最小ヒープサイズを指定すると、小さなヒープからアプリを開始し、そのヒープを徐々に増やすことができます。
これはすべて、最大ヒープサイズを増やすのに役立ちませんが、私はそれが役立つかもしれないと思ったので...
他の応答で示唆されているように、問題は仮想アドレス空間の枯渇によるものです。 32ビットのLinuxユーザースペースプログラムは、通常3GBのASに制限されています。残りの1GBはカーネルによって使用されます（理由：上位1GBはカーネル固定マッピングであるため、syscallを提供する際にページテーブルに触れる必要はありません）。
ただし、RHELカーネルは、いわゆる4GB/4GBスプリットを実装します。この場合、わずかなランタイムオーバーヘッドのコストでユーザースペースプロセスで完全な4GB ASを使用できます（カーネルは4GB仮想ASに存在します）
32ビットOSの実行は間違いです。できるだけ早くアップグレードする必要があります。
Javaヒープが単一の連続したチャンクにある必要があるかどうかはわかりませんが、もしそうなら、32ビットのボックスで1.8Gのヒープを要求するのは難しい順序に聞こえます。 JVMの起動時に、アドレススペースのチャンク（ほぼ半分）が空いていると想定しています。
その時点でロードされている他のライブラリによっては、ロードされない場合があります。ライブラリは好きな場所にメモリを割り当てることができるため、アドレス空間が十分に断片化され、1.8Gが1つのチャンクで利用できなくなります。
とにかく、Linux 32ビットでは最大で約3Gのアドレス空間しか利用できません。ライブラリとJVM自体は、一部を使用して開始します。
32ビットサーバーには、克服できないJVMの制限があるようです（2 GBの制限以下を課さない特別な32ビットJVMを見つけない限り）。
The Server Sideのこのスレッドには、32ビットアーキテクチャでさまざまなJVMをテストした数人の人々が含まれています。 IBMのJVMはさらに100 MBを許可しているように見えますが、それはあなたが望むものを実際に得ようとはしていません。
http://www.theserverside.com/discussions/thread.tss?thread_id=26347
「実際の」ソリューションは、プロセスごとに2GBを超えるヒープを取得するために64ビットJVMを備えた64ビットサーバーを使用することです。ただし、64ビットJVMを使用してアドレスサイズ（アドレス可能なスペースだけでなく）を大きくした場合の影響も考慮することが重要です。 4GB未満のメモリを使用して処理を行うと、パフォーマンスとメモリに影響が出る可能性があります。
思考の糧：これらのジョブはそれぞれ2GBのメモリを本当に必要としますか？ 1.8GB以内で実行されるようにジョブを変更する方法はありますか？この制限は問題になりませんか？
2つのアプリケーションを作成しました。1つは中規模のアプリケーションで、もう1つはかなり小さなアプリケーションです。中規模のもの（Linux、centos）を起動し、引数なし（Javaサーバー）で、正常に実行されます。しかし、その後、「Javaクライアント」で小さなアプリを起動すると、十分なスペースを確保できず、実行されないことがわかります。私は実験し、両方とも10mで-Xmsと-Xmxを使用しましたが、どちらも文句なしに実行されました...
最大メモリサイズを制限し、仮想メモリを無制限に設定しますか？
マシンのメモリを2GBから4GBにアップグレードすると、すぐにエラーが発生し始めました。
$ Java -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
問題は、アドレス可能なスペースに1GBに設定したulimitでした。 2GBに増やすことで問題は解決しました。
-Xmsおよび-Xmxは効果がありませんでした。
Javaは利用可能なメモリに比例してメモリを取得しようとし、できない場合は失敗します。
OSとJavaのアップグレードを検討する必要があります。 Java 5.0はEOLですが、Java 6に更新できない場合は、最新のパッチレベル22を使用できます。
32ビットWindowsは最大1.3 GBに制限されているため、最大1.8に設定できます。注：これは連続メモリの問題であり、システムの実行中にメモリスペースが断片化する可能性があるため、この問題が発生しても驚かないでください。
64ビットOSでは、仮想スペースがはるかに多いため、この問題は発生しません。これを利用するためにJavaの64ビットバージョンにアップグレードする必要さえありません。
ところで、私の経験では、32ビットJava 5.0は64ビットJava 5.0より高速です。 Java 6 update 10が64ビットで高速になったのは、何年も後のことです。
私は最近この問題に直面しました。 1024mまたは1280mのヒープサイズで始まる3つのJavaアプリケーションがあります。 Javaはスワップ内の使用可能なスペースを確認しており、使用可能なメモリが十分にない場合、jvmは終了します。
この問題を解決するには、大量の仮想メモリが割り当てられたいくつかのプログラムを終了する必要がありました。
64ビットjvmを搭載したx86-64 Linuxで実行していました。
実行するステップ... VMの初期化中に発生したエラーを解決するにはオブジェクトヒープ用に十分なスペースを予約できませんでしたJava仮想マシンを作成できませんでした。
ステップ1：以前に使用したメモリを減らします。Java -Xms128m -Xmx512m -cp simple.jar
ステップ2：マザーボードからRAMを少し取り外してから接続し、再起動します*ブロッキングヒープ領域のメモリが解放される場合があります。Java -Xms512m -Xmx1024m -cp simple。 jar
うまくいくことを願っています... :-)
これはたぶん軌道から外れているかもしれませんが、頭に浮かぶ2つのことがあります。次の両方は、Linuxの32ビットバージョンを実行していることを前提としています。
Linuxにはプロセスサイズの制限があり、CentOSでは約2.5GBであり、カーネルで構成されていることを覚えているようです（つまり、変更する必要があります）。すべてのJVMコード+ Permgenスペースと残りのすべてのJVMライブラリを追加すると、プロセスがヒットする可能性があります。
2つ目は、アドレススペースが不足している可能性があるということです。 GlassFishを1.5Gbのヒープで実行する際に問題が発生しました。JSPをfork javacに準拠させようとすると、ボックスに12GBのメモリがあったとしてもOSが新しく作成されたプロセスに十分なアドレス空間を割り当てることができなかったため、失敗します。ここでも同様のことが起こっている可能性があります。
64ビットカーネルにアップグレードする上記2つに対する唯一の解決策が怖いです。
これが役に立つことを願っています。
私はSOA env、setSOADomainENV.cmdでXmxを1024から768に減らしました] _を使用して問題を解決しました。
REM set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m
set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m
さらにトラブルシューティングを支援するために、他の提案はどれも機能していなかったので（自分が提案した多くのことを含む）、実行してみてください：
sysctl -a
SuSEマシンとRedHatマシンの両方で、違いがあるかどうかを確認しますか？デフォルトの構成は、これを引き起こしているこれら2つのディストリビューション間で異なると推測しています。
使用されるJVMは何ですか？ BEA JRockitは最大ヒープサイズで1850mBを超えないことを知っています。失敗することはありませんが、1850mB以上は使用しないことをユーザーに警告します。
なぜそのような制限があるのかわかりませんが、BEA JRockitには存在することは知っています。
宜しくお願いします。