2. 障害解析

2.1. よくある質問(FAQ)

WebOTX製品に関するよくある質問(FAQ)は、NECサポートポータルに掲載しています。

NECサポートポータル (NECサイト, 別ウィンドウで開きます)
http://www.support.nec.co.jp/PSHome.aspx
  左メニューの [ お問い合わせ > よくあるご質問(サポートFAQ) ]

「キーワードで検索」は、以下の文字列などで検索してください。

「製品名・カテゴリから探す」に掲載している製品名は以下の通りです。

2.2. よくある障害

頻繁に発生する障害について説明します。

処理が遅い 応答がなくなる アプリケーションが異常終了する アプリケーションが起動しない インストール直後の問題 ドメインへのログインに失敗する
関連情報

2.3. ログ情報から

2.3.1. イベントログ・syslog

WebOTX AS では障害発生時に重要な情報をイベントログ・syslogに出力します。
以下に、主な障害について説明します。

TPSメッセージ (Standard/Enterpriseのみ)
OTXメッセージ
その他

イベントログ・syslog一覧は、[ メッセージ一覧 ] でも説明しているのでそちらも参照してください。

関連情報

2.3.2. クライアントアプリケーションのログ

クライアントアプリケーションにサーバから返却されるエラーコードについて説明します。

関連情報

2.4. 障害の種類から

2.4.1. サービス起動失敗・異常終了

WebOTX Application Serverのサービスの起動失敗について説明します。
特定のアプリケーションだけでなく、WebOTX Application Server全体に及ぶ問題が発生した場合は、こちらを参照して下さい。

ドメイン起動失敗 Webサーバ起動失敗 JMSサーバ起動失敗 TPシステム起動失敗 ドメイン作成失敗
TPモニタ・マネージャライフサイクルの起動停止失敗について
(Standard/Enterprise)

TP モニタ・マネージャライフサイクルの起動停止には、TP モニタに関する制御を行うTP モニタ制御サー ビス(tpadmd)とTP モニタプロセス(tpmMain, tpmonitor)が影響します。
これらのサービスやプロセスが起動失敗すると、TP システムが起動せず、TP モニタ・マネージャライフサ イクルも起動失敗します。

TPモニタが必要とするファイルやディレクトリにアクセス権限がなかった場合、 あるいはファイルやディレクトリが不足していた場合、TPモニタは起動に失敗し、TP モニタ・マネージャも起動失敗となります。
→ TPモニタプロセス起動失敗　権限不足やファイル不足


UNIXにおいて、WebOTXの起動中に以下のコマンドを実行した場合、 TPモニタ・マネージャが状態不正となり異常終了します。
/sbin/init.d/WebOTXinit start (HP-UX)
/etc/init.d/WebOTXinit start (Linux)
→ TPモニタプロセス起動失敗　共有メモリ不正


TP モニタプロセスが何らかの理由で異常終了した場合、 他のTPモニタに関連するプロセスが動作しているのであれば、クライアントからのユーザアクセスは成功する可能性はあります。 しかし、TP システムに対する運用操作ができなくなります。
また、実行時に確保する共有メモリが残ってしまうため、次回以降のTP モニタ・マネージャの起動に失敗します。 この場合、プロセスグループのプロセスが起動しないため、クライアントからのユーザアクセスがエラーとなり（ユーザ実装による）、 統合運用管理ツールからはTP システムが停止していることが確認できます。
→ TPモニタプロセス異常終了　共有メモリ残留について


UNIX 版において、WebOTX起動時に運用ユーザを変更してしまう（otxown.sh を実行してしまう）と、 TP モニタ・マネージャが正常動作しなくなる可能性があります。
→ TPモニタプロセス異常終了　実行中の運用ユーザ変更について

IIOPリスナ異常終了時/未起動
(Standard/Enterprise)

