10    ネットワーク性能の管理

クライアントとサーバとの間の通信で使用しているネットワークは,通常は性能上の問題を起こすことはありません。 しかし,注意すべき 2 つの状況があります。 ネットワーク遅延と,高い再送率です。 イーサネットが過度に使用されると,クライアントで要求送信のための空きスロットを待ち,大きな遅れが出る現象が発生します。 イーサネットで,使用率が 50 % を超えると,非常に大きなネットワーク遅延が発生しやすくなります。

ネットワーク・トポロジが大きな遅延を招くこともあります。 クライアントがよく使用するサーバに到達するまでにいくつものゲートウェイを経由する必要がある場合,クライアントからの要求は遅延することになります。 ネットワーク・トポロジを再構築して負荷を均等に分散させることで問題が解決することがあります。

この章では,Tru64 UNIX のネットワーク・サブシステムの性能を管理する方法について説明します。 以降の各節では,次のような内容を説明しています。

10.1    ネットワーク情報の収集

表 10-1 では,ネットワークの動作状況を収集するために使用できるコマンドを説明します。

表 10-1:  ネットワークのモニタリング・ツール

ツール 説明 参照先

netstat

ネットワークの統計情報と,プロトコルごとのアクティブなソケットのリスト,ネットワーク経路に関する情報,ネットワーク・インタフェースに関する累積統計情報 (受信および送信のパケット数,パケット衝突の回数など) を表示する。 また,ネットワーク動作に使用されるメモリに関する情報も表示する。

2.4.5 項

sobacklog_hiwat 属性

任意のサーバ・ソケットに対して保留された要求の最大数を報告する。 システム内の任意のサーバ・ソケットに対して保留された要求の最大数を表示できる。

10.1.1 項

sobacklog_drops 属性

ソケットのバックログの限界値を超えたために失われたバックログの数を報告する。 キューに入れられた,ソケットへの SYN_RCVD 接続の数がソケットのバックログ限界値と等しくなったために,受信した SYN パケットをシステムがドロップした回数を表示できる。

10.1.1 項

somaxconn_drops 属性

somaxconn 属性の値を超えたドロップの数を報告する。 キューに入れられた,ソケットへの SYN_RCVD 接続の数がバックログ長の上限 (somaxconn 属性) と等しくなったために,受信した SYN パケットをシステムがドロップした回数を表示できる。

10.1.1 項

ping

ネットワーク上で特定のシステムに到達できるかどうかを調べる。 ICMP (Internet Control Message Protocol) のエコー要求をホストに送信し,ホストが稼働していて到達可能かどうか,また IP ルータに到達可能かどうかを調べる。 ルーティングに直接また間接的に関係する問題など,ネットワークに関する問題を切り分けるために使用する。

ping(8) を参照

tcpdump

ネットワーク・インタフェース・パケットをモニタリングする。 リッスンするインタフェース,パケットの転送方向,表示するプロトコル・トラフィックのタイプを指定できる。

tcpdump コマンドでは,特定のネットワーク・サービスに対応するネットワーク・トラフィックをモニタリングしたり,パケットのソースを確認したりすることができる。 また,要求が受信または肯定応答されたかどうかを調べたり,あるいはネットワークの性能が低速である場合にネットワーク要求のソースを調べたりすることができる。

このコマンドを使用するには,packetfilter オプションを用いてカーネルを構成しておかなければならない。

2.4.4 項を参照

traceroute

ネットワーク・ホストへのパケット経路を表示し,ネットワーク・パケットがゲートウェイ間で転送される経路を追跡する。

traceroute(8) を参照

10.1.1    sysconfig コマンドを用いてソケット・リッスン・キューの統計情報をチェックする

sysconfig -q socket コマンドを用いて以下の属性の値を表示することにより,ソケット・リッスン・キューの限界値を大きくする必要があるかどうかを判断できます。

sominconn 属性の値と somaxconn 属性の値を同じにすることをお勧めします。 その場合,somaxconn_drops の値は sobacklog_drops の値と同じになります。

ただし,sominconn 属性の値が 0 (省略時) であり,1 つまたは複数のサーバ・アプリケーションが listen システム・コールへのバックログ引数として不適切な値を用いている場合,sobacklog_drops の値は,somaxconn_drops カウンタが増加する速さより速く増加することがあります。 このような場合は,sominconn 属性の値を増やしてください。

ソケット・リッスン・キューの限界値のチューニングについての詳細は,10.2.3 項 を参照してください。

10.2    ネットワーク・サブシステムのチューニング

