[z/OS]

タイムアウト状態 - 考えられる原因および修正

このファイルでは、 これらのタイムアウト状態をモニターするための一般的なタイマー変数およびツールをリストします。

最初に有効期限が切れるタイマーは、修正が必要な実際の問題を示さない場合があります。 タイムアウト状態を適切に診断するには、 特定のサーバント領域に有効なタイマー値をすべて知っている必要があります。

表 1. タイムアウト状態 - 考えられる原因および修正. 以下の一般的なタイマー変数を使用して、タイムアウト状態をモニターすることができます。
タイマーの一般タイプ 考えられる原因 考えられるソリューション
入力 クライアントがデータの一部だけを送信し、 残りのデータの送信が遅れた。 クライアント側のアプリケーションは、 戻されたタイムアウト・マイナー・コードを受信する場合、 再試行ロジックの整備を検討する必要があります。
セッション 使用されていないため、セッションがアイドルである。 アイドル・セッションの失敗が問題である場合には、 パーシスタント・セッション・タイムアウトの値を増やすか、セッションをもっと頻繁に使用します。
WLM ディスパッチ 次のいずれかの状態が原因で、 要求を自由にピックアップできるスレッドが存在しない。
  • すべてのスレッドが、要求の処理に使用されている。
  • 現在実行中のスレッドが DB2®、WebSphere® MQ、別のサーバーなどからの応答を待機している。 この場合、リソースに対する競合を示すメッセージを検索します。 例えば、z/OS® コンソール上で DB2 デッドロックに関するメッセージが表示されることがあります。

いずれの場合でも、要求は、 サーバント (領域) にディスパッチされる WLM キューでの待機中にタイムアウトします。

すべてのスレッドが要求の処理に使用されている場合、次のいずれかの状態を示します。
  • WLM が開始できるサーバント領域の数の設定が低すぎる。 この値を設定するには、管理コンソールで、 「サーバー」>「アプリケーション・サーバー」>server_name>「サーバー・インスタンス」を選択します。 「Multiple Instances Enabled」をクリックして、「Maximum Number of Instances」の値を指定します。
  • サーバント領域内で許可されるスレッド数の設定が低すぎる。 この数は、管理コンソールでの「Isolation Policy」設定、 または WebSphere 変数 server_region_ workload_profile で制御されます。
  • ユーザーは、受け取った作業量を処理できるようにサーバーを複製する必要がある。
これらの状態はすべて、パフォーマンスの調整が必要であることを示しています。
トランザクション トランザクション・タイムアウトの原因としては、 以下のことが考えられます。
  • WLM ディスパッチ・タイムアウトの場合と同じか、あるいは
  • 遅延のために、トランザクション・コーディネーターが、 割り当てられた時間内にトランザクションをコミットまたはロールバックすることができない。
『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。 さらに、タイムアウトしたトランザクションに関与したリソースに対する競合を示すメッセージを参考にすることもできます。
出力 出力タイムアウトの原因として考えられるのは、 WLM ディスパッチの場合と同じです (ディスパッチは IIOP、出力は HTTP 用です)。 『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。 さらに、WebSphere 変数 protocol_accept_http_work_after_min_srs=1 を使用して、 WLM が最小数のサーバント領域を開始するまで、 HTTP トランスポート・ハンドラーが要求をディスパッチしないようにすることが可能です。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_fixtimeout
ファイル名:rtrb_fixtimeout.html