Sun Java System Web Server 7.0 パフォーマンスのチューニング、サイジング、およびスケーリング

Solaris プラットフォーム固有の問題

ここでは、その他の Solaris 固有の問題やチューニングの注意事項について説明します。この章の内容は、次のとおりです。

1 つのプロセスで開いているファイルの数 (ファイル記述子の制限)

1 つのプロセスで一度に開くことのできるファイルの数に対する制限は、プラットフォームごとに異なります。ビジー状態のサイトでは、その数を増やすことが必要な場合があります。Solaris システムでは、/etc/system ファイル内の rlim_fd_max を設定することによってこの制限を制御します。Solaris 8 の場合、デフォルトは 1024 であり、65536 まで増やすことができます。Solaris 9 および 10 の場合、デフォルトは 65536 であり、この値を増やす必要はありません。

/etc/system ファイルでこの変更や、その他の任意の変更を行ったあと、新しい設定を有効にするには Solaris を再起動します。さらに、新しいバージョンの Solaris にアップグレードした場合は、/etc/system に追加した行をすべて削除し、その行がまだ有効なことを確認したあとでのみ、もう一度追加するようにしてください。

この変更を行う別の方法に、ulimit –n "value" コマンドの使用があります。このコマンドを使用した場合、システムの再起動は必要ありません。ただし、このコマンドではログインシェルだけが変更されます。これに対して、etc/system ファイルの編集はすべてのシェルに影響します。

HTTP サーバーへの接続の失敗

サーバーの負荷が高いときに、ブラウザから Web Server への接続タイムアウトが発生している場合は、HTTP リスナーのバックログキューのサイズを増やすことができます。この設定を増やすには、HTTP リスナーの待機キューの値を編集します。

また、この設定に加えて、Solaris TCP/IP ネットワークコード内の制限も増やしてください。次のコマンドを実行することによって変更される 2 つのパラメータが存在します。

/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q 8192
/usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q0 8192

これらの 2 つの設定によって、待機中の接続でいっぱいになる可能性のある 2 つの Solaris 待機キューの最大数が増えます。tcp_conn_req_max_q によって、accept() 呼び出しからの復帰を待っている完了した接続の数が増えます。tcp_conn_req_max_q0 によって、ハンドシェークが未完了の接続の最大数が増えます。デフォルト値はそれぞれ、128 と 1024 です。これらの ndd コマンドがシステムの再起動のたびに自動的に実行されるようにするには、そのコマンドを /etc/init.d/network-tuning という名前のファイルに格納し、そのファイルへのリンクを /etc/rc2.d/S99network-tuning という名前で作成します。

これらの変更の効果は、netstat -s コマンドを使用し、tcpListenDrop、tcpListenDropQ0、および tcpHalfOpenDrop 値を確認することによって監視できます。調整を行う前に、これらの値を確認してください。これらの値が 0 でない場合は、最初に 2048 に調整し、netstat 出力の監視を続けます。

Web Server HTTP リスナーの待機キューの設定と、それに関連する Solaris の tcp_conn_req_max_q と tcp_conn_req_max_q0 の設定は Web Server のスループットに一致するはずです。これらのキューは、Web ユーザーから受信した接続の不規則な比率を管理するための「バッファー」として機能します。これらのキューによって、Solaris はそれらの接続を受け付け、それらが Web Server によって処理されるまで保持することができます。

Web Server が処理できる量より多くの接続を受け付ける必要はありません。これらのキューのサイズを制限し、過剰な接続を受け付けたために接続に対応できなくなるより過剰な接続を拒否することをお勧めします。一般に、これらの 3 つのパラメータの値を 2048 に設定すると接続要求の失敗が減少し、4096 までの値でパフォーマンス向上が確認されています。

この調整はどの Web ホスティング環境にも悪影響を与えないと予測されているため、システムが前述の症状を示していない場合でも、この提案を検討できます。

接続拒否のエラー

負荷の高いサーバーで接続拒否のエラーが発生している場合は、そのサーバー上でのネットワーク資源の使用をチューニングすることができます。

TCP/IP 接続が閉じられていると、そのポートは tcp_time_wait_interval (デフォルト値は 240000 ミリ秒) の間再利用されません。これは、残されたセグメントが発生しないようにするためです。tcp_time_wait_interval が小さければ小さいほど、貴重なネットワーク資源が早くふたたび使用可能になります。このパラメータは、次のコマンドを実行することによって変更されます。ただし、60000 未満にはしないでください。

usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval 60000

この ndd コマンドがシステムの再起動のたびに自動的に実行されるようにするには、そのコマンドを /etc/init.d/network-tuning という名前のファイルに格納し、そのファイルへのリンクを /etc/rc2.d/S99network-tuning という名前で作成します。

システムが先に述べた症状を示しておらず、TCP プロトコルのチューニングにも精通していない場合は、前述のパラメータを変更しないようにすることをお勧めします。

TCP バッファリングのチューニング

継続的に負荷の高いサーバーからのネットワーク応答に、予測不可能な速度低下がときどき見られる場合は、/etc/system ファイルに次の行を追加することによって sq_max_size パラメータの設定を調査することもできます。

set sq_max_size=512

この設定は、パケットをハードウェアドライバから TCP/IP プロトコルドライバに転送する同期キューのサイズを調整します。512 の値を使用すると、キューがオーバーフローすることなく、大量のネットワークトラフィックを格納できるようになります。

Solaris Network Cache and Accelerator (SNCA) の使用

Solaris Network Cache and Accelerator (SNCA) は、Solaris オペレーティングシステムでの Web パフォーマンスを向上させるキャッシュサーバーです。

Web Server が実行されているシステムでは SNCA が設定されていることが前提になります。SNCA およびその構成とチューニングの詳細については、各システムの次のマニュアルページを参照してください。

ncab2clf(1)
ncakmod(1)
nca(1)
snca(1)
nca.if(4)
ncakmod.conf(4)
ncalogd.conf(4)

SNCA を Web Server と連動させる

前述したように、この手順は SNCA が設定されていることを前提にしています。

「共通操作」ページで、構成を選択し、「構成を編集」をクリックします。

「HTTP リスナー」タブをクリックし、編集する HTTP リスナーを選択します。

「HTTP リスナーの編集」ページで、「プロトコルファミリ」を nca に設定します。

これが機能するには、HTTP リスナーがポート 80 上で待機している必要があります。

変更を保存します。

「パフォーマンス」タブをクリックします。

「キャッシュ」サブタブをクリックします。

「キャッシュ設定」ページで、ファイルキャッシュが有効になっていることを確認し、「Sendfile を使用」を有効にします。

変更を保存します。

変更を有効にするには、構成を再配備します。

最大スレッド数とキューサイズ

Web Server を SNCA とともに使用するように設定する場合は、スレッドプールを無効にするとパフォーマンスが向上します。これらの設定は、構成の「パフォーマンス」タブ ⇒「HTTP」サブタブの「スレッドプール設定」の下にあります。スレッドプールを無効にするには、「スレッドプール」の「有効」チェックボックスを選択解除します。また、wadm set-thread-pool-prop コマンドの enabled プロパティーを使用してスレッドプールを無効にすることもできます。

SNCA 以外の構成で、特に、キープアライブなしで短い待ち時間の応答を実現する必要がある場合にも、スレッドプールを無効にすることができます。