一般的な問題のトラブルシューティング



\| WebLogic Server ホーム \| WebLogic Server クラスタ \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

一般的な問題のトラブルシューティング

以下の節では、一般的な問題のトラブルシューティング方法について説明します。

診断情報の収集

クラスタ関連の問題について BEA テクニカルサポートにお問い合わせになる前に、この節の手順に従って、システムの診断情報を収集してください。クラスタ関連の問題についての主な診断情報は、（可能な場合）クラスタ化されたサーバからの複数のスレッドダンプを格納するログファイルです。ログファイルはクラスタ関連のさまざまな問題の診断に役立ちますが、クラスタの「フリーズ」やデッドロックに関する問題の解決に特に重要です。

注意: サーバインスタンス間のデッドロックを伴うか、クラスタが「ハング」する原因となったクラスタ関連の問題が発生した場合、複数のスレッドダンプを格納するログファイルは問題の診断に欠かせません。

必要なログファイルを作成するには次の手順に従います。

ログファイルがあればすべて削除するか、バックアップします。実際には、これまでのログファイルに新規セッションを追加するのではなく、WebLogic Server インスタンスを起動するたびに新規のログファイルを作成する必要があります。
WebLogic Server を起動したときに、Java VM の verbose ガベージコレクション（GC）出力をオンにします。サンプルのコマンドラインについては、次の手順を参照してください。
標準エラーと標準出力の両方をログファイルにリダイレクトします。リダイレクトすると、スレッドダンプ情報が WebLogic Server の情報メッセージとエラーメッセージに関連してログに記録され、診断する際にログファイルがさらに役立ちます。次に例を示します。
```
% java -ms64m -mx64m -verbose:gc -classpath $CLASSPATH
-Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==$WL_HOME/lib/weblogic.policy
-Dweblogic.admin.host=192.168.0.101:7001 -Dweblogic.management.username=system
-Dweblogic.management.password=systemPassword weblogic.Server >> logfile.txt 2>&1
```
問題が再発生するまで、WebLogic Server クラスタの実行を継続します。
サーバがハングした場合は、kill -3 または <Ctrl>-<Break> を使用して、問題を診断するために必要なスレッドダンプを作成します。各サーバの複数のスレッドダンプがスレッドダンプどうしで明確な間隔をおいてログファイルに入っていることを確認します。

注意: Linux 環境で JRockit JVM を実行している場合の対処については、 Linux 環境での JRockit スレッドダンプの取得を参照してください。

Linux 環境での JRockit スレッドダンプの取得

Linux 環境で JRockit JVM を使用する場合、以下のいずれかの方法でスレッドダンプを生成します。

weblogic.admin THREAD_DUMP コマンドを使用します。指示と制限事項については、『WebLogic Server 管理者ガイド』の「THREAD_DUMP」を参照してください。
JVM の管理サーバが（-Xmanagement オプションを指定して JVM を起動することによって）有効になっている場合、JRockit Management Console を使用してスレッドダンプを生成できます。
kill -3 PID コマンドを使用します。PID はプロセスツリーのルートです。
ルート PID を取得するには、次のコマンドを実行します。

ps -efHl | grep 'java' **. **

サーバの起動コマンドと一致する文字列を grep 引数に指定して、プロセススタック内を検索します。返される最初の PID はルートプロセスになります。これは、ps コマンドが別のルーチンにパイプされていないことを想定しています。

注意: Linux 環境では、各実行スレッドは Linux プロセススタック下の独立したプロセスであるかのように動作します。Linux 上で kill -3 コマンドを使用するには、メインの WebLogic 実行スレッドの PID と一致する PID を指定しなければなりません。正しく指定しないと、スレッドダンプは生成されません。

BEA テクニカルサポートへの診断情報の提供

（可能であれば複数のスレッドダンプが入った）診断ログファイルを作成したら、次のガイドラインを参考にして、BEA テクニカルサポート担当者に診断情報を提供します。

オペレーティングシステムの圧縮ユーティリティを使ってログファイルを圧縮します。
```
% tar czf logfile.tar logfile.txt
```
テクニカルサポート担当者宛の E メールに圧縮済みログファイルを追加します。
注意: 圧縮済みファイルは必ずメッセージに添付する形で追加します。E メールの本文にログファイルを切り取って貼り付けないでください。
圧縮済みログファイルのサイズが大きすぎて E メールに添付できない場合は、BEA カスタマサポートの FTP サイトを利用します。

一般的な問題の解決

次の節では、クラスタ関連の一般的な問題を解決する方法について説明します。また、クラスタのパフォーマンスが悪いなど、具体的な問題以外について診断する方法についても説明します。

サーバがクラスタを構成できない場合

WebLogic Server が起動時にクラスタを構成できない理由には、一般的なネットワークの可用性や WebLogic 固有のコンフィグレーションの問題などがあります。次のチェックリストを使用してクラスタの構成、および起動プロセスを確認してください。

コマンドラインパラメータの入力の間違い、つづりの誤りなどがないか確認します。
ネットワーク接続などの物理的な問題が無いことを確認します。ネットワーク接続の確認には、「接続のテスト」で説明した dbping ユーティリティを使用します。
ほかのアプリケーションがクラスタマルチキャストアドレスを使用していないことを確認します。
utils.MulticastTest ユーティリティを実行して、マルチキャストが正常に動作していることを確認します。

これ以外にも、トラブルシューティングが必要なエラーとして、次のような一般的なコンフィグレーションエラー、および通信エラーなどがあります。

Incompatible version numbers.クラスタ内のすべての WebLogic Server は同じバージョンでなければなりません。クラスタ内のほかのサーバとは異なるバージョンの WebLogic Server でクラスタを構成しようとしても、エラーメッセージが表示されます。
Unable to find a license for clustering.WebLogic のライセンスにクラスタリング機能が含まれていません。営業担当者までお問い合わせください。
Unable to send service announcement.これは、ネットワークに関する一般的な問題、または DNS の構成が誤っていることを意味します。クラスタ構成のサーバは、、マルチキャストを経由して相互に通信するため、同一の（排他的な）マルチキャストアドレスを共有する必要があります。
Cannot set default clusterAddress properties value.これは、同じ IP アドレスを持つ、別のサーバがすでにクラスタ内に存在することを意味します。複数のマシンに同じ IP アドレスを割り当てていないかどうか確認してください。
Unable to create a multicast socket for clustering, Multicast socket send error, or Multicast socket receive error.これらの通信エラーは、主にマルチキャストアドレスが間違っているか不正かのどちらかの原因により発生します。
各オペレーティングシステムシステムには、マルチキャストを構成するための固有のコンフィグレーション要件があります。したがって、このエラーの修復については、使用しているオペレーティングシステムのマニュアルを参照してください。