| キュー滞留によるレスポンス遅延への対応 |
サーバAP はプロセス数やスレッド数に応じた多重度を持っており、この多重度までのリクエストは同時に 処理することができます。しかし多重度以上のリクエストが発生した場合、そのリクエストは実行中のリク エストが完了して空きスレッドが出来るまでの間キューイングされます。キューイングされるリクエスト数が 増大すると著しくレスポンスが悪化します。
キュー滞留によりレスポンスが著しく遅延（運用アシスタント機能の応答期限設定を超える）すると、イベ ントログ・シスログに以下のメッセージが出力されます。
UNIX:
“OTX20220100 The multiplicity of process group xxx is insufficient. Please examine an increase inthe 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 にストールや想定外の遅延といった問題があるわけではないが、慢性的にキュー滞留が発生し
ており、アイドルスレッド数が常に不足している場合は絶対的に多重度が足りていない状況だと考え
られます。そのときは多重度を増やすことにより現象が改善できる場合があります。プロセスグルー
プの以下の設定を見直してください。
「プロセス制御」の「プロセス数」
「スレッド制御」の「スレッド数」
予防ではありませんが、キュー滞留数の上限を設定することにより無応答の処理を制限することが
出来ます。これによりシステム全体がスローダウンすることを防ぐことができます。
プロセスグループの以下の設定を見直してください。
「キューの最大数」の「キューの最大数」
運用アシスタントの多重度自動変更機能を利用すると、キュー滞留により応答性能が劣化した場合
に、自動的に多重度を増加させ、応答性能を回復させることができます。
設定箇所は以下になります。
「運用アシスタント」の「多重度最適化支援」「多重度最適化支援:応答期限」
詳細は「TPモニタの運用操作 2.40.3 多重度の最適化支援」を参照してください。
キュー滞留の原因がAP のストールや想定外の遅延の場合は問題のAP を修正する必要があります。
キュー滞留の原因がAP のストールである場合で、原因不明などでAP の修正が困難な場合は回避
策として該当オペレーションに実行時間上限の設定を行なうことによりストール事象を回避すること
ができます。実行時間上限で設定した時間経過しても応答がない場合はTP モニタにより強制終了
させられます。オペレーションの以下の設定を見直してください。
「オペレーションの自動活性」の「実行時間上限」
設定の際は運用アシスタントの実行時間上限適正値算出機能を利用することができます。詳しくは
「TPモニタの運用操作 2.40.4 実行時間上限の適正値算出」を参照してください。