ネットワーク・サブシステムが使用するリソースの多くは,動的に割り当てられて調整されます。 ただし,性能を改善するために使用できるチューニングのガイドラインもあります。 特に,システムが Web サーバ,プロキシ・サーバ,ファイアウォール,ゲートウェイ・サーバなどのインターネット・サーバである場合に適用できます。

ネットワークの性能は,リソース要求に対応できるだけのリソースが確保できない場合に影響を受けます。 そのような状況は,次の 2 通りの場合に発生します。

この問題は,どちらもネットワークのチューニングの問題ではありません。 ネットワークに問題がある場合は,その問題を究明して解決しなければなりません。 ネットワーク・トラフィックが高い場合 (たとえば,システムが 100% ビジーのときに,Web サーバのヒット・レートが最大値に達している場合),ネットワークの設計を変更して負荷をさらに分散させるか,ネットワーク・クライアントの数を減らすか,ネットワークの負荷を処理するシステムの数を増やさなければなりません。

ネットワークの問題を解決する方法についての詳細は,『ネットワーク・プログラミング・ガイド』 および 『ネットワーク管理ガイド:接続編』 を参照してください。

表 10-2 に,ネットワーク・サブシステムのチューニングのガイドラインと,性能上の利点と欠点を示します。

表 10-2:  ネットワークのチューニング・ガイドライン

ガイドライン 性能上の利点 欠点
TCP 制御ブロックを検索するためにカーネルが使用するハッシュ・テーブルのサイズを増やす (10.2.1 項)。 TCP 制御ブロックの検索速度が速くなり,接続速度が向上する。 固定メモリの量が少し増加する。
TCP ハッシュ・テーブルの数を増やす (10.2.2 項)。 SMP システムでのハッシュ・テーブルのロック争奪が減少する。 固定メモリの量が少し増加する。
ソケット・リッスン・キューでのパーシャル TCP 接続の限界値を大きくする (10.2.3 項)。 大量の接続を処理するシステムで,スループットと応答速度が向上する。 保留された接続がキュー内にとどまった場合に,メモリを消費する。
送信接続ポートの数を増やす (10.2.4 項)。 同時に作成できる送信接続の数が増える。 なし
送信接続ポートの範囲を変更する (10.2.5 項)。 特定の範囲のポートが使用できるようになる。 なし
PMTU 検出を無効にする (10.2.6 項)。 多数のクライアントからのリモート・トラフィックを処理するサーバの効率が改善される。 LAN トラフィックに対するサーバの効率が低下することがある。
IP 入力キューの数を増やす (10.2.7 項)。 SMP システムでの IP 入力キューのロック争奪が減少する。 なし
mbuf クラスタの圧縮を有効にする (10.2.8 項)。 ネットワークのメモリ割り当て効率が改善される。 なし
TCP の keepalive 機能を有効にする (10.2.9 項)。 アクティブでないソケット接続をタイムアウトにできる。 なし
カーネル・インタフェース別名テーブルのサイズを大きくする (10.2.10 項)。 多数のドメイン名のサービスを行うシステムでの IP アドレス検索速度が向上する。 固定メモリの量が少し増加する。
パーシャル TCP 接続のタイムアウトを速くする (10.2.11 項)。 クライアントがソケット・リッスン・キューを満杯にすることがなくなる。 時間制限が短くなるため,成立する可能性があった接続が早期に切断されることがある。
接続の最後で,TCP 接続コンテキストのタイムアウトを速くする (10.2.12 項)。 接続リソースが早く解放される。 タイムアウト限界値を小さくすると,データが破損する可能性が高くなる。 このガイドラインを適用する際は注意が必要。
TCP 再送レートを下げる (10.2.13 項)。 早期の再送がなくなり,混雑が減少する。 長い再送時間がすべての状況に適しているとは限らない。
TCP データの即時肯定応答を有効にする (10.2.14 項)。 一部の接続でネットワークの性能が向上する。 ネットワークの帯域幅に悪影響を及ぼすことがある。
TCP セグメントの最大サイズを大きくする (10.2.15 項)。 1 つのパケットで送信できるデータの量が増える。 ルータの境界で断片化が発生することがある。
送信および受信ソケット・バッファのサイズを大きくする (10.2.3 項)。 1 つのソケットにバッファリングされる TCP パケットが増える。 バッファ領域が使用されている場合に,使用可能なメモリが減少することがある。
UDP ソケットの送信および受信バッファのサイズを大きくする (10.2.16 項)。 UDP パケットのドロップ防止に効果がある。 バッファ領域が使用されている場合に,使用可能なメモリが減少することがある。
UBC に十分なメモリを割り当てる (11.1.3 項)。 ディスクの入出力性能が向上する。 プロセスが使用できる物理メモリが減少することがある。
ソケット・バッファの最大サイズを大きくする (10.2.17 項)。 ソケット・バッファのサイズを大きくできる。 メモリ・リソースを消費する。
入力パケットのドロップを防止する (10.2.18 項)。 高いネットワーク負荷に対応できる。 なし

