1

Swisscom Cloud にデプロイ可能な Java アプリケーションがあります。1.5 G の RAM を持つインスタンス。CF の次のパラメーターを使用して、このアプリのメモリ使用量を制限しています。

[jre: { version: 1.8.0_+ }, memory_calculator: {memory_sizes: {stack: 228k}, 
memory_heuristics: {heap: 50, metaspace: 20, native: 50, stack: 10}}]

インスタンスの下で、実行すると次のps -ef | grep javaようになります。

-Xms611500K -XX:MetaspaceSize=244600K -Xmx611500K -XX:MaxMetaspaceSize=244600K -Xss228
-XX:MaxDirectMemorySize=256m -XX:InitialCodeCacheSize=32m -XX:ReservedCodeCacheSize=64m 
-XX:CompressedClassSpaceSize=250m -XX:+UseCompressedOops -XX:+UseCompressedClassPointer

残念ながら、しばらくするとアプリ プロセスが強制終了されます ("Exit with status 137")。CF の別の設定を試してみましたが、うまくいきませんでした。使用メモリを制限しているにもかかわらず、常に 1.5 ギガの RAM が不足しています。

    2016-11-10T14:31:08.34+0200 [API/0]      OUT App instance exited with guid 
72a197e9-e222-43b5-9828-9553c1d58315 payload: {"instance"=>"", "index"=>0, 
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2 error(s) 
occurred:\n\n* Exited with status 137 (out of memory)\n* cancelled\n* cancelled", 
"crash_count"=>1, "crash_timestamp"=>1478781068233690142, 
"version"=>"ebfced51-9973-434b-8ec0-79a8caa86b3b"}

クラッシュする前に、New Relic を使用してヒープ メモリの使用状況を分析していました。

使用済みヒープ メモリ 使用済みの非ヒープ メモリ ここで、4時半頃の出来事Exited with status 137 (out of memory)。ご覧のとおり、メモリの超過はまったくありませんでした。

クラッシュする前に cf インスタンスでコマンドを実行するとtop、次の結果が得られました。

7 vcap 10 -10 6160764 1.357g 22528 S 27.3 7.4 3:09.52 java

実際に何が間違っている可能性がありますか？Java プロセスが実際に約 1.4G の RAM を使用したことがわかりましたが、New Relic グラフからは、それほど大量のメモリが使用されていません。

4

1 に答える 1

1

CF コンテナがメモリを使いすぎていると判断したため、アプリケーションがクラッシュしたと仮定します。この仮定は、「cf イベント」のクラッシュ イベントを見て、それらが OOM クラッシュであることを確認することで検証できます。アプリケーションをクラッシュさせているのがコンテナーであると仮定すると、これが私が通常この状況を調整する方法です。

java_buildpack は、アプリケーションのメモリ使用量を抑えるのに非常に苦労しています。ただし、jvm が構成されたオプションの外にメモリを割り当てる方法を見つけるアプリケーションがまだあるようです。

この問題が発生した場合、構成を調整する最も簡単な方法は、アプリケーションが安定するまで「ネイティブ」メモリ比率を増やし、ヒープを減らし続けることです。ネイティブは、ビルドパックが管理しない、jvm が割り当てる可能性のあるすべてのバケットをキャッチします。

また、「heap:600m」構成も削除します。これは、ヒューリスティック計算をより複雑にし、ネイティブのパーセンテージの増加を無効にする可能性があるためです。

于 2016-11-03T21:58:41.063 に答える