この章では,Tru64 UNIX をチューニングしてインターネット・サーバの性能を改善する方法を説明します。 以下の項目で,各種の構成ガイドラインを示し,モニタリング・ツールをいくつか説明して,基本的な推奨チューニングと高度な推奨チューニングを示します。
すべての推奨チューニングがすべての構成に適用できるわけではありません。 また,わずかな性能改善しか得られない場合もあります。 したがって,これらの推奨チューニングを適用する前に,現在の構成と処理量を完全に把握し,本書を注意深く読む必要があります。
注意
Tru64 UNIX バージョン 5.0 以上で変更された属性名があります。
この節では,インターネット・サーバの性能を改善する方法を説明します。 ここでは,以下のトピックに着目して,各種の構成ガイドラインを示し,いくつかのモニタリング・ツールについて説明します。
ハードウェアの構成 (6.1.1 項)
メモリとスワップ領域の構成 (6.1.2 項)
IP アドレスのロギング (6.1.3 項)
ネットワーク統計情報のモニタリング (6.1.4 項)
ソケット統計情報のモニタリング (6.1.5 項)
仮想メモリ統計情報のモニタリング (6.1.6 項)
構成情報の収集 (6.1.7 項)
インターネット・サーバの性能を改善するには,ハードウェア構成に関する以下のガイドラインが役立ちます。
システム,ディスク,アダプタ,およびコントローラのファームウェアのバージョンが最新であることを確認してください。
処理量をこなせるだけのメモリ容量とスワップ領域を備えていることを確認してください。 詳細は,6.1.2 項を参照してください。
インターネット・サーバの構成では,ディスク,アダプタ,およびコントローラなどに,高性能なストレージ・ハードウェアを使用してください。
高性能と高可用性を実現するために,LSM (Logical Storage Manager) またはハードウェア RAID ストレージ構成を使用してください。
ハードウェア RAID 構成でライトバック・キャッシュを使用すると,インターネット・サーバの性能が著しく改善されます。
/tmp
ディレクトリと
/var/tmp
ディレクトリは異なるファイル・システムに配置してください。
また,可能であれば異なるディスクに配置してください。
最高の性能を得るには,ディスク上のディレクトリは,ライトバック・キャッシュを有効にした RAID コントローラの管理下に置きます。
サーバの処理量をこなせるだけのメモリ容量とスワップ領域を用意してください。 メモリ容量やスワップ領域が不足すると,性能上の問題が発生することがあります。 メモリとスワップ領域を構成するには,以下の手順に従ってください。
処理量をこなすために必要な物理メモリ量を調べます。
スワップ領域の割り当てモードを,即時モードと延期モードのどちらにするかを選択します。
スワップ領域の必要量を調べます。
ディスク入出力を効率的に分散できるように,スワップ領域を構成します。
インターネット・サーバでは,システムやアプリケーションの動作に必要なメモリの他に,確立されている接続ごとに以下のメモリ・リソースが必要になります。
カーネルのソケット構造体
インターネット・プロトコル制御ブロック (inpcb
) 構造体
TCP 制御ブロック構造体
パケットを受信するたびに消費されるソケット・バッファ領域
これらのメモリ・リソースは,接続終端ごとに 1 KB 必要になります (ソケット・バッファ領域は含みません)。 したがって,10,000 の接続に対応するためには,10 MB のメモリが必要になります。
厳しいピーク時の負荷に耐えられるだけのメモリをサーバが備えていることを確認してください。 負荷が高い日にサーバが必要とするメモリ量の 10 倍のメモリを構成しておけば,時折発生する一時的な高負荷にも対応することができます。
接続をサービスするために必要なだけのメモリ・リソースさえあれば,サーバの TCP 接続の処理量を制限するものはありません。
しかし,メモリ量が十分でない場合は,十分な数の既存の接続が解放されるまで,サーバは新しい接続要求を拒否します。
ネットワーク・サブシステムで現在使用されているメモリをモニタリングするためには,netstat -m
コマンドを使用します。netstat
コマンドの詳細は,6.1.4 項を参照してください。
6.1.3 IP アドレスのロギング
インターネット・サーバでクライアント・ホスト名のログを記録している場合,アプリケーション・ソフトウェアがクライアント・ホスト名を得るためにシステムに DNS 逆引きルックアップを要求することがあります。 DNS 逆引きルックアップは時間のかかる処理なので,クライアントの数が多い高負荷のサーバでは性能上の問題が発生する可能性があります。
クライアント・ホスト名の代わりに,クライアント IP (インターネット・プロトコル) アドレスをログに記録するように,インターネット・ソフトウェアを変更することができます。 IP アドレスでログを記録するようにすれば,重要な情報を失うことなく,インターネット・サーバの効率が著しく改善されます。
クライアント・ホスト名のロギングを無効にする方法については,インターネット・サーバのソフトウェア・ベンダが提供するドキュメントを参照してください。 たとえば,Apache HTTP サーバ・ソフトウェアを変更するための情報は,次の URL の Apache HTTP サーバのドキュメント・サイトで入手できます。
http://httpd.apache.org/docs/
netstat
コマンドは,各プロトコルのネットワーク経路やアクティブ・ソケットの情報などのネットワーク統計情報を表示します。
このコマンドは,受信パケット数と送信パケット数,パケット衝突の回数,ネットワーク操作で使用されたメモリに関する情報,IP,ICMP,TCP,UDP のプロトコル層に関連する統計情報などの累積統計情報も表示します。
netstat
コマンドを使用して調べることができるネットワーク統計情報を表 6-1
に示します。
表 6-1: ネットワーク統計情報モニタリング・ツール
ツール | 説明 | 参照先 |
netstat -i |
過度の入力エラー (Ierrs ),出力エラー (Oerrs ),あるいは衝突 (Coll ) を表示する。
これは,ネットワークに問題がある可能性があることを示す。 |
2.4.5.1 項 |
netstat -is |
ネットワーク・デバイス・ドライバのエラーを検査する。 | 2.4.5.2 項 |
netstat -m |
ネットワークが使用しているメモリがシステムにインストールされているメモリ総量に対して多すぎないか調べる。 | 2.4.5.3 項 |
netstat -an |
既存のネットワーク接続の状態を調べる。 | 2.4.5.4 項 |
netstat -p ip |
不正チェックサム,長さの問題,過度のリダイレクト,およびリソース問題が原因のパケット紛失を検査する。 | 2.4.5.5 項 |
netstat -p tcp |
再送,パケットの順序の乱れ,および不正チェックサムを検査する。 | 2.4.5.6 項 |
netstat -p udp |
不正チェックサムとソケット・フルを検査する。 | 2.4.5.6 項 |
netstat -rs |
ルーティング統計情報を表示する。 | 2.4.5.7 項 |
netstat -s |
IP,ICMP,IGMP,TCP,および UDP プロトコル層に関する統計情報を表示する。 | 2.4.5.8 項 |
sysconfig -q socket |
現在の属性値を表示する。 表示された値によってキューがオーバフローしていることがわかったときには,ソケットのリッスン・キュー限界値を増加させる。 | 6.1.5 項 |
vmstat |
仮想メモリの利用状況のデータを表示する。 | 6.1.6 項 |
詳細は,
netstat
(1)6.1.5 ソケット統計情報のモニタリング
次の 3 つの
socket
サブシステム属性で,ソケット・リッスン・キューのイベントをモニタリングします。
sobacklog_hiwat
属性によって,すべてのサーバ・ソケットに対する保留中の要求の最大数をカウントします。
sobacklog_drops
属性によって,ソケットに対する SYN_RCVD 接続がキューに入れられた数がソケットのバックログ限界値に等しくなったために,システムが受信 SYN パケットをドロップした回数をカウントします。
somaxconn_drops
属性によって,ソケットに対する SYN_RCVD 接続がキューに入れられた数がソケットのバックログ長の上限 (somaxconn
属性) に等しくなったために,システムが受信 SYN パケットをドロップした回数をカウントします。
これらの属性のブート時の初期値は 0 です。sysconfig -q
socket コマンドを使って,現在の属性値を表示します。
キューがオーバフローしていることを示す値が表示された場合は,ソケット・リッスン・キューの限界値を大きくする必要があります。
sysconfig -q
socket コマンドの例を,次に示します。
#
sysconfig -q socket
socket: pftimerbindcpu = 0 sbcompress_threshold = 0 sb_max = 1048576 sobacklog_drops = 0 sobacklog_hiwat = 21 somaxconn = 65535 somaxconn_drops = 0 sominconn = 65535 mbuf_ext_lock_count = 64 umc_min_len = 1024 umc = 0
sominconn
属性の値は,somaxconn
属性の値と同じにすることをお勧めします。
このようにした場合は,somaxconn_drops
の値は,sobacklog_drops
の値と等しくなります。
ただし,sominconn
属性の値が 0 (これが省略時の値) で,また 1 つまたは複数のサーバ・アプリケーションが
listen
システム・コールのバックログ引数に不十分な値を指定している場合は,sobacklog_drops
の値は
somaxconn_drops
カウンタが増加する速度よりも速い速度で増加します。
このような状況が発生する場合は,sominconn
属性の値を大きくしてください。
sominconn
属性の詳細は,6.2.3.2 項を参照してください。
6.1.6 仮想メモリ統計情報のモニタリング
vmstat
コマンドは,仮想メモリの使用状況に関するデータを表示します。
このコマンドは,過度のページングが発生してインターネット・サーバの性能が低下していないか調べるのに役立ちます。
vmstat
コマンドの例を,次に示します。
#
vmstat 1
Virtual Memory Statistics: (pagesize = 8192) procs memory pages intr cpu r w u act free wire fault cow zero react pin pout in sy cs us sy id 7 526 59 80K 758 45K 402M 94M 132M 1M 74M 139K 757 42K 1K 38 14 48 7 526 59 81K 278 45K 939 15 896 0 11 0 824 2K 1K 85 11 4 6 528 59 81K 285 45K 595 67 411 0 10 0 983 5K 2K 81 17 2 7 526 59 81K 353 45K 560 31 446 0 17 0 781 2K 1K 87 10 3 7 526 59 81K 353 45K 406 0 406 0 0 0 1K 4K 2K 85 13 2 7 527 59 81K 288 45K 406 0 406 0 0 0 1K 7K 4K 81 18 1 9 524 59 81K 350 45K 640 72 420 0 13 0 999 3K 2K 85 13 2 . . .
「memory
」欄の値は,8 KB のページ単位で示されます。
未使用ページ・リスト (free
) のサイズをチェックしてください。
未使用ページの数をアクティブ・ページ (act
) および固定ページ (wire
) の値と比較します。
未使用ページ,アクティブ・ページ,および固定ページの合計は,システムの物理メモリの容量に近くなければなりません。
free
の値は小さくても構いませんが,この値が常に小さく (128 ページ未満),ページングとスワッピングが過度に発生している場合は,物理メモリが不足している可能性があります。
また,ページ・アウト (pout
) 欄もチェックしてください。
ページ・アウトの数が常に大きい場合は,メモリが不足している可能性があります。
また,スワップ領域が不足しているか,スワップ領域が不適切に構成されている可能性があります。
swapon -s
コマンドを使って,スワップ・デバイスの構成を表示し,iostat
コマンドを使ってどのスワップ・ディスクが頻繁に使用されているかを調べてください。
詳細は,
vmstat
(1)swapon
(8)iostat
(1)6.1.7 構成情報の収集
sys_check
スクリプトは,構成情報を収集して HTML 形式に変換してファイルに出力する
ksh
スクリプトです。
このスクリプトは,構成上の問題を検出すると警告を発し,カーネル・サブシステムの属性の設定値を調べ,推奨される属性チューニングを提示します。
詳細は,2.3.3 項を参照してください。
sys_check
を使用するときには,最新版を使用してください。
最新版は,次の Web ページから入手できます。
http://h30097.www3.hp.com/sys_check/
インターネット・サーバの性能に影響を与えるカーネル・サブシステムの属性には,多くのものがあります。 ここで言うインターネット・サーバとは,Web サーバ,ftp サーバ,メール・サーバおよびメール中継サーバ,プロキシ・サーバ,キャッシュ・サーバ,ゲートウェイ・システム,およびファイアウォール・システムなどを指します。 この節では,以下のサブシステムのいくつかの属性について,基本的な推奨チューニングを説明します。
注意
カーネル・サブシステム属性の一部は,稼働中のシステムで値を変更してその値を適用することができます。 その他の属性は,新しい値を有効にするためにはシステムをリブートする必要があります。 ある属性がシステムの稼働中にチューニングできるかどうかを確認する方法については,3.3.1 項を参照してください。
基本的な推奨チューニングを適用すれば,大半のインターネット・サーバ構成で,最大の性能改善が得られます。 これらのチューニングを実施してもまだ性能が不十分な場合は,6.3 節で説明している,その他のカーネル・サブシステム属性を変更することで性能を改善できることがあります。
また,CPI (Compaq Continuous Profiling Infrastructure,以前は DCPI と呼ばれていた) ツールを使って,CPU 時間を大量に消費しているシステム・コンポーネントに関する詳細情報を得ることができます。 CPI は Advanced Development Kit として提供されています。 詳細は,次の URL の Web サイトを参照してください。
http://www.tru64unix.compaq.com/dcpi
以下の
inet
インターネット・サブシステムの属性をチューニングすることで,インターネット・サーバの性能を改善することができます。
詳細は,
sys_attrs_inet
(5)6.2.1.1 TCP ハッシュ・テーブルのサイズを大きくする
tcbhashsize
属性は,TCP (Transmission Control Protocol) の
inpcb
ハッシュ・テーブル内のバケット数を指定します。
カーネルは TCP パケットを受信するたびに,接続ブロックを検索する必要があるため,テーブルのサイズを大きくすると検索の速度が速くなり,性能が改善されます。
ただし,ハッシュ・テーブルのサイズを大きくすると,固定メモリが少し増加します。 また,SMP システムでは,これが TCP ハッシュ・テーブルでのボトルネックになる可能性があります。
省略時の値は 512 バケットです。
推奨値は 16384 です。
6.2.1.2 PMTU 検出を無効にする
サーバ間で転送されるパケットは,ルータや,イーサネット・ネットワークのようなパケットの小さなネットワークでのデータ転送を容易にするために,同一サイズのユニットに分割されます。
pmtu_enabled
属性が有効になっていると,オペレーティング・システムはサーバ間の最大の共通 PMTU (Path maximum transmission unit) 値を調べ,それをユニット・サイズとして使用します。
サーバに接続するクライアント・ネットワークごとに,ルーティング・テーブル・エントリも作成されます。
主にリモート・トラフィックを処理し,ルーティング・テーブルが 1000 エントリより多くなってインターネット・サーバの性能が低下している場合,PMTU 検出を無効にすることで,ルーティング・テーブルのサイズを小さくし,サーバの効率を改善することができます。
ただし,サーバが主としてローカル・トラフィックを処理しており,リモート・トラフィックが少ない場合は,PMTU 検出を無効にすると帯域幅が狭くなります。
netstat -r
コマンドを使って,ルーティング・テーブルの内容を表示してください。
省略時の値は,1 (PMTU は有効) です。
推奨値は,0 (PMTU は無効) です。
6.2.1.3 送信接続ポート数を増やす
TCP または UDP のアプリケーションが送信接続を確立する際に,カーネルは接続ごとに,予約されていないポート番号を動的に割り当てます。
カーネルは,ipport_userreserved_min
から
ipport_userreserved
までの範囲で,ポート番号を選択します。
省略時の属性値を使用すると,送信ポートの範囲は,ポート 1024 〜 5000 になるため,同時送信接続数は 3976 (5000 マイナス 1024) に制限されます。
プロキシ・サーバ,キャッシュ・サーバ,ゲートウェイ・システム,またはファイアウォール・システムの同時接続数が 4000 を超える場合は,ipport_userreserved
属性の値を変更したほうがよい可能性があります。
省略時の値は 5000 で,これは最小値です。
推奨値は 65535 で,これは最大値です。
65535 より大きい値や 5000 より小さい値は指定しないでください。
6.2.2 プロセス属性の変更
以下の
proc
プロセス・サブシステムの属性をチューニングすることで,インターネット・サーバの性能を改善することができます。
maxusers
(6.2.2.1 項)
max_proc_per_user
(6.2.2.2 項)
max_threads_per_user
(6.2.2.3 項)
max_per_proc_data_size
(6.2.2.4 項)
max_per_proc_address_space
(6.2.2.5 項)
これらの属性はシステム・リソースの限界値を設定します。 インターネット・サーバがリソースの限界に近づいていると思われる場合は,これらの属性の値を増加させてください。 ただし,これらの属性の値を増加させると,システムのメモリ消費量が増加します。
詳細は,
sys_attrs_proc
(5)6.2.2.1 システム・テーブルとデータ構造体のサイズを大きくする
システムのアルゴリズムでは,各種のデータ構造体とシステム・テーブルのサイズを決めるために,maxusers
属性を使用します。
maxusers
属性の値を大きくすると,より多くのシステム・リソースをプロセスが使用できるようになります。
ただし,固定メモリの量が増加します。
システムでリソースの不足が発生していて (たとえば,「Out of processes
」,「No more processes
」,または「pid table is full
」といったメッセージが表示される),メモリが十分にある場合は,maxusers
属性の値を大きくしてください。
maxusers
属性の適切な値を決めるためには,性能が改善されるまで,省略時の値を 2 倍にしていきます。
たとえば,1 GB のメモリがある場合は,maxusers
属性の値を 512 に増加させます。
2 GB のメモリがある場合は,値を 1024 に増加させます。
インターネット・サーバ,Web サーバ,プロキシ・サーバ,キャッシュ・サーバ,ファイアウォール・システム,またはゲートウェイ・システムの場合は,maxusers
属性の値を 2048 に増加させます。
省略時の値は,システムに実装されている物理メモリの量に従って,16 〜 2048 の間で変化します。 2048 より大きな値にすることは,お勧めできません。
システム管理者は,maxusers
属性を,次のコマンドで変更できます。
#
sysconfig -r proc maxusers=N
N
に新しい値を指定します。
このコマンドによって,pid テーブル
が自動的に拡張されます。
他のシステム・テーブルのサイズ変更は,/etc/sysconfigtab
ファイルの
maxusers
属性に新しい値を指定してシステムをリブートするまで行われません。
6.2.2.2 ユーザごとのプロセス数を増やす
max_proc_per_user
属性は,各ユーザ (スーパユーザを除く) に割り当てることができるプロセスの最大数を指定します。
システムでプロセス不足の状況が発生している場合は,この属性の値を大きくしてください。 マルチプロセスのインターネット・サーバ (たとえば,IPlanet,Apache,CERN,または Zeus を稼働させているサーバ) の場合も,この属性の値を大きくしたほうがよい可能性があります。 この値を大きくすると,固定メモリの量も増加することに注意してください。
省略時の値は 64 です。
推奨値は 2000 です。
選択する値は,システムで起動できるプロセスの最大数を超えてはなりません。
インターネット・サーバの場合は,これらのプロセスには,CGI プロセスが含まれます。
この属性の値として 0 を指定すると,ユーザごとのプロセス数には制限がなくなります。
6.2.2.3 ユーザごとのスレッド数を増やす
max_threads_per_user
属性は,各ユーザ (スーパユーザを除く) に割り当てることができるスレッドの最大数を指定します。
システムでスレッド不足の状況が発生している場合は,この属性の値を大きくしてください。 マルチスレッドのインターネット・サーバ (たとえば,Netscape FastTrack または Netscape Enterprise を稼働させているサーバ) の場合は,この属性の値を大きくしたほうがよい可能性があります。
省略時の値は 256 です。
推奨値は 4096 です。
選択する値は,システムで起動できるスレッドの最大数を超えてはなりません。
6.2.2.4 ユーザ・プロセスのデータ・セグメント・サイズの限界値を大きくする
max_per_proc_data_size
属性は,データ・セグメント・サイズの上限の限界値を指定します。
大きなプログラムや大きなメモリを使用するプロセスには,この属性値を大きくしないと実行できないものがあります。
「Out of process memory
」というメッセージが表示される場合は,この限界値を大きくしてください。
省略時の値は 1073741824 (1 GB) です。
推奨値は 10737418240 (10 GB) です。
システムのメモリが 10 GB より大きい場合は,この値をもっと大きくすることができます。
6.2.2.5 ユーザ・プロセスのアドレス空間の限界値を大きくする
max_per_proc_address_space
属性は,ユーザ・プロセスのアドレス空間の上限の限界値 (仮想メモリのバイト数) を指定します。
大きなプログラムや大きなメモリを使用するプロセスには,この属性値を大きくしないと実行できないものがあります。
ただし,アドレス空間の限界値を大きくすると,メモリの消費量も少し増加します。
省略時の値は,Tru64 UNIX バージョン 5.0 以降が稼働しているシステムでは 4,294,967,296 バイト (4 GB) です。
推奨値は 10,737,418,240 (10 GB) です。
システムのメモリが 10 GB より大きい場合は,この値をもっと大きくすることができます。
6.2.3 ソケット属性の変更
以下のソケット属性をチューニングすることで,インターネット・サーバの性能を改善することができます。
詳細は,
sys_attrs
(5)6.2.3.1 保留中 TCP 接続の最大数を増やす
somaxconn
属性は,各サーバのソケット (たとえば,HTTP サーバのソケット) の保留中 TCP 接続の最大数 (ソケット・リッスン・キューの限界値) を指定します。
TCP 接続の保留は,インターネットでのパケットの紛失やサービス拒否アタックによって発生します。
負荷の高いインターネット・サーバでは,保留中 TCP 接続の数が多くなることがあります。
リッスン・キューの接続限界値が小さすぎると,受信接続要求がドロップされることがあります。
省略時の値は 1024 です。
推奨値は 65535 で,これは最大値です。
最大値より大きい値を指定したときの動作は予測できないため,最大値より大きい値は,指定しないでください。
6.2.3.2 保留中 TCP 接続の最小数を増やす
sominconn
属性は,各サーバのソケットの保留中 TCP 接続 (backlog
) の最小数を指定します。
この属性は,システムが同時に処理できる SYN パケットの最大数を制御し,これ以上の要求は破棄されます。
クライアントがソケット・リッスン・キューをエラーの TCP SYN パケットでいっぱいにすると,他のユーザがキューにアクセスできなくなるため,ネットワーク性能が低下します。
sominconn
属性の値は,アプリケーションに固有の
backlog
値より優先されます。
このアプリケーションに固有の値は,サーバ・ソフトウェアによっては,小さ過ぎる場合があります。
アプリケーションのソース・コードがない場合は,sominconn
属性を使って,接続保留の限界値にアプリケーションに適した値を設定してください。
省略時の値は 0 です。
推奨値は 65535 で,これは最大値です。
sominconn
属性の値を,somaxconn
属性の値と同じにすることをお勧めします。
somaxconn
属性の詳細は,6.2.3.1 項を参照してください。
6.2.3.3 mbuf クラスタの圧縮を有効にする
sbcompress_threshold
属性は,mbuf
クラスタをソケット層で圧縮するかどうかを制御します。
省略時の設定では,mbuf
クラスタは圧縮されないため,プロキシ・サーバやキャッシュ・サーバがすべての使用可能な
mbuf
クラスタを消費してしまう場合があります。
この問題は,イーサネットの代わりに FDDI を使用しているときによく発生します。
mbuf
クラスタをモニタリングする方法の詳細は,2.4.5.3 項を参照してください。
mbuf
クラスタの圧縮を有効にするには,sbcompress_threshold
属性を変更し,値を指定します。
パケット・サイズがこの値より小さい場合,そのパケットは既存の
mbuf
クラスタにコピーされます。
省略時の値は 0 (mbuf
圧縮は無効) です。
プロキシ・サーバ,キャッシュ・サーバ,ゲートウェイ・システム,またはファイアウォール・システムの場合,推奨値は 600 バイトです。
6.3 高度な推奨チューニング
この節では,以下のサブシステムのいくつかの属性について,高度な推奨チューニングを説明します。
これらのチューニングは,十分な物理メモリを備えた,主としてインターネット・サーバとして使用されるシステムに対してのみ有効です。 インターネット・サーバ以外で属性の推奨値を使用すると,システム性能が低下することがあります。
インターネット・サーバの構成はシステムごとに異なっており,推奨値はすべての構成に最適なものではないため,属性値の変更は注意深く行う必要があります。
属性の説明を読み,使用しているシステムの構成に適した値を確認してください。
属性の値を変更しても性能が改善できない場合は,省略時の値に戻してください。
6.3.1 汎用属性の変更
kmemreserve_percent
汎用 (generic
) サブシステム属性をチューニングすることで,インターネット・サーバの性能を改善できます。
この属性は,ページ・サイズ (8 KB) 以下のカーネルのメモリ割り当て用に予約される物理メモリの割合を増加させます。
kmemreserve_percent
の値を大きくすると,システムに大きなネットワークの負荷がかかっているときにドロップされるパケットの数が減るため,ネットワーク・スループットが改善されます。
ただし,この値を大きくすると,メモリを消費します。
kmemreserve_percent
属性値の増加は,netstat
コマンドの出力でパケットのドロップが示される場合,または
vmstat -M
コマンドの出力で「fail_nowait
」見出しの下にパケットのドロップが示される場合に行ってください。
これは,システムに大きなネットワークの負荷がかかっているときに発生します。
省略時の値は 0 (予約する物理メモリの割合は,使用可能なメモリの 0.4% と 256 KB のうち小さい方) です。
この値を少しずつ (最大,75 まで) 増やし,vmstat -M
コマンドで「fail_nowait
」見出しの下のエントリ数が 0 になるまで増やしていきます。
6.3.2 インターネット属性の変更
インターネット・サーバの性能は,以下の
inet
インターネット・サブシステム属性をチューニングすることで,改善できます。
tcbhashnum
(6.3.2.1 項)
inifaddr_hsize
(6.3.2.2 項)
tcp_keepinit
(6.3.2.3 項)
tcp_rexmit_interval_min
(6.3.2.4 項)
tcp_keepalive_default
(6.3.2.5 項)
tcp_msl
(6.3.2.6 項)
ipport_userreserved_min
(6.3.2.7 項)
ipqs
(6.3.2.8 項)
ipqmaxlen
(6.3.2.9 項)
カーネル・サブシステム属性の変更については,
sys_attrs_inet
(5)6.3.2.1 TCP ハッシュ・テーブルの数を増やす
tcbhashnum
属性は,TCP ハッシュ・テーブルの数を指定します。
ハッシュ・テーブルの数を増やすと負荷が分散されるため,性能が改善できます。
ただし,システムの固定メモリが少し増加します。
省略時の値は,1 ハッシュ・テーブルですが,この値は最小値です。 負荷の高いインターネット・サーバの SMP システムでは,推奨値は 16 です。 最大値は 64 です。
ハッシュ・テーブルの数を増やしたら,ハッシュ・テーブルのサイズを小さくしてください。
詳細は,6.2.1.1 項を参照してください。
また,この属性の値は,ipqs
属性と同じ値にすることをお勧めします。
ipqs
属性の詳細は,6.3.2.8 項を参照してください。
6.3.2.2 ハッシュ・バケットの数を増やす
inifaddr_hsize
属性は,カーネル・インタフェース別名テーブル (in_ifaddr
) 内のハッシュ・バケットの数を指定します。
システムが,多くのサーバ・ドメイン名 (それぞれが固有の IP アドレスに割り当てられている) をサービスしている場合,受信したパケットを正しいサーバ・アドレスと照合する処理では,IP アドレスを高速に検索するために,ハッシュ・テーブルを使用します。
これらの IP アドレスは,通常,ifconfig alias
コマンド,または
ifconfig aliaslist
コマンドを使って設定されます。
テーブル内のハッシュ・バケットの数を増やすと,多数の IP 別名アドレスを使っているシステムの性能が改善されます。
省略時の値は,32 ハッシュ・バケットです。 インタフェース IP 別名を使用していなかったり,250 未満の別名しか使用していない大部分のインターネット・サーバでの推奨値は,32 です。 500 を超えるインタフェース IP 別名を使用している場合は,推奨値は 512 で,これが最大値です。
最適な性能を得るためには,この属性の値は,最も近い 2 のべき乗値まで切り下げる必要があります。
6.3.2.3 TCP パーシャル接続タイムアウト限界値を変更する
tcp_keepinit
属性は,部分的に確立された TCP 接続が,ソケット・リッスン・キューに留まる最長時間 (タイムアウトになるまでの時間) を指定します。
この属性の値は,0.5 秒単位です。
パーシャル接続は,ソケット・リッスン・キューのスロットを消費し,キューを
SYN_RCVD
状態の接続で満たします。
省略時の値は,150 単位 (75 秒) です。
somaxconn_drops
属性の値が増加することがそれほどなければ,TCP パーシャル接続タイムアウト限界値を変更する必要はありません。
イベント・カウンタの詳細は,6.1.5 項を参照してください。
ソケット・キューの限界値として最大値を設定している場合は,通常はこの属性の省略時の値で十分です。
somaxconn_drops
属性の値が頻繁に増加し,ソケット・キューの限界値を大きくしてもリッスン・キューがいっぱいになるのを避けることができない場合は,この属性の値を小さくして,パーシャル接続がもっと早くタイムアウトになるようにします。
また,クライアントによってソケット・リッスン・キューに TCP SYN パケットが過度に詰め込まれると,他のユーザがキューにアクセスできなくなるため,ネットワーク性能が低下します。
この問題を避けるためには,ソケット・リッスン・キューの限界値を最大値まで大きくします。
それでもシステムが SYN パケットをドロップする場合は,tcp_keepinit 属性の値を 30 (15 秒) に下げてください。
システムがパケットをドロップしているかどうかを確認するには,イベント・カウンタの
sobacklog_drops
と
somaxconn_drops
の値をモニタリングします。
この属性の値を小さくし過ぎないでください。
小さくし過ぎると,遅いネットワーク・パスや多くのパケットがドロップするネットワーク・パスでは,クライアントとの接続処理の打ち切りが早過ぎてしまうためです。
この値は,20 単位 (10 秒) より小さくしないでください。
6.3.2.4 TCP 再送の速度を遅くする
tcp_rexmit_interval_min
属性は,最初の TCP 再送の時間間隔の最小値を指定します。
一部の WAN (wide area network) では,省略時の値では小さ過ぎるため,再送タイムアウトが早く発生し,それによってパケットを重複して送信したり,TCP 混雑回避アルゴリズムが誤って起動されることがあります。
この属性の値を大きくすると,TCP 再送速度が遅くなるため,混雑を減らし性能を改善することができます。
省略時の値は 2 単位 (1 秒) です。 すべての接続が,長い再送時間を必要とするわけではありません。 通常はこの属性の省略時の値で十分です。 しかし,一部の WAN では,省略時の再送時間では小さ過ぎることがあります。
再送が発生しているかどうかを確認するには,netstat -p tcp
コマンドの出力で「再送されたデータ・パケット (data packets retransmitted)」を調べます。
この属性の値を大きくして,TCP 再送速度を遅くすることができます。 この属性は,0.5 秒単位で指定します。
この属性の省略時の値は,TCP アルゴリズムを熟知していないかぎり,変更しないでください。
1 単位より小さい値は指定しないでください。
6.3.2.5 TCP 持続機能を有効にする
持続 (keepalive) 機能を使用すると,接続済みのソケット上でメッセージを定期的に転送する際に,アクティブな接続を持続させ,アクティブでない接続をタイムアウトにすることができます。 明確に終了していないソケットは,持続時間が経過すると,抹消されます。 持続機能が有効になっていない場合,これらのソケットはシステムをリブートするまで存続し続けます。
アプリケーションでは,setsockopt
関数の
SO_KEEPALIVE
オプションを設定することで,ソケットの持続機能を有効にします。
省略時の値は 0 (持続機能は無効) です。
持続機能を有効にしていないプログラムの場合,またはアプリケーションのソース・コードに手を加えることができない場合に持続機能を有効にしたいときには,この属性を 1 にしてください。
この属性を設定した後は,すべての接続で持続機能が有効になります。
既存の接続は,以前の持続機能の設定内容のままになります。
この属性を変更した後にシステムをリブートしていないときには,既存のソケットの動作は,アプリケーションを再起動するまで以前の動作のままになります。
持続機能を有効にすると,ソケットごとに以下の TCP オプションも構成できます。
tcp_keepidle
属性で,持続プローブを送信するまでのアイドル時間を 0.5 秒単位で指定できます。
この属性の省略時の値は,2 時間です。
tcp_keepintvl
属性で,持続プローブの再送間隔を 0.5 秒単位で指定できます。
この属性の省略時の値は,75 秒です。
tcp_keepcnt
属性で,接続を打ち切る前に送信される持続プローブの最大数を指定できます。
この属性の省略時の値は,8 プローブです。
tcp_keepinit
属性で,最初の接続要求がタイムアウトになるまでの時間を,0.5 秒単位で指定できます。
この属性の省略時の値は,75 秒です。
6.3.2.6 TCP 接続コンテキスト・タイムアウトの頻度を高くする
tcp_msl
属性は,TCP セグメントの最大存続期間と
TIME_WAIT
状態のタイムアウト値を決定します。
TCP プロトコルには,MSL (最大セグメント存続期間) という概念があります。
TCP 接続が
TIME_WAIT
状態になると,MSL の 2 倍の時間だけこの状態に留まる必要があります。
そうしないと,その後の接続で検出されないデータ・エラーが発生する可能性があります。
この属性の値を小さくすることで,接続終了時に TCP 接続コンテキストを,より早くタイムアウトさせることができます。 ただし,そのようにすると,データが壊れる可能性が高くなります。
省略時の値は 60 単位です (これは 30 秒で,TCP 接続が 60 秒間,すなわち MSL の倍の時間だけ,TIME_WAIT
状態に留まることを意味します)。
この属性値は,0.5 秒単位で設定します。
推奨値は省略時の値です。
これ以外の値を指定すると,データが壊れる可能性があります。
TCP の仕様では MSL は 120 秒と規定されていますが,大部分の TCP の実装では,120 より小さい値を使用しています。 詳細は,Internet FAQ Consortium Web サイトを参照してください。 RFC793 については,次の URL を参照してください。
http://www.faqs.org/rfcs/rfc793.html
RFC1122 については,以下の URL を参照してください。
http://www.faqs.org/rfcs/rfc1172.html
場合によっては,TIME_WAIT
状態の省略時のタイムアウト値が長すぎることがあります。
そのため,この属性の値を小さくすると,接続リソースを省略時の動作より早く解放させることができます。
この属性の値は,ネットワークおよび TCP プロトコルの設計と動作について熟知していないかぎり,小さくしないでください。
6.3.2.7 送信接続ポートの範囲を変更する
TCP または UDP のアプリケーションが送信接続を確立する際に,カーネルは接続ごとに,予約されていないポート番号を動的に割り当てます。
カーネルは,ipport_userreserved_min
から
ipport_userreserved
までの範囲から,ポート番号を選択します。
システムが特定の範囲のポートを必要とする場合は,この属性の値を変更することができます。
省略時の値は 1024 です。
最大値は 65535 です。
この属性に,65535 より大きい値や 1024 より小さい値は指定しないでください。
6.3.2.8 IP 受信キューの数を増やす
SMP システムでは,IP 受信キューの数を増やすと,受信キューのロック争奪が減少し,負荷を分散させることができます。
ipqs
属性は,IP 受信キューの数を指定します。
省略時の値は,最小値である 1 キューです。 負荷が高いインターネット・サーバの SMP システムでは,推奨値は 16 です。 最大値は 64 です。
この属性の値は,tcbhashnum
属性と同じ値にすることをお勧めします。tcbhashnum
属性の詳細は,6.2.1.1 項を参照してください。
6.3.2.9 IP 受信キューの最大長を大きくする
ネットワークの負荷が高い場合,IP 受信キューがいっぱいになって,受信パケットがドロップすることがあります。ipqmaxlen
属性は,IP 受信キュー (ipintrq
) の最大長をバイト単位で指定します。
この長さを超えた受信パケットはドロップします。
システムで受信パケットがドロップしている場合は,ipqmaxlen
属性の値を大きくしたほうがよい可能性があります。
受信パケットがドロップしているかどうかを確認するには,以下のように,dbx
コマンドを使って,ipintrq
カーネル構造体を調べてください。
#
dbx -k /vmunix
(dbx)
print ipintrq
struct { ifq_head = (nil) ifq_tail = (nil) ifq_len = 0 ifq_maxlen = 512 ifq_drops = 128 ifq_slock = struct { sl_data = 0 sl_info = 0 sl_cpuid = 0 sl_lifms = 0 } }
ifq_drops
フィールドが 0 でない場合,システムは IP 受信パケットをドロップしています。
省略時の値は,1024 です。
最小値が省略時の値です。
最大値は 65535 です。
システムが受信パケットをドロップしている場合,推奨値は 2048 です。
送信キューを制御する
ifqmaxlen
属性の値を大きくしたほうがよい場合もあります。ifqmaxlen
属性の詳細は,6.3.3.1 項を参照してください。
以下の
net
ネットワーク・サブシステムの属性をチューニングすることで,インターネット・サーバの性能を改善できます。
ifqmaxlen
(6.3.3.1 項)
screen_cachedepth
(6.3.3.2 項)
screen_cachewidth
(6.3.3.2 項)
screen_maxpend
(6.3.3.3 項)
詳細は,
sys_attrs_net
(5)6.3.3.1 送信キューの最大長を大きくする
ネットワークの負荷が高い場合,インタフェースの送信キューがいっぱいになって,送信パケットがドロップされることがあります。
ifqmaxlen
属性は,パケットがドロップされることなく,ネットワーク・アダプタの送信キューに入れることができるパケットの数を指定します。
netstat -id
コマンドを使って,送信パケットがドロップされているかどうかを確認することができます。
このコマンドの出力で,インタフェースの「Drop
」欄が 0 でない場合,システムで送信パケットのドロップが発生しているので,この属性の値を大きくしたほうがよい可能性があります。
省略時の値は,1024 です。
最小値は,省略時の値です。
最大値は,65535 です。
システムが送信パケットをドロップしている場合は,推奨値 は 2048 です。
6.3.3.2 スクリーニング・キャッシュのミスを減らす
スクリーニング・ルータ,または
screend
機能を実行しているスクリーニング・ファイアウォールとして動作しているコンピュータで,多くのパス・スルー接続が同時に確立されている場合,スクリーニング・キャッシュのミスが発生している可能性があります。
スクリーニング・キャッシュのミスは,カーネルのスクリーニング・テーブルで,アドレス/ポートの組とプロトコルに従って,キャッシュ・エントリのないパケットを,スクリーニングしようとしたときに発生します。
この場合,テーブルによってパケットがキューにつながれ,screend
デーモンがそのパケットを調べます。
これは,通常,接続の最初のパケットの場合と,キャッシュが多くのエントリを保持するには小さすぎる場合に発生します。
スクリーニング・キャッシュがミスしているかどうかを確認するには,次のように,dbx
を使ってスクリーニング・キャッシュのヒットとミスを調べます。
(dbx) p screen_cachemiss 616738 (dbx) p screen_cachehits 11080198
ヒットに比べてミスの割合が高い場合は,screen_cachedepth
属性と
screen_cachewidth
属性の値を大きくしたほうがよい可能性があります。
screen_cachedepth
属性の省略時の値は 8 で,これは最小値です。
スクリーニング・キャッシュのミス率が高い場合,推奨値は 16 で,これは最大値です。
screen_cachewidth
属性の省略時の値は 8 で,これは最小値です。
スクリーニング・キャッシュのミス率が高い場合,推奨値は 2048 で,これは最大値です。
screen_cachedepth
を大きくする前に,まず
screen_cachewidth
を大きくすることをお勧めします。
また,これらの属性をチューニングしても,必ずしもスクリーニング・キャッシュのミスは 0 にならないことに注意してください。
変更した内容を有効にするには,リブートが必要です。
これらの値を大きくするとメモリの消費量が少し増えます。
6.3.3.3 スクリーニング・バッファのドロップを減らす
スクリーニング・ルータ,または
screend
機能を実行しているスクリーニング・ファイアウォールとして動作しているコンピュータで,ネットワークの負荷が高い場合,スクリーニング・バッファのドロップが発生している可能性があります。
screenstat
コマンドを使って,現在の状態を表示してください。
例を以下に示します。
#
/usr/sbin/screenstat
total packets screened: 11696910 total accepted: 11470734 total rejected: 225453 packets dropped: because buffer was full: 34723 because user was out of sync: 0 because too old: 0 total dropped: 34723
「バッファがいっぱいのため (because buffer was full
)」にドロップされているパケットの数が多い場合,screen_maxpend
属性の値を大きくしたほうがよい可能性があります。
省略時の値は 32 で,これは最小値です。
スクリーニング・バッファがいっぱいになったことを示す値が大きい場合,推奨値は 8192 です。
最大値は 16384 です。
この値を大きくするとメモリの消費量が少し増えます。
この属性を変更するには,システムのリブートが必要です。
6.3.4 ソケット属性の変更
インターネット・サーバの性能は,sb_max
ソケット (socket
) サブシステム属性をチューニングすることで,改善できます。
また,socket
サブシステムの属性の
sobacklog_hiwat
,sobacklog_drops
,および
somaxconn_drops
は,ソケット・リッスン・キューに関するイベントを追跡します。
これらの値をモニタリングすることにより,キューがオーバフローしているかどうかを調べることができます。
これらの属性の詳細は,6.1.5 項を参照してください。
sb_max
属性は,ソケット・バッファの最大サイズを指定します。
ソケット・バッファの最大サイズを大きくすると,バッファ・サイズが大きいほうが効率が良くなるアプリケーションを使っている場合,性能が改善されます。
省略時の値は 1048576 バイトです。 省略時の値より大きなソケット・バッファを必要とするアプリケーションでは,この属性の値を大きくしてください。
カーネル・サブシステム属性の変更については,
sys_attrs
(5)6.3.5 仮想メモリ属性の変更
インターネット・サーバの性能は,vm
仮想メモリ・サブシステム属性
ubc_maxpercent
,ubc_minpercent
および
ubc_borrowpercent
をチューニングすることで,改善できます。
負荷の高いインターネット・サーバでは,通常,仮想メモリの消費量は平均的で,多数のファイルが使用されます。 プロセスと,ファイル・システムのデータをキャッシュする UBC (Unified Buffer Cache) は,カーネルが固定していない物理メモリを共有します。
UBC に割り当てるメモリが多すぎると,過度のページングとスワッピングが発生し,システム全体の性能が低下します。 逆に,UBC に割り当てるメモリが少なすぎると,ファイル・システムの性能が低下します。
ubc_minpercent
属性は,UBC だけが利用できるメモリの最小割合を指定します。
残りのメモリは,プロセスと共有されます。ubc_maxpercent
属性は,UBC が利用できるメモリの最大割合を指定します。ubc_borrowpercent
属性は,UBC の借用しきい値を指定します。
ubc_borrowpercent
属性の値と
ubc_maxpercent
属性の値の間で,UBCに割り当てられているメモリはプロセスから借りていると見なされます。
ページングが始まると,これらの借りているページが最初に再生され,UBCに割り当てられたメモリは
ubc_borrowpercent
属性の値になるまで減らされます。
ubc_minpercent
の省略時の値は 10% です。
ubc_maxpercent
の省略時の値は 100% です。
ubc_borrowpercent
の省略時の値は 20% です。
通常のインターネット・サーバでは,各属性の省略時の値で十分です。
また,ディスクに対してファイル・システム入出力が頻繁に実行され,システムに十分な空きページがある場合も,省略時の値を使用してください。
vmstat
コマンドを使って,空きページの数などの仮想メモリ情報を表示してください。
空きページの数が少ない場合は,UBC が利用できるメモリを減らし,プロセスが利用できるメモリを増やしたほうがよい可能性があります。 UBC ミスの回数が増えたとしても,プロセスのワーキング・セットをメモリ内に維持する必要があります。
ubc_maxpercent
属性の値を,省略時の値から 10% 単位で減らしてみてください。
ubc_borrowpercent
属性の値を減らして借用メモリのしきい値を減らすと,メモリが少ない場合にシステムの応答時間が改善されます。
ただし,これにより,UBC の性能は低下します。