11

そのため、数日ごとに Ubuntu の Java プロセスが自動的に強制終了され、その理由がわかりません。

私のボックスには 35.84 GB の RAM があり、Java プロセスを起動するときに -Xmx28g パラメータを渡すので、利用可能な最大 RAM よりもはるかに少ない量を使用する必要があります。

次のように jstat を実行しました。

# jstat -gccause -t `pgrep java` 60000

プロセスが強制終了される直前の jstat からの出力の最後の数行は次のとおりです。

Time     S0     S1     E      O      P       YGC   YGCT       FGC FGCT     GCT     LGCC                 GCC
14236.1  99.98   0.00  69.80  99.40  49.88   1011  232.305    11  171.041  403.347 unknown GCCause      No GC
14296.2  93.02   0.00  65.79  99.43  49.88   1015  233.000    11  171.041  404.041 unknown GCCause      No GC
14356.1  79.20   0.00  80.50  99.55  49.88   1019  233.945    11  171.041  404.986 unknown GCCause      No GC
14416.2   0.00  99.98  24.32  99.64  49.88   1024  234.945    11  171.041  405.987 unknown GCCause      No GC

これは、この頃に /var/log/syslog でダウンしたようです: https://gist.github.com/1369135

私のJavaアプリ以外に、このサーバーでは何も実行されていません。どうしたの？

編集: Java バージョン 1.6.0_20 を実行しています。起動時に Java に渡す唯一の注目すべきパラメーターは「-server -Xmx28g」です。私はアプリケーション サーバーを使用していませんが、私のアプリには "Simple Web Framework" が組み込まれています。

4

5 に答える 5

8

問題が OOM キラーであると仮定すると、深刻なメモリ不足の危機の中で OS の機能を維持しようと必死になってプロセスを強制終了したことになります。

私は次のように結論付けます。

  • JVM は実際には 28Gb を大幅に超えて使用しています。つまり、ヒープ以外のメモリを大量に使用している。

  • OS が適切な量のスワップ領域で構成されていません。

OSが緊急時にアプリケーションの一部をスワップアウトできるように、スワップスペースを追加してみます。

または、JVM のヒープ サイズを減らします。

「-Xmx ...」は、JVM が使用できるメモリの最大量ではなく、最大ヒープ サイズを設定することに注意してください。JVM は、スレッド スタック用のメモリや、アプリケーションが使用するメモリ マップ ファイルなど、いくつかのものをヒープの外に置きます。

syslog は、それが動作中の OOM キラーであることを確認します。

リンクされたsyslogはどのようにそう言っていますか?

それはこう言います：

Nov 15 13:53:49 ip-10-71-94-36 kernel: [3707038.606133] Out of memory: kill process 6368 (run.sh) score 4747288 or a child
Nov 15 13:53:49 ip-10-71-94-36 kernel: [3707038.606146] Killed process 9359 (java)

コンソールには、Java が終了したのではなく、終了したと表示されます。

正しい。オペレーティング システムの OOM キラーによって強制終了されました。

メモリが不足すると、通常は OutOfMemory 例外がスローされますが、スローされませんでした。

これは、Java ヒープをいっぱいにしていた場合に起こることです。

それはここで起こっていることではありません。実際の問題は、Java ヒープを保持するのに十分な物理 RAM がないことです。OOMキラーはそれを処理します...

それぞれ数キロバイトの RAM を必要とする何百万ものオブジェクトを格納する必要があるため、私は非常に巨大なヒープで実行しています。

残念ながら、システムで利用可能なよりも多くの RAM を使用しようとしています。これにより、仮想メモリがスラッシングし、オペレーティング システム全体に影響が及びます。

システムがひどくスラッシングし始めると、(JVM ではなく) OOM キラーが問題の原因として Java プロセスを識別します。その後、システムの残りの部分を保護するために (SIGKILL で) 強制終了します。そうしないと、システム全体が完全にロックされ、ハード リブートが必要になるリスクがあります。

最後に、あなたはこう言いました。

私のボックスには35.84 GBのRAMがあります...

それはかなり奇妙な値です。32 GiB は 34,359,738,368 バイトまたは 34.35 GB です。

しかし、それと観察された動作に基づいて、それは物理 RAM ではなく利用可能な仮想メモリであると思われます。または、「ボックス」は、ハイパーバイザー レベルで RAM オーバーコミットが有効になっている仮想マシンである可能性があります。

于 2011-11-16T03:13:31.117 に答える
7

Linux の「機能」である OOM-killer へようこそ。これは、どこにでもある大容量メモリ アプリケーションの悩みの種です。対処するための簡単なレシピはありません。グーグルで検索して、読んで泣き始めてください。

OOM キラーの悪巧みを簡潔に説明することはできませんが、重要な調整パラメーターが「swappiness」と呼ばれていることを思い出します。私たちの大きなサーバーの 1 つには、次のものがあります。

/etc/sysctl.conf:vm.swappiness=20

http://www.gentooexperimental.org/~patrick/weblog/archives/2009-11.htmlを読んでください。

于 2011-11-16T03:14:46.503 に答える
3

どのJVMを使用していますか? そしてどのアプリケーションサーバー？あまりにも多くのメモリを割り当てている可能性があり、それが問題になる可能性があります.ガベージコレクタがその仕事をするのに問題があるかもしれません.

これがあなたのケースかどうかはわかりませんが、Linux がメモリをオーバーコミットする方法を説明しているこの記事は非常に興味深いものでした。

于 2011-11-16T03:14:24.843 に答える
1

うわー、実際に 28 GB のヒープを持てますか?! それを減らしてみて、私が考えるRAMの50％以下に保つ必要があるかもしれません（つまり、〜18 GB、または15 GBになることもあります）。さらに171個のフルGCが多い！このアプリはどのくらいの期間実行されていましたか? 2 ～ 3 日で 171 人というのは巨大に聞こえます。要点は、終了前にOOMを示しています-ヒープを減らすと修正されると思います（JVMがネイティブスペースを拡張するのを制限している可能性があります）。必要に応じて、さまざまなパラメーターを調整してみてください。たとえば、スタック サイズを試してください (-Xss)。最大パーマサイズと他のセクションもチェックしてください。これはメモリの問題であり、必ずしもヒープであるとは限りません。

于 2011-11-16T03:13:34.737 に答える