49

バックグラウンド

約 20 の Linux ブレードのプールがあります。Suse を実行している人もいれば、Redhat を実行している人もいます。次の 3 つのフォルダーを含むすべての共有 NAS スペース:

  • /NAS/app/java - Java JDK のインストールを指すシンボリック リンク。現在のバージョン 1.5.0_10
  • /NAS/app/lib - アプリケーションのバージョンを指すシンボリック リンク。
  • /NAS/data - 出力が書き込まれるディレクトリ

すべてのマシンには、4 GB の物理メモリと 4 GB のスワップ スペースを備えた 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.

これは、同じマシンで同時に実行されるジョブが多すぎるためだと考えていました。問題が発生する頻度は非常に低いため ( 1か月に 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 (bhcompile@bugs.build.redhat.com) (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

マシン上でジョブが実行されておらず、他のプロセスが多くのメモリを使用していません。現在実行中のすべてのプロセスが合計 100 MB を使用している可能性があります。

'top' は現在、次を示しています。

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

次のコマンド ライン (1850 MB の最大ヒープ) でジョブを開始すると、正常に開始されます。

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.

現在使用されているメモリがバッファリング/キャッシング用であることは明らかであり、そのため「空き」として表示されるメモリはほとんどありません。明確でないのは、1850 mb の魔法のラインがあり、それ以上になると Java が起動できないことを意味する理由です。

説明をいただければ幸いです。

4

15 に答える 15

21

32 ビット OS を使用しているため、合計サイズが制限されます。他の回答はこれをより詳細にカバーしているので、それらの情報を繰り返すことは避けます.

サーバーで最近気付いた動作は、 で最大ヒープ サイズを-Xmx指定し、最小ヒープ サイズを指定しない-Xmsと、Java のサーバー VM が最大ヒープ サイズに必要なすべてのメモリをすぐに割り当てようとすることです。確かに、アプリがそのヒープ サイズに達すると、それが必要なメモリの量になります。ただし、アプリケーションは比較的小さなヒープで開始され、後で大きなヒープが必要になる可能性があります。さらに、最小ヒープ サイズを指定すると、アプリを小さなヒープから開始し、そのヒープを徐々に大きくすることができます。

これらすべてが最大ヒープサイズを増やすのに役立つわけではありませんが、役立つかもしれないと考えたので...

于 2009-06-29T17:03:41.713 に答える
15

他の回答で示唆されているように、問題は仮想アドレス空間の枯渇によって引き起こされます。32 ビットの Linux ユーザー空間プログラムは通常、3 GB の AS に制限されています。残りの 1GB はカーネルによって使用されます (理論的根拠: 上部の 1GB はカーネル固定マッピングであるため、syscall を処理するときにページ テーブルに触れる必要はありません)。

ただし、RHEL カーネルはいわゆる 4GB/4GB 分割を実装しており、わずかなランタイム オーバーヘッドを犠牲にして、4GB AS 全体をユーザー空間プロセスで利用できます (カーネルは別の 4GB 仮想 AS に存在します)。

于 2009-11-06T15:23:40.247 に答える
8

32 ビット OS を実行するのは間違いです。できるだけ早くアップグレードする必要があります。

Java がそのヒープを 1 つの連続したチャンクにする必要があるかどうかはわかりませんが、必要な場合、32 ビット ボックスで 1.8G のヒープを要求するのは難しい注文のように思えます。JVM の起動時に、アドレス空間のチャンク (ほぼ半分) が空いていると想定しています。

その時点でロードされている他のライブラリによっては、存在しない場合があります。ライブラリは好きな場所にメモリを割り当てることができるため、1 つのチャンクで 1.8G を使用できないほどアドレス空間が断片化される可能性があります。

いずれにせよ、Linux 32 ビットで利用できる最大アドレス空間は約 3G だけです。ライブラリと JVM 自体は、最初にいくつかを使用します。

于 2009-06-30T06:43:17.750 に答える
4

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

「本当の」解決策は、64 ビット JVM を備えた 64 ビット サーバーを使用して、プロセスごとに 2GB を超えるヒープを取得することです。ただし、64 ビット JVM を使用して (アドレス可能なスペースだけでなく) アドレス サイズを増やすことの影響も考慮することが重要です。4GB 未満のメモリを使用した処理では、パフォーマンスとメモリに影響が出る可能性があります。

考察の材料: これらの各ジョブは本当に 2GB のメモリを必要とするのでしょうか? この制限が問題にならないように、ジョブを 1.8GB 以内で実行するように変更する方法はありますか?

于 2009-06-29T16:44:59.343 に答える
3

最大メモリサイズを制限し、仮想メモリを無制限に設定しますか?

于 2009-06-29T19:19:00.920 に答える
3

私は 2 つのアプリケーションを作成しました。1 つは中規模で、もう 1 つはかなり小規模です。引数なしで中規模のもの（Linux、centos上）（Javaサーバー）を起動すると、問題なく動作します。しかし、「Java クライアント」を使用して小さなアプリを起動すると、十分なスペースを確保できず、実行されないことがわかりました。私は実験して、-Xms と -Xmx の両方を 10m で使用しました。

于 2012-10-05T05:20:28.327 に答える
2

これは道から外れているかもしれませんが、心に浮かぶことが 2 つあります。以下は両方とも、32 ビット バージョンの Linux を実行していることを前提としています。

Linux にはプロセス サイズの制限があり、CentOS では約 2.5 GB であり、カーネルで構成されていることを覚えているようです (つまり、変更するための再コンパイル)。すべての JVM コードと Permgen スペース、および残りのすべての JVM ライブラリを合計すると、プロセスはそれを達成している可能性があります。

2 つ目は、アドレス空間が不足している可能性があるということです。奇妙に聞こえます。1.5Gb ヒープで Glassfish を実行する際に問題がありました。JSP をコンパイルしようとすると、javac をフォークすると、OS が新しく作成されたプロセスに十分なアドレス空間を割り当てることができなかったため、ボックスに 12GB のメモリがあったにもかかわらず失敗しました。ここでも似たようなことが起こっているかもしれません。

残念ながら、上記の 2 つの問題を解決するには、64 ビット カーネルにアップグレードする必要があります。

これが役に立つことを願っています。

于 2009-06-29T16:40:20.157 に答える
2

実行する手順 .... VM の初期化中に発生したエラーを解決する オブジェクト ヒープに十分なスペースを予約できませんでした Java 仮想マシンを作成できませんでした。

ステップ1：以前に使用したメモリを減らします.. java -Xms128m -Xmx512m -cp simple.jar

ステップ 2: RAM をしばらくマザーボードから取り外し、プラグを差し込んで再起動します * ブロッキング ヒープ領域のメモリが解放される可能性があります.. java -Xms512m -Xmx1024m -cp simple.jar

今はうまくいくといいのですが... :-)

于 2011-11-24T09:57:57.750 に答える
2

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 ビットでより高速になったのは、何年も後のことでした。

于 2010-05-13T21:24:09.073 に答える
2

マシンのメモリを 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.

問題は、アドレス可能なスペースに 1 GB に設定した ulimit でした。2GBに増やすと問題が解決しました。

-Xms と -Xmx は効果がありませんでした。

Java は使用可能なメモリに比例してメモリを取得しようとし、取得できない場合は失敗するようです。

于 2010-12-22T20:46:20.953 に答える
2

私は最近この問題に直面しました。1024m または 1280m のヒープ サイズで始まる 3 つの Java アプリケーションがあります。Java はスワップ内の利用可能なスペースを調べており、十分なメモリが利用できない場合、jvm は終了します。

この問題を解決するには、大量の仮想メモリが割り当てられているいくつかのプログラムを終了する必要がありました。

64ビットjvmを使用してx86-64 Linuxで実行していました。

于 2013-02-12T21:15:19.420 に答える
1

JVM は何を使用していますか? BEA JRockit の最大ヒープ サイズが 1850mB を超えないことはわかっています。失敗することはありませんが、1850mB を超えて使用しないことをユーザーに警告します。

このような制限がある理由はわかりませんが、BEA JRockit には存在することはわかっています。

よろしくお願いします。

于 2009-06-29T14:07:40.630 に答える
1

他の提案がどれもうまくいかなかったことを考えると (私が自分で提案した多くのことを含む)、さらにトラブルシューティングを行うために、実行してみてください:

sysctl -a

SuSE と RedHat の両方のマシンで違いがあるかどうかを確認しますか? これを引き起こしているこれら2つのディストリビューション間でデフォルト構成が異なると推測しています。

于 2009-06-29T19:28:35.580 に答える
1

問題を解決するために、SOA env を使用しています。Xmx を 1024 から 768 に減らしましsetSOADomainENV.cmdた。

REM set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m
set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m
于 2012-03-27T04:54:12.470 に答える
-3

Windows では、ファイル /bin/cassandra.bat を直接編集してこの問題を解決し、「Xms」および「Xmx」JVM_OPTS パラメータの値を変更しました。/bin/cassandra ファイルの編集を試みることができます。このファイルには、コメント付きの変数 JVM_OPTS が表示されます。コメントを外して編集してみてください。

于 2011-09-11T11:52:46.827 に答える