IIOPリスナが正常に起動していない場合、全てのオペレーション呼び出しを行う事ができません。
起動時に問題があった場合や何らかのプログラム的問題による終了が考えられます。
起動時の問題としては、UNIXの場合はIIOPリスナの設定「最大同時接続クライアント数」 を増やした事によるカーネルパラメータの不足により起動に失敗する事があります。
あるいはIIOPリスナで使用するポートが既に使用されている可能性があります。

→ IIOPリスナ異常終了時/未起動への対応

全てのオペレーション呼び出しに失敗する場合、 IIOPリスナ異常終了時/未起動以外が原因の可能性もあります。
以下にそれぞれ説明があります。
→ サーバポート未開設への対応

関連情報

2.4.2. オペレーション呼び出しでの障害

クライアントアプリケーションからサーバアプリケーションに対するオペレーション呼び出しに失敗した場合の調査方法を説明します。

調査のためには、何の呼び出しが何のエラーになったのかを確認する必要があります。
何のエラーかだけで調査が可能な場合もありますが、通信障害や遅延/無応答などの障害ではエラー情報で相手が特定できません。 何の呼び出しがエラーになったのかを確認することで対象を絞り込むことができます。

実行基盤のエラーを受けた場合(Standard/Enterprise)

あらゆるCORBA システム例外で、minor 番号が3840〜4095 の範囲にある場合は、WebOTX のサーバ実 行環境からエラーを受けています。WebOTXのサーバ実行環境上で何らかの問題が起きています。
以下に、主な障害について説明します。

例外一覧は、[ 例外一覧 ] で説明しているのでそちらも参照してください。

COM_FAILUREシステム例外を受けた場合

通信障害の発生を意味します。オペレーション呼び出し時のCOM_FAILUREなら実行基盤との間で問題があり、 リファレンス取得でのCOM_FAILUREなら名前サーバとの間で問題がおきています。

org.omg.CosNaming.NamingContext.NotFound

名前サーバから取得しようとしたリファレンスが存在しない場合に本エラーになります。
リファレンスの登録をAP起動と同期して行っている場合(一時的な登録の場合)、APが起動していない可能性があります。
→ プロセスグループ未起動への対応

リファレンスの登録時にラウンドロビン機能を使用する設定になっている場合、 名前サーバのラウンドロビン拡張機能が有効になっていない可能性もあります。 名前サーバのラウンドロビン拡張機能の設定を確認してください。 この設定については、ドメインの名前サーバを使用している場合は [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ] を、ドメイン外の名前サーバを使用している場合は [ Object Broker C++ > 運用ガイド > 1. 環境設定について ] を参照してください。

リファレンスの登録が永続的となっていて、まだ一度も呼び出しに成功したことがないという場合は、 単にリファレンス登録を行っていない可能性があります。 [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.6. TPシステム > 4.6.4. woiorinfo ] で登録状況を確認するか、リファレンス登録を再実行してみてください。

NO_RESPONSE システム例外を受けた場合、または応答がない場合

クライアント側で指定したタイマ(デフォルト30秒)の間に応答が返ってこない場合にNO_RESPONSE例外が返ります。 NO_RESPONSE及び無応答の場合は、APサーバでデッドロックやループ障害などがおきている可能性があります。
→ APストールへの対応
→ CPU使用率の過剰への対応

また、デッドロックなどで完全に処理が止まっていなくても、 リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性もあります。
→ オペレーション遅延への対応
→ キュー滞留によるレスポンス遅延への対応

J2EEアプリケーションの場合、 同一プロセスグループ上で動作する異なるアプリケーションアーカイブファイルに含まれるアプリケーション間の呼び出しは、 リモート呼び出しとなり別スレッドでの実行完了を待ちます。 このため、実行スレッド不足によるデッドロックが発生する可能性があります。

例えば、同一プロセスグループにwarとejb-jarでアーカイブされたアプリケーションがそれぞれ別々に配備され、 スレッド数の設定が1である場合にサーブレットからEJBを呼び出すと、空きスレッド待ちの状態となってデッドロックが発生します。

