9

Websphere Application Server 6.0でアプリケーションを実行していますが、メモリ不足が原因でほぼ毎日クラッシュします。詳細なGCから、メモリリークがあることは確かです（それらの多く）

残念ながら、アプリケーションは外部ベンダーによって提供されており、問題を修正するのは時間がかかり、面倒なプロセスです。プロセスの一環として、OOMが発生するたびにログとヒープダンプを収集する必要があります。

今、私はそれを自動化する方法を探しています。基本的な問題は、OOM状態をどのように検出するかです。1つの方法は、新しいヒープダンプを定期的に検索するシェルスクリプトを作成することです。このアプローチは私にはちょっと汚いようです。別のアプローチは、何らかの方法でJMXを活用することかもしれません。しかし、私はこの分野での経験がほとんどないかまったくなく、その方法についてあまりよくわかりません。

それとも、これのための何らかのトリガー/フックがありましたか？アドバイスありがとうございます！

4

9 に答える 9

10

起動時に次の引数を JVM に渡すことができます。ヒープ ダンプは OutOfMemoryError で自動的に生成されます。2 番目の引数では、ヒープ ダンプ ファイルのパスを指定できます。これを使用することで、少なくとも特定のファイルの存在をチェックして、ヒープ ダンプが発生しているかどうかを確認できます。

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<value>
于 2009-08-25T08:47:45.377 に答える
5

ヒープダンプを自動化する場合は2つのオプションがありますが、OOMでヒープダンプを使用する@Markのソリューションでは不十分です。

  1. You can use the MemoryMXBean to detect high memory pressure, and then programmatically create a heap dump if the usage (or usage delta) seems high.
    • You can periodically get memory usage info and generate heap dumps with a cron'd shell script using jmap (works both locally and remote).

It would be nice if you could have a callback on OOM, but, uhm, that callback probably would just crash with an OOM error. :)

于 2009-08-25T09:45:22.250 に答える
4

JConsoleを見たことがありますか？JMX を使用して、メモリ情報を含むさまざまな JVM メトリックを可視化します。メモリがどのように/いつ消費されるかを把握するために、まずこれを使用してアプリケーションを監視する価値があるでしょう。1 日を通して、または特定の機能を使用しているときに、メモリが均一に消費されることがあります。

上記のリンクのメモリ不足の検出セクションをご覧ください。

必要に応じて、アプリケーションを自動的に監視し、必要なアクションをトリガーするJMX クライアントを作成できます。JConsole は、ポーリングする必要がある JMX メソッドを示します。

于 2009-08-25T09:37:01.220 に答える
2

また、アプリケーションがクラッシュするまで待つ代わりに、アプリケーションが 12 時間存続できると楽観的である場合は、毎晩のように制御された再起動をスクリプト化することもできます..

たぶん websphere でさえあなたのためにそれを行うことができます!?

于 2009-08-25T08:50:31.300 に答える
1

新しいオブジェクトがセッション/アプリ スコープに追加されるたびに呼び出されるリスナー (セッション スコープまたはアプリケーション スコープ属性リスナー) クラスを追加できます。

これで、アプリで使用されている合計メモリを確認して (ログに記録して)、run gc を呼び出すことができます (呼び出しても gc が常に実行されるわけではないことに注意してください)。

(上記は、使用量の増加に基づくロギング部分と gc 用です)

スケジュールされた gc の場合: さらに、数時間ごとに実行され、gc の要求を行うタイマー タスク クラスを保持できます。

于 2009-08-25T09:05:35.560 に答える
1

ITCAM での私たちの経験は、監視の観点から見れば素晴らしいものではありませんでした。CA Wily Introscope を優先して破棄しました。

于 2009-08-25T15:38:27.837 に答える
0

OOMが発生したときにヒープダンプが必要であることに異議を唱えます。時間をかけて定期的に情報を収集することで、何が起こっているのかを把握できます。

観察されているように、これらの問題を分析するためのさまざまなツールが存在します。私は ITCAM for WebSphere で成功しており、IBMer としてすぐにアクセスできます。問題が発生した状況で、コードの正確な行を非常に迅速に特定することができました。

その性質のツールを入手できる方法があれば、それが道です。

于 2009-08-25T15:20:24.863 に答える
0

カーネルからプロセス リストを取得し、それをスキャンして WAS プロセスがまだ実行されているかどうかを確認する簡単なプログラムを作成できるはずです。Unix ボックスでは、おそらく数分で Perl で何かを作成できます (Perl を知っている場合)。ただし、Windows でそれがどれほど難しいかはわかりません。スケジュールされたタスクとして 5 分ごとに実行し、プロセスが表示されない場合は、ヒープ ダンプを処理して WAS を再起動する別のプロセスを分岐させることができます。

于 2010-12-22T20:39:02.197 に答える
0

最新の Java 6 JDK の jvisualvm ツールを調べましたか?

実行中のコードを検査するのに最適です。

于 2009-08-25T11:31:37.480 に答える