WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化
このトピックは、z/OS オペレーティング・システムにのみ適用されます。

タイムアウト値の変更についてのガイドライン

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

一般に、タイムアウト値を増やすのは最後の手段にすべきです。 あるいは、複数のタイムアウト異常終了ダンプによりシステム・パフォーマンスの問題が起こるのを防ぐための、 一時的な措置にとどめるべきです。 タイムアウト条件の適切な診断を行わずにタイムアウト値を大きくすると、 同じタイムアウト条件の異常終了やダンプの頻度が減少したり、 またはシステムやアプリケーションのパフォーマンスが遅くなるという結果しか得られない可能性があります。

これらのタイマー変数の値を変更する方法、およびこれらの変数を内部変数にマップする方法についての情報は、タイムアウト値による制御の振る舞いを参照してください。

共通タイマー変数およびこれらのタイムアウト条件をモニターするツール

WebSphere 変数および (ある場合は) その他のタイマーとの関係 タイムアウト条件ごとの処理のモニター方法 値を調整する場合の注意点
WLM タイムアウト

HTTP 作業および Scalable Messaging Support については、WLM タイマーは設定されず、ConnectionResponseTimeout のみ有効となります (ディスパッチ・ウィンドウ全体で有効)。

SMF は WLM キュー・タイムにデータを提供します。 作業がサーバントに到達するのにかかる時間は、WLM が開始する サーバント数、ユーザーが開始させる数、 作業が分散されるサービス・クラス数、 ユーザーが実行する処理量などによって決まります。
ConnectionIOTimeOut

なし。

この振る舞いのモニターは、簡単ではありません。 トレース・ポイントをオンにすると、 この入力タイムアウト設定が原因でクライアントが失敗したかどうかが示されますが、 トレースを行うとパフォーマンスに影響します。
  • メッセージを待ちながら、どれくらい長く制御領域ワーカー・スレッドをブロックするか ?
  • 着信 HTTP 要求はどれくらいの大きさであるか ? これらが大きくなるほど、 ネットワークを介して要求全体を読み込むのにさらに時間がかかる可能性があります。
ConnectionResponseTimeout

アプリケーション・コンポーネントがトランザクションを開始する場合に、 トランザクション・タイマーが設定されている場合があります。

この振る舞いのモニターは簡単ではありませんが、 このタイムアウト条件が発生すると、 コントローラーは、異常終了 EC3 でサーバント (領域) を終了します。
  • 応答を待ちながら、どれくらい長くクライアントを停止するか ?
  • 要求の処理時間が長すぎると判断せずに、 どれくらい長くサーバント (領域) 内のスレッドを応答に関する作業に専念させるか ?
  • サーバント (領域) 内に複数のアプリケーション・スレッドがある場合は、 そのうちの 1 つでもタイムアウトになった時点でスレッドはすべて終了されます。 このように作業にロスが生じるので、 こうしたタイムアウトが発生する頻度を少なくした方が良い場合もあります。
ConnectionKeepAliveTimeout

なし。他のすべてのタイマーが作業の処理に関連するものであるのに対して、 このタイマーは作業が存在しないときに発生する内容に関連しています。

なし。 要求間の経過時間と、新規セッション確立にかかるコストを比べてください。 新規セッションの始動コストがかからないようにするため、 アイドル・セッションをしばらく維持すべきですが、 リソース使用が積み重なっていくと最終的には問題になるため、 セッションを永続的に維持すべきではありません。
要求 タイムアウト (ORB サービス)

なし。この変数はクライアント・サイドのタイムアウトで、IIOP のみです。

クライアント・サイドで発生するタイムアウトの監視以外はなし。 どれくらい長くクライアントを待機させるか ?
ORB リスナー・キープアライブ ORB SSL リスナー・キープアライブ

なし。これらの変数は、 アイドル期間中のセッション・アクティビティーに関係するもので、IIOP の場合のみ適用されるため、 これらのタイマーと ConnectionKeepAliveTimeout タイマーに相互作用はありません。

SOCK_TCP_KEEPALIVE
値とその結果について詳しくは、TCP/IP APAR PQ18618 をお読みください。
アイドル・セッションをタイムアウトにすることが有用か ? アイドル・セッションは、リソースを消費する可能性があるため、通常は実行しません。 ただし、 タイムアウトの検出に TCP/IP スタック間でネットワーク・トラフィックが必要になります。 他のアイドル・セッションでトラフィックを作成すると、 ネットワークに対して望ましくない影響を与える場合があります。
Total Transaction Lifetime Timeout

この変数は、Maximum Transaction Timeout 変数によって示される最大値までアプリケーションによってオーバーライドすることができます。 これは、 アプリケーションで設定できるトランザクションの完了時間を制限します。 output タイマーが原因で作業がタイムアウトになる場合もありますが、 トランザクション・タイマーと output タイマーは互いを認識しているわけではありません。

コントローラーは、 メッセージ BBOT0003W を発行してタイムアウト条件を示し、 サーバント (領域) を異常終了 EC3、理由コード 04130002 または 04130005 で終了します。
  • 応答を待ちながら、どれくらい長くクライアントを停止するか ?
  • 要求の処理時間が長すぎると判断せずに、 どれくらい長くサーバント (領域) 内のスレッドを応答に関する作業に専念させるか ?
  • サーバント (領域) 内に複数のアプリケーション・スレッドがある場合は、 そのうちの 1 つでもタイムアウトになった時点でスレッドはすべて終了されます。 このように作業にロスが生じるので、 こうしたタイムアウトが発生する頻度を少なくした方が良い場合もあります。
最大トランザクション・タイムアウト

この変数が設定されている場合、 アプリケーションで設定できるトランザクションの完了時間を制限します。 最大トランザクション・タイムアウト変数が設定されていない場合、アプリケーションのトランザクションは、Total Transaction Lifetime Timeout 変数に設定されている時間制限によって制御されます。

なし。 考慮事項については、
transaction_ defaultTimeout
と同じ。
transaction_ recoveryTimeout

なし

なし。 1 つのコントローラー (領域) が、 未確定のトランザクションを解決するために必要なその他のコントローラーを待っている間はロックされています。 これらのリソースをどれくらい長く保持する余裕があるか ?



関連タスク
トラブルシューティング管理
関連資料
タイマーの概要
タイムアウト状態の診断データ分析についてのガイドライン
タイムアウト状態 - 考えられる原因および修正
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/rtrb_altertimeout.html