以降の項では,上記チューニングのガイドラインについて詳しく説明します。

カーネル・サブシステム属性を変更する方法は,第 3 章を参照してください。

10.2.1    TCP 制御ブロックの検索速度を速くする

カーネルが伝送制御プロトコル (TCP) の制御ブロックを検索するために使用する,ハッシュ・テーブルのサイズを変更できます。 inet サブシステムの tcbhashsize 属性は,カーネルの TCP 接続テーブル内のハッシュ・バケットの数 (inpcb ハッシュ・テーブル内のバケット数) を指定します。

性能上の利点と欠点

カーネルは,受信するすべての TCP パケットについて接続ブロックを検索しなければならないため,テーブルのサイズを大きくすると検索速度が上がり,性能が改善されます。 これにより,固定メモリの量が少し増加します。

tcbhashsize 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

インターネット・サーバがある場合は,カーネルの TCP 接続テーブル内のハッシュ・バケットの数を増やします。

推奨値

tcbhashsize 属性の省略時の値は 512 です。 インターネット・サーバの場合は,tcbhashsize 属性の値を 16384 にしてください。

10.2.2    TCP ハッシュ・テーブルの数を増やす

カーネルは,受信するすべての伝送制御プロトコル (TCP) パケットについて接続ブロックを検索しなければならないため,SMP システムの TCP ハッシュ・テーブルがボトルネックになるおそれがあります。 テーブルの数を増やすと負荷が分散されるため,性能を改善できます。 inet サブシステムの tcbhashnum 属性は,TCP ハッシュ・テーブルの数を指定します。

性能上の利点と欠点

SMP システムでは,カーネルが TCP 制御ブロックの検索に使用するハッシュ・テーブルの数を増やすと,ハッシュ・テーブルのロック争奪を削減できます。 これにより,固定メモリの量が少し増加します。

tcbhashnum 属性を変更したときには,システムのリブートが必要です。

チューニングするかどうかの判断

SMP システムのインターネット・サーバの場合は,TCP ハッシュ・テーブルの数を増やします。

推奨値

tcbhashnum 属性の最小値および省略時の値は 1 です。 最大値は 64 です。 負荷の高いインターネット・サーバの SMP システムでは,tcbhashnum 属性の値を 16 に増やします。 この属性の値を大きくする場合は,ハッシュ・テーブルのサイズも大きくしてください。 詳細は 10.2.1 項 を参照してください。

tcbhashnum 属性の値を inet サブシステムの ipqs 属性と等しくすることをお勧めします。 詳細は 10.2.7 項 を参照してください。

10.2.3    TCP ソケット・リッスン・キューの限界値をチューニングする

ソケット・リッスン・キューの限界値を大きくすることで,性能が改善できることがあります (TCP の場合のみ)。 socket サブシステムの somaxconn 属性は,各サーバ・ソケットに対して保留される TCP 接続の最大数 (ソケット・リッスン・キューの限界値) を指定します。 リッスン・キューの接続限界値が小さ過ぎると,受信接続要求が失われることがあります。 TCP 接続の保留は,インターネットでのパケット紛失や,サービス・アタックの拒否によって生じることがあるので注意してください。

socket サブシステムの sominconn 属性は,各サーバ・ソケットに対して保留される TCP 接続 (バックログ) 数の最小値を指定します。 この属性は,新たな要求を破棄しないで,同時に処理できる SYN パケットの数を制御します。 sominconn 属性の値は,アプリケーションに固有のバックログの値より優先されます。 アプリケーションに固有のバックログの値は,一部のサーバ・ソフトウェアに対しては小さすぎることがあります。

性能上の利点と欠点

ドロップを少なくして,スループットと応答速度を改善するには,somaxconn 属性の値を増やします。

アプリケーションを再コンパイルすることなく性能を改善したい場合,またはインターネット・サーバの場合は,sominconn 属性の値を大きくします。 この属性の値を大きくすると,エラーの TCP SYN パケットでクライアントのソケット・リッスン・キューが満杯になるのを防止できます。

