NEC Mark
WebOTX Manual V10.2 (第4版)

目次を表示

キュー滞留数超過への対応

事象説明

    各プロセスグループに対するリクエストは空きスレッドがあれば即実行されますが空きがない場合は空きができるまで実行待ちとなります。実行待ちはFIFOのキューで管理しますが、いくつまでキューイングできるかは設定可能です(デフォルトは無制限)。各プロセスグループの重要度やレスポンス許容時間などを踏まえて、キュー滞留数の上限を個々に設定することが可能です。キューに上限一杯のリクエストがキューイングされた状況で更にリクエストが来た場合、そのリクエストは上限超過ということでエラーになります。この時、イベントログ・syslogには以下のようなメッセージが出力されます。 

      OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1: TPS07-00816 MAX QUEUING OVER.
    また、クライアントには以下のようなメッセージが出力されます。 
      NO_RESOURCES(minor=3840)
    このエラーが起きる原因は2つあります。

    (1)APの処理が予定よりも遅延しているか無応答となっている場合
    (2)純粋に要求数が多くて処理が追いつかない場合

原因の特定方法

    2つの原因のいずれが起きているかを特定する必要があります。まず統合運用管理ツールから該当プロセスグループの「スレッド情報」で各スレッドの状態を確認してください。オペレーション実行中で且つ実行開始からの時間が通常考えられない長時間となっている場合、そのオペレーションで無応答状態となっており、それが原因でキューイング数が超過した可能性があります。 [ APストールへの対応 ] を参照してください。

    次にオペレーションジャーナルで障害発生までのオペレーション処理時間を確認してください。処理時間が予定よりも長くなっている場合はその遅延が原因の可能性があります。 [ オペレーション遅延への対応 ] を参照してください。

    次にオペレーションジャーナルで処理件数と稼動スレッド数を確認してください。処理件数が想定よりも多く、また、全てのスレッドが稼動している状態であれば純粋に要求数が多くて処理が追いついていない可能性があります。

復旧方法

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

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

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

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

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

      システムの再起動

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

予防のための対策

    この問題を予防するための対策については以下の方法があります。

      プロセスグループの多重度の見直し

        (ストールなど)APに問題があるわけではないが、慢性的にキュー滞留が発生しており、アイドルスレッド数が常に不足している場合は絶対的に多重度が足りていない状況だと考えられます。そのときは多重度を増やすことにより現象が改善できる場合があります。プロセスグループの「プロセス制御」の「プロセス数」と 「スレッド制御」の「スレッド数」の設定を見直してください。但し、そのAPでの処理内容やサーバ構成によっては多重度を上げてもスループットが上がらない可能性があります。

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

        運用アシスタントの多重度自動変更機能を利用すると、キュー滞留による応答性能劣化を検出し、自動的に多重度を増加させることができます。これにより、現象が改善できる場合があります。
        設定箇所は「運用アシスタント」の「多重度最適化支援」「多重度最適化支援:応答期限」になります。詳細は、 [ 構築・運用 > ドメインの構築 > TPシステム > 運用アシスタント > 多重度の最適化支援 ] を参照してください。

      キュー滞留数の上限設定の見直し

        APに問題がなく多重度の変更が容易でない場合、キュー滞留数上限を増やすことでエラー応答を引き起こしづらくさせることができます。
        プロセスグループの「キューの最大数」の「リクエストキューのサイズ」の設定を見直してください。

      問題のAPの修正

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

      実行時間の上限の設定

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

      現状維持

        上限を設定した理由として、特定のプロセスグループにCPUやリソースを占有されることを避ける、レスポンス上限を保証する、などがありますが、こういった理由で設定している場合は安易に上限を変更しない方がよいかもしれません。但し、該当のエラーを受けた利用者に対して事象を説明し、一定時間後にリトライなどを依頼する必要があります。

対象となるエラー事象

    TPS07-00816、NO_RESOURCES（3840）

関連情報
Copyright (C) 1998 - 2020 NEC Corporation. All rights reserved.