高負荷-非常にビジーなコンテンツストリーミングサーバーに最適なsysctl.conf構成

高負荷で非常にビジーなコンテンツストリーミングサーバーに最適なsysctl.conf構成は何ですか？サーバーは、amazon、s3などのリモートサーバーからコンテンツをフェッチし、phpを使用して、コンテンツをハードドライブに保存せずに動的にユーザーにストリーミングします。phpはCURLを使用してファイルをフェッチし、次にflush（）を使用して同時にストリーミングするため、ハードドライブの動作はそれほどではなく、ネットワークと帯域幅のみです。

サーバーはクアッドコアxeonで、1Gビットの全二重NIC、8GBのRAM、RAIDに500GBx2を備えています。サーバーのメモリ使用量とCPU負荷はかなり低いです。

私たちは、その上でdebian lennyとlighttpd2を実行しています（はい、まだリリースされていないことがわかります:-)）。最大fcgiリクエストは20で、mod_balancerモジュールがlighttpd2設定にあり、SQF（ショートキューが最初）の設定でこれらの4つのソケット間でfastcgiリクエストのバランスを取ります。

当社のサーバーは多くの帯域幅を使用します。つまり、ネットワーク接続は常にビジーです。100〜200の並列接続の直後に、サーバーの速度が低下し始め、最終的に応答がなくなり、接続タイムアウトエラーが発生し始めます。cpanelを使用していたときは、タイムアウトエラーは発生しなかったため、スクリプトの問題ではありません。ネットワーク構成の問題である必要があります。

lighttpd2構成：ワーカープロセス= 8、キープアライブリクエストは32、キープアライブアイドルタイムアウトは10秒、最大接続は8192です。

現在のsysctl.confの内容は次のとおりです。

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

このようなパフォーマンスチューニングとボトルネックの特定は解決が難しい問題であり、診断するには多くの情報が必要になることがよくあります。プロセスの鍵は、使用するプロセスを実行し、どのリソースが使い果たされているかを見つけることができるかどうかを確認することです。サーバーがphpに対して応答しないが、htmlは機能するというのは、興味深いデータポイントです。それらが提供される方法の違いは何ですか？微妙なネットワークバッファオーバーランである場合もあれば、それよりも基本的な場合もあります。子のfcgi子プロセスの20個の制限を使い果たした可能性があります。それらはすべて、データの提供でビジー状態ですが、新しい要求は、fcgiのphpプロセスが起動するのを待って、待ち行列に詰まり（最終的にはタイムアウトします）ます。

ボックスを表示しようとする場合の本当の秘訣は、問題が発生したときにボックスにログインして、情報の収集を開始することです。

実行されているphpプロセスの数を確認するには、次のようなものを実行できるはずです。

ps auxgmww | grep php

そして、自分で数えるのではなく、それらの数を取得したい場合は、次のようにすることができます。

ps auxgmww | grep php | wc -l

パフォーマンスチューニングに関する元の質問に戻ります。syctl.confを変更する前に、問題が発生したときにサーバーから何が通知されているかを確認したい場合は、次のようにしてこれを見つけることができます。

sysctl -a > sysctl.txt

次に、テキストファイルを表示します。これは大量のデータですが、特定の値を調整する前に、sysctlの出力が、その調整可能変数に現在使用しているものと消費しているものについて何か報告していることを確認してください。1つの例は開いているファイルで、ここにサンプル出力を表示できます。

fs.file-nr = 3456   0   102295

これは、3456個のファイル記述子を使用していることを示していますが、上限は102295であるため、上限に近づいていません。最初の数値が100000の範囲にあった場合、それはファイル記述子が不足していることを示しており、それがチューニングに必要なことです。