APストールへの対応

APストールへの対応

事象説明

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

状況の確認方法

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

プロセス状態の確認

ストールしたプロセスではその後の要求に対して処理ができなくなるため、キュー滞留が発生する可能性があります。まずはキュー滞留しているプロセスグループがないかご確認ください。キュー滞留数確認方法は「キュー滞留によるレスポンス遅延への対応」の状況の確認方法をご覧ください。

スレッドの状態の確認

スレッドの状態を参照することにより、そのプロセスがどのオペレーションを実行しているのか状況を確認できます。特に処理時間が長時間経過しているものに問題が発生している可能性が高いです。統合運用管理ツールからプロセスグループの属性[スレッド情報]を参照することにより、実行中のオペレーションを判別することができます。
また該当AP がJava である場合、スタックを採取する事でどのオペレーションを実行中なのか確認することが出来ます。スタック採取方法は統合運用管理ツールより該当プロセスグループを選択して、右クリックで「スタックトレースの採取(stackTrace)」を実行してください。

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

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 examine an increase in the number of process or threads


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

問題の検出方法

実行時間上限の設定

AP ストールの検出方法として、該当オペレーションに実行時間上限の設定を行なうことにより、ストール事象を検出することができます。実行時間上限で設定した時間経過しても応答がない場合は TP モニタにより検出され、強制終了させられます。オペレーションの以下の設定を見直してください。
「オペレーションの自動活性」の「実行時間上限」
設定の際は運用アシスタントの実行時間上限適正値算出機能を利用することができます。詳しくは「TPモニタの運用操作 2.40.4 実行時間上限の適正値算出」を参照してください。

原因の特定

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

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

採取資料

イベントログ(アプリケーション、システム)・シスログ

${INSTANCE_ROOT}/logs/tpsystem ディレクトリ配下全て

ストールしているAP がJava の場合は統合運用管理ツールより該当プロセスグループを選択して、右クリックで「スタックトレースの採取(stackTrace)」を実行してください。アプリケーションログにスタックトレースが出力されます。

復旧方法

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

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

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

運用アシスタントの多重度自動変更機能を利用すると、ＡＰストールが引き起こす応答性能劣化を検出し、自動的に多重度を増加させ、新たな要求を実行させることができます。
設定箇所は以下になります。詳細は「TPモニタの運用操作 2.40.3 多重度の最適化支援」を参照してください。
「運用アシスタント」の「多重度最適化支援」「多重度最適化支援:応答期限」

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

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

予防のための対策

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

問題のAP の修正

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

原因不明などでAP の修正が困難な場合は回避策として該当オペレーションに実行時間上限の設定を行なうことによりストール事象を回避することができます。実行時間上限で設定した時間経過しても応答がない場合はTP モニタにより強制終了させられます。オペレーションの以下の設定を見直してください。
「オペレーションの自動活性」の「実行時間上限」
設定の際は運用アシスタントの実行時間上限適正値算出機能を利用することができます。詳しくは「TPモニタの運用操作 2.40.4 実行時間上限の適正値算出」を参照してください。

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

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

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