somaxconn および sominconn 属性の値は,システムをリブートすることなく変更できます。 ただし,すでにオープンしているソケットでは,アプリケーションを再起動するまで,以前のソケット限界値が使用されます。

チューニングするかどうかの判断

インターネット・サーバを使用している場合や,負荷の高いシステムで保留される接続が多く,また大量の接続を生成するアプリケーションを実行している場合は,ソケット・リッスン・キューの限界値を大きくします。

sobacklog_hiwatsobacklog_dropssomaxconn_drops 属性をモニタリングして,ソケット・キューがオーバフローしていないか調べます。 オーバフローしている場合は,ソケット・リッスン・キューの限界値を大きくする必要があります。 詳細は,10.1.1 項 を参照してください。

推奨値

somaxconn 属性の省略時の値は 1024 です。 インターネット・サーバの場合は,somaxconn 属性の値を最大値の 65535 にします。

sominconn 属性の省略時の値は 0 です。 アプリケーションを再コンパイルすることなく性能を改善したい場合や,インターネット・サーバの場合は,sominconn 属性の値を最大値の 65535 にします。

クライアントのソケット・リッスン・キューがエラーの TCP SYN パケットで満杯になっている場合は,他のユーザを効率的にキューからブロックして,sominconn 属性の値を 65535 に増やします。 システムで受信 SYN パケットのドロップが続く場合は,inet サブシステムの tcp_keepinit 属性を 30 (15 秒) に減らします。

sominconn 属性の値は somaxconn 属性の値と同じにしてください。

10.2.4    送信接続ポート数を増やす

TCP または UDP アプリケーションが送信接続を作成する場合,カーネルは予約されていないポート番号を各接続に動的に割り当てます。 カーネルは,inet サブシステムの ipport_userreserved_min 属性の値から ipport_userreserved 属性の値までの範囲からポート番号を選択します。 省略時の属性値を使用する場合,同時に接続できる送信接続の数は 3976 に制限されます。

性能上の利点

ポートの数を増やすと,TCP および UDP アプリケーションに対するポート数が増えます。

ipport_userreserved 属性の値は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

システムに多数の送信ポートが必要な場合は,ipport_userreserved 属性の値を大きくします。

推奨値

ipport_userreserved 属性の省略時の値は 5000 です。 この場合,省略時のポート数は 3976 (5000 から 1024 を引いた値) になります。

システムがプロキシ・サーバ (Squid キャッシュ・サーバやファイアウォール・システムなど) で,同時接続が 4000 を超える場合は,ipport_userreserved 属性の値を最大値の 65000 まで増やします。

ipport_userreserved 属性の値を 5000 未満に減らしたり,65000 より大きい値に増やさないでください。

また,送信接続ポートの範囲を変更することもできます。 詳細は 10.2.5 項 を参照してください。

10.2.5    送信接続ポートの範囲を変更する

TCP または UDP アプリケーションが送信接続を作成する場合,カーネルは予約されていないポート番号を各接続に動的に割り当てます。 カーネルは,inet サブシステムの ipport_userreserved_min 属性の値から ipport_userreserved 属性の値までの範囲からポート番号を選択します。 これらの属性の省略時の値を使用した場合,送信ポートの範囲は 1024 〜 5000 になります。

性能上の利点と欠点

送信接続の範囲を変更すると,TCP および UDP アプリケーションには指定した範囲のポートが割り当てられます。

ipport_userreserved_min および ipport_userreserved 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

特定の範囲の送信ポートを使用したい場合は,ipport_userreserved_min 属性および ipport_userreserved 属性の値を変更します。

推奨値

ipport_userreserved_min 属性の省略時の値は 1024 です。 ipport_userreserved の省略時の値は 5000 です。 属性の最大値は,どちらも 65000 です。

ipport_userreserved 属性の値は 5000 未満にしないでください。 また,ipport_userreserved_min 属性の値は 1024 未満にしないでください。

10.2.6    PMTU の検出を無効にする

サーバ間で伝送されるパケットは,ルータやパケット・サイズの小さいネットワーク (イーサネット・ネットワークなど) を介して伝送しやすくするために,特定のサイズのユニットに分割されます。 inet サブシステムの pmtu_enabled 属性が有効 (1 に設定。 省略時の動作) の場合,システムはサーバ間の PMTU (Path Maximum Transmission Unit) 値の共通の最大値を調べ,それをユニットのサイズとして使用します。 また,システムは,サーバに接続しようとしたクライアント・ネットワークごとにルーティング・テーブルのエントリを作成します。

性能上の利点と欠点

