TCP/IP バッファー・サイズの調整

WebSphere® Application Server は、TCP/IP ソケット通信メカニズムを広範囲にわたって使用します。 TCP/IP ソケット接続では、送受信バッファー・サイズによって受信ウィンドウが定義されます。受信ウィンドウは、送信が可能で、送信が中断されるまで受信が禁止されるデータ・サイズを指定します。送信データ量が大きすぎると、バッファーがオーバーランし、転送は中断されます。データ転送の中断を制御する仕組みは、フロー制御といいます。 TCP/IP バッファーの受信ウィンドウ・サイズが小さすぎる場合は、受信ウィンドウ・バッファーが頻繁にオーバーランし、受信バッファーが空になるまでフロー制御メカニズムはデータ転送を停止します。

このタスクの概要

フロー制御は CPU 時間を大量に消費するため、データ転送が中断した結果、追加のネットワーク遅延が発生することがあります。通常の操作条件下では、フロー制御を避けるために、バッファー・サイズを増加することをお勧めします。バッファー・サイズを大きくすると、フロー制御の発生確率が低下し、CPU 利用率が高まります。ただし、バッファー・サイズが大きいと、場合によってはパフォーマンスが低下することがあります。 TCP/IP バッファーが大きすぎて、アプリケーションがデータを十分な速度で処理できない場合は、ページングが増加することがあります。重要なのは、バッファーに累積されるデータ量がシステムの処理能力を超えない範囲で、フロー制御を回避できる十分大きな値を指定することです。

デフォルトのバッファー・サイズは 8 KB です。最大サイズは 8 MB (8096 KB) です。最適なバッファー・サイズはスイッチやシステムのタイプ、肯定応答タイミング、エラー率やネットワーク・トポロジー、メモリー・サイズ、およびデータ転送サイズなど、複数のネットワーク環境因子によって決まります。データ転送サイズが極端に大きい場合は、バッファー・サイズを最大値まで設定して、スループットを高め、フロー制御の発生頻度を低下させ、CPU コストを削減することができます。

Web サーバーと WebSphere Application Server の間のソケット接続のバッファー・サイズは、 64KBに設定されます。通常は、この値で十分です。

アプリケーションが IBM® Developer Kit for Java(TM) JDBC ドライバーまたは IBM Toolbox for Java™ JDBC ドライバーを使用してリモート・データベースにアクセスする場合、フロー制御が問題になることがあります。データ転送サイズが大きいと、フロー制御が CPU 時間を大量に消費することがあります。 IBM Toolbox for Java JDBC ドライバーを使用する場合は、カスタム・プロパティーを使用して、各データ・ソースのバッファー・サイズを構成できます。大きなバッファー・サイズ (1 MB など) を指定することをお勧めします。

システム全体に関する設定の一部は、ソケットの 8 KB のデフォルト・バッファー・サイズをオーバーライドします。一部のアプリケーション ( WebSphere Commerce Suiteなど) では、バッファー・サイズが 180 KB の場合、フロー制御が削減され、通常はページングに悪影響を与えることはありません。最適値は特定のシステム特性によって決まります。ご使用のシステムに最適なバッファー・サイズを決定する前に、値をいくつか試す必要があります。

[AIX] 詳しくは、 System p および AIXでの IBM WebSphere Application Server の実行: 最適化とベスト・プラクティスの TCP/IP ネットワーク設定を参照してください。さらに、 TCP ストリーミング・ワークロードのチューニングを参照してください。

[Linux] 詳しくは、 Linux チューニングを参照してください。

[Windows] TCP/IP バッファー・サイズのチューニングについては、「 Windows 2000 and Windows Server 2003 TCP Features 」資料を参照してください。 TcpWindowSize の値を 8388608 または 16777216 に設定することを検討してください。

[z/OS] TCP/IP が原因で、リモート・メソッドが非常に遅くなることがあります。

手順

システム全体の値を変更するには、以下のステップを実行します。

TCP/IP バッファー・サイズをチューニングします。
1. TCP/IP 構成を変更します。
  1. Change TCP/IP Attribute (CHGTCPA コマンド) を実行します。
  2. 「Change TCP/IP Attributes」ウィンドウで F4 を押すことで、バッファー・サイズを表示して、変更します。バッファー・サイズが TCP 送受信バッファー・サイズとして表示されます。新規の値を入力して、変更を保存します。
2. TCP/IP をリサイクルしてから、CPU およびページング率をモニターし、推奨システム・ガイドライン内に収まっているかどうかを判別します。
TCP/IP バッファー・サイズをチューニングします。
1. まず、必ずご使用のシステムに十分なソケットを定義し、デフォルトのソケット・タイムアウト時間 (180 秒) が長すぎることのないようにします。十分なソケットを許可するには、次のように BPXPRMxx parmlib メンバーを更新します。
  1. AF_INET ファイル・システムの MAXSOCKETS を十分高く設定します。
  2. MAXFILEPROC を十分高く設定します。
  ベスト・プラクティス: MAXSOCKETS および MAXFILEPROC は、低スループットの場合は少なくとも 5000、中スループットの場合は 10000、高スループットの WebSphere トランザクション環境の場合は 35000 に設定する必要があります。これらのパラメーターに高い値を設定すると、ソケットまたはファイルが実際に割り振られない限り、リソースを過度に使用することはありません。
  以下の例は、MAXSOCKETS パラメーターおよび MAXFILEPROC パラメーターの設定値を示しています。
