クライアントとサーバとの間の通信で使用しているネットワークは,通常は性能上の問題を起こすことはありません。 しかし,注意すべき 2 つの状況があります。 ネットワーク遅延と,高い再送率です。 イーサネットが過度に使用されると,クライアントで要求送信のための空きスロットを待ち,大きな遅れが出る現象が発生します。 イーサネットで,使用率が 50 % を超えると,非常に大きなネットワーク遅延が発生しやすくなります。
ネットワーク・トポロジが大きな遅延を招くこともあります。 クライアントがよく使用するサーバに到達するまでにいくつものゲートウェイを経由する必要がある場合,クライアントからの要求は遅延することになります。 ネットワーク・トポロジを再構築して負荷を均等に分散させることで問題が解決することがあります。
この章では,Tru64 UNIX のネットワーク・サブシステムの性能を管理する方法について説明します。 以降の各節では,次のような内容を説明しています。
表 10-1
では,ネットワークの動作状況を収集するために使用できるコマンドを説明します。
表 10-1: ネットワークのモニタリング・ツール
ツール | 説明 | 参照先 |
ネットワークの統計情報と,プロトコルごとのアクティブなソケットのリスト,ネットワーク経路に関する情報,ネットワーク・インタフェースに関する累積統計情報 (受信および送信のパケット数,パケット衝突の回数など) を表示する。 また,ネットワーク動作に使用されるメモリに関する情報も表示する。 |
||
任意のサーバ・ソケットに対して保留された要求の最大数を報告する。 システム内の任意のサーバ・ソケットに対して保留された要求の最大数を表示できる。 |
||
ソケットのバックログの限界値を超えたために失われたバックログの数を報告する。
キューに入れられた,ソケットへの
|
||
|
||
ネットワーク上で特定のシステムに到達できるかどうかを調べる。 ICMP (Internet Control Message Protocol) のエコー要求をホストに送信し,ホストが稼働していて到達可能かどうか,また IP ルータに到達可能かどうかを調べる。 ルーティングに直接また間接的に関係する問題など,ネットワークに関する問題を切り分けるために使用する。 |
|
|
ネットワーク・インタフェース・パケットをモニタリングする。 リッスンするインタフェース,パケットの転送方向,表示するプロトコル・トラフィックのタイプを指定できる。
このコマンドを使用するには, |
2.4.4 項を参照 | |
ネットワーク・ホストへのパケット経路を表示し,ネットワーク・パケットがゲートウェイ間で転送される経路を追跡する。 |
|
10.1.1 sysconfig コマンドを用いてソケット・リッスン・キューの統計情報をチェックする
sysconfig -q socket
コマンドを用いて以下の属性の値を表示することにより,ソケット・リッスン・キューの限界値を大きくする必要があるかどうかを判断できます。
sobacklog_hiwat
-- システム内のすべてのサーバ・ソケットについて,保留される要求の最大数をモニタリングできます。
初期値は 0 です。
sobacklog_drops
-- キュー内にあるソケットへの
SYN_RCVD
接続の数がソケットのバックログ限界値と等しくなったために,受信した SYN パケットをシステムがドロップした回数をモニタリングできます。
初期値は 0 です。
somaxconn_drops
-- キュー内にあるソケットへの
SYN_RCVD
接続の数がバックログ長の上限 (somaxconn
属性) と等しくなったために,受信した SYN パケットをシステムがドロップした回数をモニタリングできます。
初期値は 0 です。
sominconn
属性の値と
somaxconn
属性の値を同じにすることをお勧めします。
その場合,somaxconn_drops
の値は
sobacklog_drops
の値と同じになります。
ただし,sominconn
属性の値が 0 (省略時) であり,1 つまたは複数のサーバ・アプリケーションが
listen
システム・コールへのバックログ引数として不適切な値を用いている場合,sobacklog_drops
の値は,somaxconn_drops
カウンタが増加する速さより速く増加することがあります。
このような場合は,sominconn
属性の値を増やしてください。
ソケット・リッスン・キューの限界値のチューニングについての詳細は,10.2.3 項
を参照してください。
10.2 ネットワーク・サブシステムのチューニング
ネットワーク・サブシステムが使用するリソースの多くは,動的に割り当てられて調整されます。 ただし,性能を改善するために使用できるチューニングのガイドラインもあります。 特に,システムが Web サーバ,プロキシ・サーバ,ファイアウォール,ゲートウェイ・サーバなどのインターネット・サーバである場合に適用できます。
ネットワークの性能は,リソース要求に対応できるだけのリソースが確保できない場合に影響を受けます。 そのような状況は,次の 2 通りの場合に発生します。
1 つまたは複数のハードウェアまたはソフトウェアのネットワーク構成要素に問題が発生した場合
作業負荷 (ネットワーク・トラフィック) が使用可能なリソースの許容量を定常的に超過しているが,すべて順調に動作しているように見える場合
この問題は,どちらもネットワークのチューニングの問題ではありません。 ネットワークに問題がある場合は,その問題を究明して解決しなければなりません。 ネットワーク・トラフィックが高い場合 (たとえば,システムが 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_hiwat
,sobacklog_drops
,somaxconn_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
サブシステム属性も構成できます。
tcp_keepidle
属性は,keepalive プローブを送信するまでのアイドル時間の長さを指定します (0.5 秒単位で指定)。
省略時の間隔は 2 時間です。
tcp_keepintvl
属性は,keepalive プローブを再送する時間間隔 (0.5 秒単位) を指定します。
省略時の間隔は 75 秒です。
tcp_keepcnt
属性は,接続を切るまでに送信する keepalive プローブの最大数を指定します。
省略時の値は 8 プローブです。
tcp_keepinit
属性は,初期接続がタイムアウトになるまでの最大時間を 0.5 秒単位で指定します。
省略時の値は 75 秒です。
アプリケーションでは,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 に増やします。