サーバが多数のリモート・クライアント間のトラフィックを処理する場合,PMTU 検出を無効にしておくと,カーネルのルーティング・テーブルのサイズが小さくなり,サーバの効率が良くなります。 ただし,ローカル・トラフィックとリモート・トラフィックを処理するサーバでは,PMTU 検出を無効にすると帯域幅が低下することがあります。

pmtu_enabled 属性の値は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

パスを分断する FDDI ツー・イーサネットのブリッジがあるような場合は,PMTU 検出を使用すると,あるサイズよりも大きなパケットが見えなくなり,データ転送ができなくなることがあります。 このような場合は,PMTU 検出を無効にします。 また,多数のリモート・クライアント間のトラフィックを処理するサーバがある場合や,性能の低いインターネット・サーバを使用していて,ルーティング・テーブルのエントリ数が 1000 を超えている場合にも,PMTU 検出を無効にしてください。

10.2.7    IP 入力キューの数を増やす

inet サブシステムの ipqs 属性は,IP 入力キューの数を指定します。

性能上の利点と欠点

IP 入力キューの数を増やすと,負荷が分散されるため,キューのロック争奪が減少します。

ipqs 属性を変更したときには,システムのリブートが必要です。

チューニングするかどうかの判断

インターネット・サーバとして使用している SMP システムでは,IP 入力キューの数を増やします。

推奨値

インターネット・サーバとして使用している SMP システムでは,ipqs 属性の値を 16 に増やします。 最大値は 64 です。

ipqs 属性の値は,inet サブシステムの tcbhashnum 属性の値と同じにすることをお勧めします。 詳細は,10.2.2 項を参照してください。

10.2.8    mbuf クラスタの圧縮を有効にする

socket サブシステムの sbcompress_threshold 属性は,mbuf クラスタがソケット・レイヤで圧縮されるかどうかを制御します。 特に指定しなければ,mbuf クラスタは圧縮されません (sbcompress_threshold の設定が 0)。

性能上の利点

mbuf クラスタを圧縮すると,使用可能な mbuf クラスタをプロキシ・サーバが使い果たしてしまうのを防止できます。

sbcompress_threshold 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

プロキシ・サーバを使用している場合は,mbuf クラスタの圧縮を有効にします。 プロキシ・サーバのシステムでは,イーサネットの代わりに FDDI を使用している場合に,使用可能な mbuf クラスタを使い果たしてしまうことがよくあります。

mbuf クラスタとして使用しているメモリを調べるには,netstat -m コマンドを実行します。 次の例は,128 MB のメモリを備え,mbuf クラスタの圧縮を有効にしていないファイアウォール・サーバの例です。