```
/* Open/MVS Parmlib Member                                           */
/* CHANGE HISTORY:                                                   */
/*   01/31/02 AEK Increased MAXSOCKETS on AF_UNIX from 10000 to 50000*/
/*                per request from My Developer                      */
/*   10/02/01 JAB Set up shared HFS                                  */

/* KERNEL RESOURCES              DEFAULT             MIN MAX         */
/* ========================      =================== === =========== */
   .
   .
   MAXFILEPROC(65535)            /* 64               3   65535       */

   .
   .
    NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(30000)
   .
```
2. 次に、TCPIP プロファイル・データ・セット内のポートの指定を調べて、 NODELAYACKS が以下のように指定されていることを確認します。
```
PORT 8082 TCP NODELAYACKS
```
  これを変更すると、稼働時のスループットが最大 50% 改善されることがあります (特に、作業負荷が小さな処理を扱っている際には役に立ちます)。この設定は SSL を実行する際のパフォーマンスを良好にするために重要です。
3. 必ず DNS 構成を最適にし、頻繁に使用するサーバーおよびクライアントの検索をキャッシュする必要があります。
  
  キャッシングは、ネーム・サーバーの存続時間 (TTL) 値に関係することがあります。 TTL を高く設定すると、必ずキャッシュ・ヒットが良好になります。ただし、それを高く設定することは、デーモンがダウンすると、ネットワークの全利用者がそれを認識するのに時間がかかることも意味します。
  
  ご使用の DNS 構成が最適化されていることを確認する良い方法は、oping および onslookup USS コマンドを発行することです。妥当な時間で応答しているかを確認してください。多くの場合、DNS または DNS サーバー名が正しく構成されていないと、 10 秒以上の遅延の原因となります。
4. TCPIP 送受信バッファーのサイズをデフォルトの 16K から少なくとも 64K に増やします。これは、アプリケーションで送信するデータに存在するものを超える制御情報を含む、バッファーのサイズです。これを行うには、次のように指定します。
```
TCPCONFIG TCPSENDBFRSIZE 65535
          TCPRCVBUFRSIZE 65535
```
  トラブルの回避: 256 KB バッファーを指定することは、場合によっては不合理です。
5. デフォルトの listen バックログを増やします。
  デフォルトの listen バックログは、HTTP のようなプロトコルを用いた新しい接続のバッファー・スパイクに使用されます。デフォルトの listen バックログの要求は 10 です。 TCP トランスポート・チャネル listenBacklog カスタム・プロパティーを使用して、この値を増やす必要があります。例：
```
listenBacklog=100
```
  注: listenBacklog に使用する値は、TCP/IP プロファイル内の SOMAXCONN ステートメントの指定によって制限することができます。 SOMAXCONN 値より大きい listenBacklog 値を使用すると、listenBacklog 値は使用されず、SOMAXCONN 値が使用されます。
  重要: チャネル・タイプが HTTP、HTTP SSL、IIOP および IIOP SSL の場合に listenBacklog が設定されないと、listenBacklog には非推奨の環境値 (protocol_http_backlog、protocol_https_backlog、 protocol_iiop_backlog、および protocol_iiop_backlog_ssl) から設定されます。関連する非推奨の環境値が指定されていない場合、デフォルトの 10 が使用されます。
  
  チャネル・タイプが HTTP、 HTTP SSL、IIOP および IIOP SSL 以外の場合、listenBacklog のデフォルトは 511 です。
6. finwait2 時間を削減します。
  最も要求の多いベンチマークで、65K のソケットおよびファイル記述子を定義しても、100% 稼働させるのに十分な「空き」ソケットがないことがわかることがあります。ソケットが異常終了で閉じている場合 (例えば、もはや必要ない場合)、直ちには使用可能になりません。その代わり、finwait2 という状態に置かれます (これは netstat -s コマンドで示されるものです)。フリー・プールで使用可能になる前に、しばらくの間その状態で待機します。待機時間のデフォルト値は 600 秒です。
  
  トラブルの回避: ソケットの使用に問題がない限り、この設定はデフォルト値のままにしてください。
  z/OS® バージョン 1.2 以降を使用している場合、構成ファイルで以下を指定することにより、ソケットが finwait2 状態のままになっている時間を制御できます。
```
FINWAIT2TIME 60
```

結果

最適なバッファー・サイズが決まるまで、この処理を繰り返します。

次の作業

TCP/IP バッファー・サイズが変更されます。最適なバッファー・サイズが決まるまで、この処理を繰り返します。