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

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

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

表 1. タイムアウト条件-考えられる原因および修正。以下の一般的なタイマー変数を使用して、タイムアウト状態をモニターすることができます。
タイマーの一般タイプ	考えられる原因	考えられるソリューション
入力	クライアントがデータの一部だけを送信し、残りのデータの送信が遅れた。	クライアント側のアプリケーションは、戻されたタイムアウト・マイナー・コードを受信する場合、再試行ロジックの整備を検討する必要があります。
セッション	使用されていないため、セッションがアイドルである。	アイドル・セッションの失敗が問題である場合には、パーシスタント・セッション・タイムアウトの値を増やすか、セッションをもっと頻繁に使用します。
WLM ディスパッチ	次のいずれかの状態が原因で、要求を自由にピックアップできるスレッドが存在しない。すべてのスレッドが、要求の処理に使用されている。現在実行中のスレッドは、 DB2®、 WebSphere® MQ、別のサーバーなどからの応答を待機しています。この場合は、リソースの競合を示すメッセージを探してください。例えば、 z/OS® コンソールでは、 DB2 デッドロックに関するメッセージが表示されることがあります。いずれの場合でも、要求は、サーバント (領域) にディスパッチされる WLM キューでの待機中にタイムアウトします。	すべてのスレッドが要求の処理に使用されている場合、次のいずれかの状態を示します。 WLM が開始できるサーバント領域の数の設定が低すぎる。この値を設定するには、管理コンソールで、 *「サーバー」>「アプリケーション・サーバー」>server_name>「サーバー・インスタンス」を選択します。「Multiple Instances Enabled」をクリックして、「Maximum Number of Instances*」の値を指定します。サーバント領域内で許可されるスレッド数の設定が低すぎる。この数は、管理コンソールまたは WebSphere 変数の「分離ポリシー」設定によって制御されます: `server_region_ workload_profile` ユーザーは、受け取った作業量を処理できるようにサーバーを複製する必要がある。これらの状態はすべて、パフォーマンスの調整が必要であることを示しています。
トランザクション	トランザクション・タイムアウトの原因としては、以下のことが考えられます。 WLM ディスパッチ・タイムアウトの場合と同じか、あるいは遅延のために、トランザクション・コーディネーターが、割り当てられた時間内にトランザクションをコミットまたはロールバックすることができない。	『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。さらに、タイムアウトしたトランザクションに関与したリソースに対する競合を示すメッセージを参考にすることもできます。
出力	出力タイムアウトの原因として考えられるのは、 WLM ディスパッチの場合と同じです (ディスパッチは IIOP、出力は HTTP 用です)。	『WLM ディスパッチ・タイムアウトに対する考えられるソリューション』を参照してください。さらに、 WebSphere 変数 `protocol_accept_ http_work _after_min_srs=1` を使用して、WLM が最小数のサーバント領域を開始するまで HTTP トランスポート・ハンドラーが要求をディスパッチしないようにすることができます。