プロセスグループのスレッド数を増やすことにより、 スレッド数よりクライアントの同時接続数が少ない場合はデッドロックが解消しますが、 スレッド数以上の要求を受け付けたときはやはりデッドロックとなる可能性があります。

このような場合は呼び出し元と呼び出し先のアプリケーションをひとつのアプリケーションとしてアーカイブして配備するか、 別々のプロセスグループに配備するようにしてください。

遅延

リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性があります。

→ オペレーション遅延への対応

オペレーションの遅延は運用アシスタント機能により自動的に検出することができます。詳細は [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.13. 運用アシスタント ] を参照してください。

エラーの詳細が不明の場合

エラーの詳細は不明ながらもクライアントの利用者からエラーの報告を受けることは多々あります。 可能であればトレースを設定して再現させてください。 トレースが取れない場合も、状況によってはある程度原因が絞り込める可能性があります。

・特定のオペレーションが常に失敗し、それ以外は成功する場合

成功するオペレーションがあるのでAPサーバへ到達するまでの設定に問題はなさそうです。 名前サーバやAP実行基盤の起動状態も問題ありません。 但し名前サーバが正しく見られているものの肝心のリファレンスがない可能性があります。 [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.6. TPシステム > 4.6.4. woiorinfo ] で登録状況を確認するか、リファレンス登録を再実行してみてください。

一番可能性が高いのが特定のオペレーションを含むプロセスグループかアプリケーショングループが 障害状態(または単に起動してない)ケースです。
→ アプリケーショングループ未起動への対応
→ プロセスグループ未起動への対応

・特定のクライアントのみ常に失敗となる

特定のクライアントだけがまったくうまく行かない、成功することがない、という場合です。 WebOTXのサーバではクライアントの設定がありません。 つまりクライアントのアドレスによってどうこうという処理がありません。 このため特定のクライアントのみ失敗するケースでサーバ要因の可能性は低く、 クライアント側の設定に問題がある可能性が高いです。 正常なクライアントとの間で環境の比較を行ってください。

・特定のオペレーションが成功したり失敗したりする

その特定のオペレーションに付与されたユーザデータの違いにより成功したり失敗したりしている可能性があります。 該当のプロセスグループで障害が起きていないか確認してください。 ユーザデータを含めた電文長が制限を越えている可能性も考えられます。 制限の約10M(9999998byte)を越えていないか確認してください。

・一度失敗すると失敗し続け、プロセスグループの再起動で復旧する場合

プロセスグループの再起動にあたり、正常停止操作がタイムアウトし、強制停止操作でようやく停止できたという場合は、 オペレーション実行がいつまで終わらない状況になっていた可能性があります。システムトレース（ [ ドメイン構築・基本設定ガイド > 8. ログ ] ）に実行中だったオペレーションの情報が残っているはずなので確認してください。

関連情報

2.4.3. サーバアプリケーションの障害

アプリケーションが起動/停止しない、アプリケーションの起動/停止に時間がかかる、 アプリケーションが異常終了するといった障害について説明しています。


起動障害

起動操作を行った際に起動完了に著しく時間がかかった、または失敗した場合を起動障害とします。

タイムアウト障害

起動時の処理にはプロセスで一度行うプロセス起動処理とスレッド毎に一度行うスレッド起動処理があり、 どちらも無応答状態を避けるためにタイマ監視しています。 タイマ値まで待っても各処理が完了しない場合は起動失敗とみなして異常終了します。 タイマはデフォルトで10 分(プロセス起動処理10 分、スレッド起動処理10分)となっています。 統合運用管理ツールでプロセスグループの状態を確認したときに、起動処理中の状態が長く続いている場合は、 このタイムアウト障害が繰り返し発生しているがあります(但し プロセス障害時の再起動回数を2以上としている場合です)。
イベントログ・syslogにTPS15-01312、またはTPS10-11101 が出力されている場合は、 プロセス起動処理またはスレッド起動処理で遅延しています。

