サーバAP はプロセス数やスレッド数に応じた多重度を持っており、この多重度までのリクエストは同時に処理することができます。しかし多重度以上のリクエストが発生した場合、そのリクエストは実行中のリクエストが完了して空きスレッドが出来るまでの間キューイングされます。キューイングされるリクエスト数が増大すると著しくレスポンスが悪化します。
キュー滞留によりレスポンスが著しく遅延（運用アシスタント機能の応答期限設定を超える）すると、イベントログ・syslogに以下のメッセージが出力されます。
UNIX:
OTX20220100 The multiplicity of process group xxx is insufficient. Please examine an increase in the number of process or threads.
OTX20220100 プロセスグループxxx の多重度が不足しています。プロセス数/スレッド数の増加を検討してください。
システムレベルでの最大キュー滞留数の参照
キューはプロセスグループ単位で作成されていますが、その中で現在最も多いキュー滞留数を確認することができます。これを参照することにより、システム全体の滞留状況が確認できます。
StatsHolderMBean（CLIName: tpsystem.Queue 統合運用管理ツール: [統計情報]-[domain]-[TP システム]-[キュー]）の最大キュー滞留数(MaxStayMsgNum)のカレント値を参照します。
キューはプロセスグループ単位で作成されていますが、キュー滞留数の合計を確認することができます。これを参照することにより、システム全体の滞留状況が確認できます。
StatsHolderMBean（CLIName: tpsystem 統合運用管理ツール: [統計情報]-[domain]-[TP システム]）のキュー滞留数(queueingCount)のカレント値を参照します。
該当プロセスグループのキュー滞留数を確認します。これを参照することにより、問題のプロセスグループが特定できます。
StatsHolderMBean（tpsystem.applicationGroups.apg_name.processGroups.pg_name）のキュー滞留数(queueingCount)のカレント値を参照します。
実際にキュー滞留している要求がどのオペレーションであるかを確認することが出来ます。
StatsHolderMBean（tpsystem.ap_name.module_name.interface_name.operation_name）のキュー滞留数(queue)のカレント値を参照します。
スレッドの状態を参照することにより、そのプロセスがどのオペレーションを実行しているのか状況を確認できます。処理時間が長時間経過しているものがある場合、それが原因でキュー滞留数が多くなっている可能性があります。
統合運用管理ツールからはプロセスグループの「動作情報」タブにある「スレッド情報」を参照します。運用管理コマンドからはtpsystem.applicationGroups.apg_name.processGroups.pg_name のスレッド情報(threadStatistic)を参照します。
実際にキュー滞留を検出する方法としては以下の方法があります。
統計情報におけるシステムレベルでのキュー滞留数の監視
StatsHolderMBean（CLIName: tpsystem. Queue 統合運用管理ツール: [統計情報]-[domain]-[TP システム]-[キュー]）の最大キュー滞留数(MaxStayMsgNum)のカレント値の閾値上限を設定してモニタリングします。該当システムの任意のキューで上限値を越えた場合に通知が行なわれます。
StatsHolderMBean（CLIName: tpsystem.applicationGroups.apg_name.processGroups.pg_name 運用管理ツール: [統計情報]-[domain]-[TP システム]-[アプリケーショングループ]-[apg_name]-[プロセスグループ]-[pg_name]）のキュー滞留数(queueingCount)のカレント値の閾値上限を設定してモニタリングします。指定したプロセスグループで上限値を超えた場合に通知が行なわれます。
[TP システム]の[運用アシスタント]タブにある属性[応答期限](tpsystem.multiOvertimeLimit)を設定してください。キューの最後のリクエストがこの応答期限を超えると予測される場合に、通知が行なわれます。
統合運用管理ツールの「スレッド情報」で各スレッドの状態を確認してください。オペレーション実行中
で且つ実行開始からの時間が通常考えられない長時間となっている場合、そのオペレーションで無応答状態となっており、それが原因でキューイング数が増加した可能性があります。 [ APストールへの対応 ] を参照してください。
次にオペレーションジャーナルで障害発生までのオペレーション処理時間を確認してください。処理時間が予定よりも長くなっている場合はその遅延が原因の可能性があります。 [ オペレーション遅延への対応 ] を参照してください。
次にオペレーションジャーナルで処理件数と稼動スレッド数を確認してください。処理件数が想定よりも多く、全てのスレッドが稼動している状態が続いており、オペレーション処理時間自体には問題無いと考えられる場合は、純粋に要求数が多くてサーバAP の処理が追いついていない可能性があります。
実際にこの現象が発生してしまった場合の復旧方法について説明します。
動的多重度変更によるプロセス数の増加
キュー滞留が発生しているプロセスグループのプロセス多重度を増加させ滞留している要求を実行させます。ただしこの場合、ストールしているプロセスはそのまま存在しつづけます。またバックエンドでロックしている場合、この方法では解消されない場合もあります。増加したあとしばらくキュー滞留が解消されているかどうか見極めてください。
プロセスグループを選択して「多重度変更(multiplex)」を実行してプロセス数を現状より増やして実行して下さい。
プロセスグループの再起動
動的多重度変更では現在ストールしているプロセスを停止させることができません。問題のプロセスがCPU やメモリなどリソースを消費している場合や動的多重度変更では効果が見られない場合プロセスグループを再起動する必要があります。なおストールしている場合は、「通常停止(stop)」は失敗してしまう可能性があります。その場合は「強制停止(forcibleStop)」させてください。
システムの再起動
システム全体に影響が及んでしまっている場合は局所的な対応では復旧しない可能性があります。 その場合はシステム再起動を行なってください。
この問題を予防するための対策については以下の方法があります。
プロセスグループの多重度の見直し
AP にストールや想定外の遅延といった問題があるわけではないが、慢性的にキュー滞留が発生しており、アイドルスレッド数が常に不足している場合は絶対的に多重度が足りていない状況だと考えられます。そのときは多重度を増やすことにより現象が改善できる場合があります。プロセスグループの「プロセス制御」の「プロセス数」と、「スレッド制御」の「スレッド数」の設定を見直してください。
キュー滞留数の上限設定
予防ではありませんが、キュー滞留数の上限を設定することにより無応答の処理を制限することが出来ます。これによりシステム全体がスローダウンすることを防ぐことができます。
プロセスグループの「キューの最大数」タブにある「リクエストキューのサイズ」の設定を見直してください。
運用アシスタントによる多重度自動変更
運用アシスタントの多重度自動変更機能を利用すると、キュー滞留により応答性能が劣化した場合に、自動的に多重度を増加させ、応答性能を回復させることができます。
設定箇所は「運用アシスタント」の「多重度最適化支援」「多重度最適化支援:応答期限」になります。詳細は、
[ ドメイン構築・基本設定ガイド
> 7. WebOTXの内部サービス >
7.1. TPシステム >
7.1.13. 運用アシスタント >
7.1.13.2. 多重度の最適化支援 ]
を参照してください。
問題のAP の修正
キュー滞留の原因がAP のストールや想定外の遅延の場合は問題のAP を修正する必要があります。
実行時間上限の設定
キュー滞留の原因がAP のストールである場合で、原因不明などでAP の修正が困難な場合は回避策として該当オペレーションに実行時間上限の設定を行なうことによりストール事象を回避することができます。実行時間上限で設定した時間経過しても応答がない場合はTP モニタにより強制終了 させられます。オペレーションの「オペレーション制御」タブにある「実行時間の上限」の設定を見直してください。設定の際は運用アシスタントの実行時間上限適正値算出機能を利用することができます。詳細は、
[ ドメイン構築・基本設定ガイド
> 7. WebOTXの内部サービス >
7.1. TPシステム >
7.1.13. 運用アシスタント >
7.1.13.3. 実行時間上限の適正値算出 ]
を参照してください。