# netstat -m
  2521 Kbytes for small data mbufs (peak usage 9462 Kbytes)
 78262 Kbytes for mbuf clusters (peak usage 97924 Kbytes)
  8730 Kbytes for sockets (peak usage 14120 Kbytes)
  9202 Kbytes for protocol control blocks (peak usage 14551
     2 Kbytes for routing table (peak usage 2 Kbytes)
     2 Kbytes for socket names (peak usage 4 Kbytes)
     4 Kbytes for packet headers (peak usage 32 Kbytes)
 39773 requests for mbufs denied
     0 calls to protocol drain routines
 98727 Kbytes allocated to network

上記の例では,39773 個のメモリ要求が拒否されたことを示しています。 この値は 0 でなければならないので,これは問題があることを示しています。 また,この例では,78 MB のメモリが mbuf クラスタに割り当てられ,98 MB のメモリがネットワーク・サブシステムによって消費されていることもわかります。

推奨値

mbuf クラスタの圧縮を有効にするには,socket サブシステムの sbcompress_threshold 属性の省略時の値を変更します。 パケット・サイズがこの値より小さい場合,パケットは既存の mbuf クラスタにコピーされます。 プロキシ・サーバの場合は,この属性に 600 を指定します。

sbcompress_threshold 属性の値を大きくして 600 にすると,ネットワーク・サブシステムに割り当てられているメモリはただちに 18 MB まで減少します。 これは,カーネル・ソケット・バッファのインタフェースで圧縮が行われ,メモリの使用効率が改善されるためです。

10.2.9    TCP の keepalive 機能を有効にする

keepalive 機能を有効にすると,接続をアクティブの状態に保つために,接続されたソケット上でメッセージが定期的に伝送されます。 正常に終了していないソケットは,keepalive の時間間隔が経過した時点で消去されます。 keepalive を有効にしていない場合,このようなソケットはシステムをリブートするまで消えません。

アプリケーションでは,setsockopt 関数の SO_KEEPALIVE オプションを設定することで,ソケットの keepalive 機能を有効にします。 自分で keepalive を設定しないプログラムについて指定を変更する場合,またはアプリケーションのソースにアクセスできない場合は,inet サブシステムの tcp_keepalive_default 属性を用いて keepalive 機能を有効にします。

性能上の利点

keepalive 機能は,keepalive の時間間隔が経過した時点で,正常に終了していないソケットを消去します。

tcp_keepalive_default 属性は,システムをリブートすることなく変更できます。 ただし,すでに存在しているソケットは,アプリケーションを再起動するまで以前の動作を続けます。

チューニングするかどうかの判断

keepalive 機能が必要で,ソース・コードにアクセスできない場合に keepalive を有効にします。

推奨値

自分で keepalive を設定しないプログラムについて指定を変更する場合,またはアプリケーションのソース・コードにアクセスできない場合は,inet サブシステムの tcp_keepalive_default 属性に 1 を設定して,すべてのソケットの keepalive を有効にします。

keepalive を有効にしている場合は,ソケットに対して次の inet サブシステム属性も構成できます。

アプリケーションでは,setsockopt() コールを用いて,ソケットごとに属性の値を変更できます。

10.2.10    IP アドレスの検索速度を速くする

inet サブシステムの inifaddr_hsize 属性は,カーネル・インタフェース別名テーブル (in_ifaddr) 内のハッシュ・バケット数を指定します。

システムが多数のサーバ・ドメイン名に対するサーバとして使用され,ドメイン名がそれぞれ一意の IP アドレスにバインドされている場合,受信したパケットを正しいサーバ・アドレスと照合する処理では,ハッシュ・テーブルを使用して IP アドレスの検索処理を高速化しています。

性能上の利点と欠点

テーブル内のハッシュ・バケットの数を増やすと,大量の別名を使用するシステムの性能を改善できます。

inifaddr_hsize 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

大量の別名を使用しているシステムでは,カーネル・インタフェース別名テーブル内のハッシュ・バケット数を増やします。

推奨値

inet サブシステムの inifaddr_hsize 属性の省略時の値は 32 です。 また,最大値は 512 です。

最良の性能を得るために,inifaddr_hsize 属性の値は,最も近い 2 の累乗に切り下げられます。 インタフェース IP の別名を 500 個以上使用している場合は,最大値の 512 にします。 別名が250 個より少ない場合は,省略時の 32 を使用します。

10.2.11    TCP のパーシャル接続タイムアウトの限界値を小さくする

inet サブシステムの tcp_keepinit 属性は,部分的に確立された TCP 接続がタイムアウトになるまでにソケット・リッスン・キューにとどまる時間を指定します。 パーシャル接続では,リッスン・キューのスロットが消費され,SYN_RCVD 状態の接続がキューに入れられます。

性能上の利点と欠点

tcp_keepinit 属性の値を小さくすると,パーシャル接続が早くタイムアウトになります。

tcp_keepinit 属性の値は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

somaxconn_drops 属性の値が頻繁に増加しない限り,TCP パーシャル接続のタイムアウト限界値を変更する必要はありません。 頻繁に増加する場合は,tcp_keepinit 属性の値を小さくします。

推奨値

tcp_keepinit 属性の値は 0.5 秒単位で指定します。 省略時の値は 150 単位 (75 秒) です。 sominconn 属性の値が 65535 の場合,tcp_keepinit 属性には省略時の値を使用してください。

tcp_keepinit 属性に設定する値が小さすぎないようにしてください。 この値が小さすぎると,低速のネットワーク・パスや多数のパケットが失われるネットワーク・パスで,クライアントとの接続が早期に切断されてしまうおそれがあります。 20 単位 (10 秒) 未満の値は設定しないようにしてください。

10.2.12    TCP 接続コンテキストのタイムアウト限界値を小さくする

TCP プロトコルには,MSL (Maximum Segment Lifetime) という概念があります。 TCP 接続は,TIME_WAIT 状態になったときには,MSL の値の 2 倍だけこの状態にとどまらなければなりません。 そうしないと,その後の接続でデータ未検出のエラーが発生する可能性があります。 inet サブシステムの tcp_msl 属性によって,TCP セグメントの最大存在期間と TIME_WAIT 状態のタイムアウト値が決まります。

性能上の利点と欠点

tcp_msl 属性の値を小さくすると,接続の終わりで TCP 接続コンテキストのタイムアウトが早くなります。 ただし,これによりデータが破損する可能性が高くなります。

tcp_msl 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

通常は,TCP 接続コンテキストのタイムアウト限界値を変更する必要はありません。

推奨値

tcp_msl 属性の値は,0.5 秒単位で設定します。 省略時の値は 60 単位 (30 秒) です。 これは,TCP 接続が 60 秒間 (MSL の値の 2 倍) だけ TIME_WAIT 状態にとどまるということです。 状況によっては,TIME_WAIT 状態のタイムアウト値として,省略時の値 (60 秒) では長すぎるため,tcp_msl 属性の値を小さくして,接続リソースが省略時よりも早く解放されるようにすることがあります。

ネットワークの設計および動作と TCP プロトコルについて完全に理解するまでは,tcp_msl 属性の値を小さくしないでください。 省略時の値を使用することをお勧めします。 それ以外の値を使用すると,データが破損するおそれがあります。

10.2.13    TCP 再送レートを下げる

inet サブシステムの tcp_rexmit_interval_min 属性は,最初の TCP 再送を行う前に待つ時間の最小値です。

性能上の利点と欠点

tcp_rexmit_interval_min 属性の値を大きくすると,TCP 再送レートは低くなり,混雑が減って性能が改善されます。

tcp_rexmit_interval_min 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

すべての接続で再送時間を長くする必要はありません。 通常,省略時の値で十分です。 ただし,広域ネットワーク (WAN) の中には,省略時の再送間隔では短すぎて,再送のタイムアウトが早く発生しすぎることがあります。 これにより,パケットの伝送が重複したり,TCP の混雑制御アルゴリズムが誤って起動されるおそれがあります。

再送をチェックするには,netstat -p tcp コマンドを用いて data packets retransmitted という出力を調べます。 netstat コマンドの詳細は,2.4.5 項を参照してください。

推奨値

tcp_rexmit_interval_min 属性は,0.5 秒単位で指定します。 省略時の値は 2 単位 (1 秒) です。

1 単位より小さい値は指定しないでください。 TCP アルゴリズムを完全に理解するまでは,この属性を変更しないでください。

10.2.14    TCP データの肯定応答の遅延を無効にする

特に指定しない限り,システムは TCP データの肯定応答を遅延させます。 inet サブシステムの tcpnodelack 属性によって,システムが TCP データの肯定応答を遅延させるかどうかが決まります。

性能上の利点と欠点

TCP データの遅延を無効にすると,性能が改善されることがあります。 ただし,ネットワークの帯域幅に悪影響を及ぼすことがあります。

tcpnodelack 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

通常,tcpnodelack 属性の省略時の値で十分です。 ただし,接続によっては (ループバックなど),この遅延により性能が低下することもあります。 tcpdump コマンドを用いて,遅れが大きすぎないかチェックしてください。

推奨値

tcpnodelack の省略時の値は 0 です。 TCP 肯定応答の遅延を無効にするには,tcpnodelack 属性の値を 1 にしてください。

10.2.15    TCP セグメントの最大サイズを大きくする

inet サブシステムの tcp_mssdflt 属性は,TCP セグメントの最大サイズを指定します。

性能上の利点と欠点

TCP セグメントの最大サイズを大きくすると,1 つのソケットで送信できるデータの量が増えますが,ルータの境界で断片化が発生することがあります。

tcp_mssdflt 属性は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

通常は,TCP セグメントの最大サイズを変更する必要はありません。

推奨値

tcp_mssdflt 属性の省略時の値は 536 です。 この値は 1460 まで大きくすることができます。

10.2.16    UDP ソケットの送受信バッファを大きくする

inet サブシステムの udp_sendspace 属性は,Internet UDP (User Datagram Protocol) ソケットの省略時の送信バッファ・サイズを指定します。 inet サブシステムの udp_recvspace 属性は,UDP ソケットの省略時の受信バッファ・サイズを指定します。

性能上の利点と欠点

UDP 送信および受信ソケット・バッファを大きくすると,1 つのソケットにバッファリングできる UDP パケットの数が多くなります。 ただし,値を大きくすると,アプリケーションがバッファを使用する (データの送受信) 際に使用されるメモリも多くなります。

注意

UDP 属性は,ネットワーク・ファイル・システム (NFS) の性能には影響しません。

udp_sendspace および udp_recvspace 属性は,システムをリブートすることなく変更できます。 ただし,新しい UDP ソケット・バッファの値を使用するには,アプリケーションを再起動しなければなりません。

チューニングするかどうかの判断

netstat -p udp コマンドを使用して,ソケット・フルをチェックします。 出力に full sockets がたくさん表示される場合は,udp_recvspace 属性の値を大きくしてください。

推奨値

udp_sendspace の省略時の値は 9 KB (9216 バイト) です。 udp_recvspace の省略時の値は 40 KB (42240 バイト) です。 これらの属性の値は,64 KB まで大きくすることができます。

10.2.17    ソケット・バッファの最大サイズを大きくする

socket サブシステムの sb_max 属性は,ソケット・バッファの最大サイズを指定します。

性能上の利点と欠点

ソケット・バッファの最大サイズを大きくすると,バッファ・サイズを大きくして効果のあるアプリケーションの場合は,性能が改善できることがあります。

sb_max 属性の値は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

大きなソケット・バッファが必要な場合は,ソケット・バッファ・サイズの最大値を大きくします。

推奨値

sb_max 属性の省略時の値は 128 KB です。 送信および受信ソケット・バッファのサイズを大きくする前に,この値を大きくしてください。

10.2.18    入力パケットのドロップを防止する

ネットワークの負荷が高いために IP の入力キューがオーバフローすると,入力パケットがドロップします。

inet サブシステムの ipqmaxlen 属性は,入力パケットがドロップすることなく使用できる IP 入力キュー (ipintrq) の最大長 (バイト) を指定します。 ifqmaxlen 属性は,パケットがドロップすることなくネットワーク・アダプタのキューに入れることができる出力パケットの数を指定します。

性能上の利点と欠点

IP 入力キューを大きくすると,パケットのドロップを防止できます。

ipqmaxlen および ifqmaxlen 属性の値は,システムをリブートすることなく変更できます。

チューニングするかどうかの判断

システムでパケットのドロップが発生している場合は,ipqmaxlen および ifqmaxlen 属性の値を大きくします。 入力パケットのドロップをチェックするには,dbx を用いて ipintrq カーネル構造体を調べます。 ifq_drops フィールドが 0 でない場合は,入力パケットのドロップが発生しています。 次に例を示します。

# dbx -k /vmunix 
(dbx)print ipintrq
struct {
    ifq_head = (nil)
    ifq_tail = (nil)
    ifq_len = 0
    ifq_maxlen = 512
    ifq_drops = 128
 .
 .
 .

netstat -id コマンドを用いて,出力パケットのドロップをモニタリングします。 出力の中で,インタフェースの Drop 欄にゼロ以外の値がないか調べます。 次の例は,ネットワーク・インタフェースの tu1 で 579 個の出力パケットがドロップしていることを示しています。

# netstat -id
 
Name  Mtu   Network  Address              Ipkts Ierrs    Opkts Oerrs  Coll Drop
 
fta0  4352  link     08:00:2b:b1:26:59    41586     0    39450     0     0   0
fta0  4352  DLI      none                 41586     0    39450     0     0   0
fta0  4352  10       fratbert             41586     0    39450     0     0   0
tu1   1500  link     00:00:f8:23:11:c8  2135983     0   163454    13  3376 579
tu1   1500  DLI      none               2135983     0   163454    13  3376 579
tu1   1500  red-net  ratbert            2135983     0   163454    13  3376 579
 .
 .
 .

さらに,netstat -p ip を使用して,lost packets due to resource problems フィールドまたは no memory or interface queue was full フィールドにゼロ以外の値がないか調べます。 次に例を示します。

# netstat -p ip
ip:                                        
        259201001 total packets received
        0 bad header checksums
        0 with size smaller than minimum
        0 with data size < data length
        0 with header length < data size
        0 with data length < header length
        25794050 fragments received
        0 fragments dropped (duplicate or out of space)
        802 fragments dropped after timeout
        0 packets forwarded
        67381376 packets not forwardable
                67381376 link-level broadcasts
        0 packets denied access
        0 redirects sent
        0 packets with unknown or unsupported protocol
        170988694 packets consumed here
        160039654 total packets generated here
        0 lost packets due to resource problems
        4964271 total packets reassembled ok
        2678389 output packets fragmented ok
        14229303 output fragments created
        0 packets with special flags set

推奨値

ipqmaxlen および ifqmaxlen 属性の省略時の値および最小値は 1024 です。 最大値は 65535 です。 多くの構成では,省略時の値で十分です。 パケットのドロップが発生している場合に限り,値を増やしてください。

システムでパケットのドロップが発生している場合は,ipqmaxlen および ifqmaxlen 属性の値を,パケットがドロップしなくなるまで増やします。 たとえば,省略時の値から 2000 に増やします。