起動処理失敗

統合運用管理ツールでプロセスグループの状態を確認したときに、起動処理中の状態が長く続いている場合は、 この起動処理失敗が繰り返し発生している可能性があります(但しプロセス障害時の再起動回数を2以上としている場合です)。 プロセスが起動してすぐに停止状態になるといった場合も、起動処理中に例外している可能性があります。
イベントログ・syslogにTPS10-11001 またはTPS10-00402 が出力されている場合は、起動処理中に 例外しています。

遅延

AP 起動に時間がかかった場合、 APを起動後すぐの呼び出しが何故か失敗したが暫くしたら呼べるようになったなどの場合、 起動処理に時間がかかっている可能性があります。 APの起動がなかなか終わらない(プロセスグループのアイコンが緑にならない)という場合も、起動処理が遅延している可能性があります。
異常終了

起動後しばらく動作していたものが異常終了したケースです。
イベントログ・syslogまたは ${INSTANCE_ROOT}/logs/tpsystem/history.act を調査してください。

タイムアウト障害

リクエストを受け付けて実装部分(オペレーション)を呼び出した時に、 そのオペレーションが無応答状態になることを避けるためにタイマ監視しています。 タイマ値まで待ってもオペレーションが完了しない場合は失敗とみなしてイベントログ・syslogに下記エラーメッセージを出力し、 プロセスは終了します。

オペレーション失敗

リクエストを受け付けて実装部分(オペレーション)を呼び出したものの、 それが正常終了せずにJavaランタイム例外やネイティブ例外などを検出した場合、 イベントログ・syslogに下記エラーメッセージ を出力してプロセスは終了します。

正常の終了

・TPS15-01214/TPS15-01210

これらは${INSTANCE_ROOT}/logs/tpsystem/history.actに出力されるプロセス及びプロセスグループの正常停止メッセージであり、 運用停止時に出力されます。異常終了時は別のメッセージが出力されます。 APが異常終了したと思って調査したものの実際には運用停止操作が行われていた、といったことがまれにあります。 ${INSTANCE_ROOT}/logs/tpsystem/history.actを確認し、終了が異常か正常かを見極めてください。

停止障害

停止操作を行った際に停止完了に著しく時間がかかった、または失敗した場合を停止障害とします。
アプリケーションプロセスの異常終了時の停止処理に著しく時間がかかった場合も停止障害とします。

タイムアウト障害

アプリケーショングループ、もしくはプロセスグループの停止処理がタイムアウトしたという場合は、 アプリケーションプロセスの停止処理がタイムアウトした可能性があります。
停止時の処理にはプロセスで一度行うプロセス停止処理とスレッド毎に一度行うスレッド停止処理があり、 どちらも無応答状態を避けるためにタイマ監視しています。 タイマ値まで待っても各処理が完了しない場合は停止失敗とみなしてその後の処理を行わずに異常終了します。 タイマはデフォルトで10分(プロセス異常終了時停止処理10分、スレッド停止処理10分)となっています。
イベントログ・syslogにTPS15-01312やTPS10-11101やTPS10-13301が出力されている場合は、停止処理中にタイムアウトしています。

遅延

アプリケーショングループ、もしくはプロセスグループの停止処理に時間がかかるという場合は、 アプリケーションプロセスの停止処理が遅延している可能性があります。
AP停止に時間がかかった場合は前記タイムアウト障害の一歩手前の状況と考えられます。
関連情報

2.4.4. その他の障害


キュー滞留長が増加する、単位時間あたりの処理件数が減るないし0になる

リクエスト量の増加による処理待ち時間増加やAPの修正による処理時間増加などによって遅延が起きている可能性があります。
→ オペレーション遅延への対応

または完全に処理が止まっているかもしれません。
→ APストールへの対応

