WebOTX Manual V10.2 (第4版)

目次を表示

APストールへの対応

事象説明

サーバAP の処理がストールした場合、最初は特定の処理のみが応答を返さない現象となりますが、さらに多重度を使い切るなどキュー滞留に影響したりするとプロセスグループ全体に影響が広がります。さらに応答を返さないリクエストが滞留するとWeb サーバのスレッド枯渇などを招いてしまい、システム全体へ影響が広がります。

状況の確認方法

AP ストールを確認するには以下の方法があります。

プロセス状態の確認

キュー滞留によるレスポンス遅延への対応

スレッドの状態の確認

リクエスト多重度超過への対応

UNIX:

OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00825 TPBASE SG MAX ASYNC TX.

OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00825 同時実行できる非同期トランザクション数を超えました。

キュー滞留によるレスポンス遅延への対応

UNIX:

OTX20220100 The multiplicity of process group xxx is insufficient. Please increase the number of process or threads.

OTX20220100 プロセスグループxxx の多重度が不足しています。プロセス数/スレッド数の増加を検討してください。

問題の検出方法

実行時間の上限の設定

AP ストールの検出方法として、該当オペレーションに実行時間の上限の設定を行なうことにより、ストール事象を検出することができます。実行時間の上限で設定した時間経過しても応答がない場合はTP モニタにより検出され、強制終了させられます。オペレーションの「オペレーション制御」タブにある「実行時間の上限」の設定を見直してください。設定の際は運用アシスタントの実行時間の上限の適正値算出機能を利用することができます。詳細は、 [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント > 実行時間の上限の適正値算出 ] を参照してください。

原因の特定

該当AP がJava の場合、無応答障害発生中に、統合運用管理ツールより該当プロセスグループを選択して、右クリックで「スタックトレースの採取(stackTrace)」を実行してください。任意のタイミングでスタックトレースをAP トレースに記録することが可能です。これにより行レベルでストール箇所が判明します。

統合運用管理ツールから、プロセスグループの「動作情報」タブにある「スレッド情報」を定期的に参照（F6）し、オペレーションを実行しているスレッドでCPU使用時間が増加するか確認することもできます。CPU使用時間が増加している場合はCPUループが発生している可能性があります。逆にCPU使用時間増加していない場合は、バックエンド処理などの「待ち」状態で止まっている可能性が考えられます。
CPUループの可能性がある場合は、 [ CPU使用率の過剰への対応 ] を参照してください。

採取資料

イベントログ(アプリケーション、システム)・syslog
${INSTANCE_ROOT}/logs/tpsystem ディレクトリ配下全て

${INSTANCE_ROOT}/logs/webcontainer ディレクトリ配下全て(Web コンテナを使用している場合)
${INSTANSE_ROOT}/logs/tpsystem/history.act, history.<数字>, sysmsg.trc, sysmsg.<数字>
イベントジャーナル、キュー滞留数 : ${INSTANCE_ROOT}/logs/tpsystem/logcollect

復旧方法

実際にこの現象が発生してしまった場合の復旧方法について説明します。

動的多重度変更によるプロセス数の増加

ストールが発生しているプロセスグループのプロセス多重度を増加させ新たな要求を実行させます。ただしこの場合、ストールしているプロセスはそのまま存在しつづけます。またバックエンドでロックしている場合、この方法では解消されない場合もあります。増加したあとしばらくキュー滞留が解消されているかどうか見極めてください。
プロセスグループを選択して「多重度変更(multiplex)」を実行してプロセス数を現状より増やして実行して下さい。

運用アシスタントによる多重度自動変更

運用アシスタントの多重度自動変更機能を利用すると、ＡＰストールが引き起こす応答性能劣化を検出し、自動的に多重度を増加させ、新たな要求を実行させることができます。
設定箇所は以下になります。詳細は、 [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント > 多重度の最適化支援 ] の「多重度最適化支援:目標応答時間」を参照してください。

プロセスグループの再起動

動的多重度変更では現在ストールしているプロセスを停止させることができません。問題のプロセスがCPU やメモリなどリソースを消費している場合や動的多重度変更では効果が見られない場合プロセスグループを再起動する必要があります。なおストールしている場合は、「通常停止(stop)」は失敗してしまう可能性があります。その場合は「強制停止(forcibleStop)」させてください。

システムの再起動

システム全体に影響が及んでしまっている場合は局所的な対応では復旧しない可能性があります。その場合はシステム再起動を行なってください。

予防のための対策

この章では、WebOTXの運用を行なうためのコマンドやWebOTX運用ツールを用いたシステムの運用管理方法について、また障害解析について詳細な説明します。

問題のAP の修正

完全に問題を解決するためにはAP を修正する必要があります。スレッド情報を参照して経過時間が異常に長いオペレーションがある場合そのオペレーションがストールしていると考えられます。
なお該当AP がJava である場合、該当アプリケーショングループを強制停止することで、スタックによりストール箇所の特定を行なうことができます。

実行時間の上限の設定

原因不明などでAP の修正が困難な場合は回避策として該当オペレーションに実行時間の上限の設定を行なうことによりストール事象を回避することができます。実行時間の上限で設定した時間経過しても応答がない場合はTP モニタにより強制終了させられます。オペレーションの「オペレーション制御」タブにある「実行時間の上限」の設定を見直してください。設定の際は運用アシスタントの実行時間の上限の適正値算出機能を利用することができます。詳細は、 [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント > 実行時間の上限の適正値算出 ] を参照してください。

キューイング数上限の設定

キューイング数上限を設定することにより、想定外のキューイングがあった場合は即クライアントにエラーメッセージを返却することができます。詳しくは [ キュー滞留によるレスポンス遅延への対応 ] を参照してください。

プロセス数、スレッド数の設定

プロセス、スレッドの多重度が小さい場合、クライアントからの要求数や処理時間によってはなかなか応答が返らず、ユーザはストールしているのではないかと感じることがあります。ただ単に応答時間が長くなっているだけの場合はプロセス数、スレッド数が適切であるか確認してください。

プロセッサ数の設定

Web サーバを使用している場合、 [ 構築・運用 > チューニング > Webコンテナ > プロセッサ数 ] を参照し、プロセッサ数が適切であるか確認してください。