1

これは難しい問題です。Amazon ElasticBeanStalk の Tomcat Web サーバーにデプロイされた Java Web アプリケーションがあります。JVM が OutOfMemory 例外で毎晩クラッシュしているようです。問題は、クラッシュの後、EBS が古い EC2 インスタンスを自動的に廃棄し、新しいインスタンスを開始することです。すべてのログと情報も破棄されます...

私は現在、JVM のメモリを監視するためのカスタム CloudWatch メトリクスを開発しています (準備されたものがあるはずだと思うでしょう...) が、ヒープ ダンプを生成するのに役立ちません。

誰かが同様の問題を経験し、EBS でこれらのエラーをキャッチする方法を知っていますか?

4

2 に答える 2

1

これは確かに異常な EC2 (EBS ではない) インスタンスの動作のように思えます。興味深いことに、Tomcats が失敗した場合、マシン インスタンスが (停止または終了に関して) 影響を受けます。

これは私が診断することを提案するものです：

  1. 実行中のインスタンスを読み取り、調べたり遊んだりする
  2. 「終了保護」を見てください-これは「有効」に設定されているかどうか-問題の「廃棄」部分を説明できます(廃棄によってインスタンスが終了して削除されることを意味する場合)。これは、AWS コンソールを使用して EC2 インスタンスのプロパティで見つけることができます。
  3. Tomcat サーバーが構成されている Java メモリ設定を確認してください。おそらく最大値は、仮想マシンが持っているよりも (Xmx) 大きい!? もしそうなら、おそらくTomcatは文字通りマシンをメモリ不足で実行しており、メモリ不足に対するEC2の応答の一部を説明できます. 「スクラップ」ではなく「停止」を意味していると思います。そうでない場合、メモリ不足エラーが発生していることをどのように知ることができますか?
  4. 稼働中のインスタンスで tomcat/java プロセスを手動で強制終了した場合、インスタンスは動作し続けますか (または、起動してインスタンスが停止しますか)? 単純に tomcat を停止したために何かが発生した場合は、何らかの監視プロセスが開始され、マシンが明示的に停止されていることを意味します。
  5. -XX:-HeapDumpOnOutOfMemoryError を使用してダンプ ファイルを生成します。これにより、リークが発生している場所を特定し、根本的な原因を修正することができます。

幸運を。それが役立つことを願っています。

于 2012-08-07T09:17:09.390 に答える