-2

16GBのメモリを搭載したEC2でバッチエンジン（BE）とJbossインスタンスを実行しています。どちらもWrapperSimpleAppによって管理されています。

BEは常に大量の情報を処理しています。念のために言うと、データベースは毎日約10〜15GBずつ増加します。ログから、BEは1日に1〜7回ダウンします。最大Javaヒープサイズを8GBから4GBに減らしました。効果はありませんでした。最後の手段として、EC2サーバーをバウンスすると、エラーはなくなりました。JVMが応答しなかった理由を見つける方法があるかどうか知りたいです。BEは、同じ量の作業で同じプロセスを実行しています。EC2サーバーの既知の問題ですか？BEに問題があるという証拠はありません。

ラッパー設定の一部を次に示します。

＃初期Javaヒープサイズ（MB単位）
＃wrapper.java.initmemory = 256
＃最大Javaヒープサイズ（MB単位）
wrapper.java.maxmemory =
4096wrapper.ping.timeout = 600

ログファイルのエラー：
INFO | jvm 6 | 2012/07/03 05:46:12 | BEはここでいくつかのことをしています。
エラー| ラッパー| 2012/07/03 05:57:14 | JVMがハングしているように見える：JVMからの信号を待ってタイムアウトしました。
エラー| ラッパー| 2012/07/03 05:57:14 | JVMは要求に応じて終了せず、
INFO|を終了しました。ラッパー| 2012/07/03 05:57:14 | アプリケーションを強制終了するのを待っている間、JVMは自動的に終了しました。
ステータス| ラッパー| 2012/07/03 05:57:14 | JVMは、シグナルSIGKILL（9）に応答して終了しました。
ステータス| ラッパー| 2012/07/03 05:57:19 | JVMを起動しています...
INFO| jvm 7 | 2012/07/03 05:57:19 | ラッパー（バージョン3.2.3）http://wrapper.tanukisoftware.org
INFO | jvm 7 | 2012/07/03 05:57:19 | Copyright 1999-2006 Tanuki Software、Inc.無断複写・転載を禁じます。
情報| jvm 7 | 2012/07/03 05:57:19 |
情報| jvm 7 | 2012/07/03 05:57:19 | BEは引き続き作業を行います

よろしくお願いします。

4

1 に答える 1

0

jstackまたはkill-3を使用してスレッドダンプをキャプチャすると、問題を見つけるのに役立ちます。

java.exeの代わりにバッチファイルを起動する場合、これは問題の説明に役立つ可能性があります。

http://wrapper.tanukisoftware.com/doc/english/troubleshooting.html#10

問題は、wrapper.java.commandプロパティをjava.exeに直接設定するのではなく、バッチファイルに設定する可能性があることです。スレッドダンプを要求すると、「BREAK」シグナルがJavaプロセスではなくプロセスcommand.exe/shellに送信されます。次に、シグナルをJVMに転送しますが、CTRL-Cが押されたことを示す内部フラグも設定します。子のJavaが終了すると、バッチスクリプトを停止するか続行するかをユーザーにすぐに尋ねます。

于 2012-07-12T07:57:40.487 に答える