クライアントの切断事象が多発する
WebOTXはめったなことではクライアントを切断しません。切断するケースは以下の通りです。

(1)リソース不足

(2)同時接続数超過

(3)プロトコル不正

(4)運用管理操作により切断を指示された場合

(5)システム停止時

(6)通信障害

(7)無通信監視

よって切断が多発するということは上記いずれかが起きているということです。(5)はサービス停止時なのでここでは外します。 (4)も運用操作を実行した場合だけであり、またその運用操作もあまり使われるものではないので外します。 (7)もデフォルトでは機能しません。(1)(3)はほとんど起きたことがありません。ほとんどの切断は(2)か(6)となります。

最大同時接続クライアント数を超過したために、超過した接続要求を切断しているかもしれません。
→ クライアント接続数オーバへの対応

サーバ−クライアント間の回線が細い/遅い場合に接続完了を待てないクライアントが接続要求を再試行することがあります。 この場合、最後以外の接続要求はクライアントで捨てられますがサーバ側に切断事象が来ないため、 サーバでは一定時間後にこれを切断します。
→　ひとつのクライアントから複数の接続要求への対応
CPU使用率が100％近くになる（大きすぎる）
アプリケーションプロセスのCPU使用率が異常に大きい場合、CPUループが発生している可能性があります。 または想定以上にCPUを消費し、処理が遅延している可能性があります。
→ CPU使用率の過剰への対応
ユーザアプリケーションからネットワークドライブへの接続･切断･アクセスに失敗する

スクリプトマネージャ機能を正しく使用して接続･切断をしていない、もしくは、その他の関連する設定が正しく行われていない可能性があります。
→ ユーザアプリケーションによるネットワークドライブへの接続･切断･アクセス失敗への対応

関連情報

2.5. 機能別リンク

2.5.1. TPシステム(Standard/Enterprise)

Standard/EnterpriseのTPモニタ機能によるアプリケーションサーバ障害への対応について説明します。

プロセス異常終了関連

無応答・遅延関連

起動・停止関連

接続・切断関連

環境構築関連

TPモニタ・マネージャライフサイクル関連

関連情報

2.5.2. EJBコンテナ

EJBコンテナの障害の対応について説明します。

関連情報

2.5.3. JNDI

JNDIの障害への対応について説明します。

関連情報

2.5.4. JDBCデータソース

JDBCデータソースの障害への対応について説明します。 JDBCデータソースでは、障害が発生すると、SQLExceptionをスローします。例外メッセージの先頭に[NEC][WOJDBC]がない場合は、JDBCドライバからの例外をそのままスローしています。その場合は、JDBCドライバのサポートに調査を依頼してください。 障害解析のために、次の内容を参考にしてください。

関連情報

2.5.5. Transactionサービス

Transactionサービスは、次の場合に利用されます。


これらの場合に発生する障害への対応について説明します。
関連情報

2.5.6. JMX

JMXの障害への対応について説明します。

関連情報

2.5.7. Object Broker

Object Broker の障害への対応について説明します。ここでは、特に発生頻度の高い障害について説明します。

Object Broker Java での障害

Object Broker C++ での障害


その他の例外やその対処については、次の例外一覧を参照してください。

関連情報

2.5.8. JMS

JMSの障害への対応について説明します。

関連情報

2.5.9. Webサーバ(Apache HTTP Serverベース)

WebOTX Webサーバ (Apache HTTP Serverベース)の障害への対応について説明します。

関連情報

2.5.10. Working Domain Coordinator

ワーキングドメインコーディネータの障害への対応について説明します。

関連情報

2.5.11. 分散管理サーバ

分散管理サーバの障害への対応について説明します。

関連情報

2.5.12. Webコンテナ

Webコンテナの障害への対応について説明します。

Webコンテナでの障害と調査

Webコンテナでの障害対策

Java VMのスレッドダンプ取得

関連情報