+200同時接続後のNGINXタイムアウト
これは私のnginx.confです（PHPが関与していないことや他のボトルネックがないことを確認するために設定を更新しました）：
user nginx;
worker_processes 4;
worker_rlimit_nofile 10240;
pid /var/run/nginx.pid;
events
{
worker_connections 1024;
}
http
{
include /etc/nginx/mime.types;
error_log /var/www/log/nginx_errors.log warn;
port_in_redirect off;
server_tokens off;
sendfile on;
gzip on;
client_max_body_size 200M;
map $scheme $php_https { default off; https on; }
index index.php;
client_body_timeout 60;
client_header_timeout 60;
keepalive_timeout 60 60;
send_timeout 60;
server
{
server_name dev.anuary.com;
root "/var/www/virtualhosts/dev.anuary.com";
}
}
私は http://blitz.io/play を使用してサーバーをテストしています（10000の同時接続プランを購入しました）。 30秒の実行で、964ヒットと5,587 timeoutsを取得します。最初のタイムアウトは、同時ユーザー数が200であるテストの40.77秒で発生しました。
テスト中、サーバーの負荷は（top出力）でした：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20225 nginx 20 0 48140 6248 1672 S 16.0 0.0 0:21.68 nginx
1 root 20 0 19112 1444 1180 S 0.0 0.0 0:02.37 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.03 migration/0
したがって、サーバーリソースの問題ではありません。それは何ですか？
UPDATE 2011 12 09 GMT 17:36。
これまでのところ、ボトルネックがTCP/IPではないことを確認するために、次の変更を行いました。 /etc/sysctl.confに追加：
# These ensure that TIME_WAIT ports either get reused or closed fast.
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1
# TCP memory
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096
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
さらにデバッグ情報：
[root@server node]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 126767
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 1024
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
注意worker_rlimit_nofileは10240 nginx設定に設定されています。
UPDATE 2011 12 09 GMT 19:02
変更が多いほど悪くなりますが、ここでは新しい構成ファイルを使用しています。
user nginx;
worker_processes 4;
worker_rlimit_nofile 10240;
pid /var/run/nginx.pid;
events
{
worker_connections 2048;
#1,353 hits, 2,751 timeouts, 72 errors - Bummer. Try again?
#1,408 hits, 2,727 timeouts - Maybe you should increase the timeout?
}
http
{
include /etc/nginx/mime.types;
error_log /var/www/log/nginx_errors.log warn;
# http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/
access_log off;
open_file_cache max=1000;
open_file_cache_valid 30s;
client_body_buffer_size 10M;
client_max_body_size 200M;
proxy_buffers 256 4k;
fastcgi_buffers 256 4k;
keepalive_timeout 15 15;
client_body_timeout 60;
client_header_timeout 60;
send_timeout 60;
port_in_redirect off;
server_tokens off;
sendfile on;
gzip on;
gzip_buffers 256 4k;
gzip_comp_level 5;
gzip_disable "msie6";
map $scheme $php_https { default off; https on; }
index index.php;
server
{
server_name ~^www\.(?P<domain>.+);
rewrite ^ $scheme://$domain$request_uri? permanent;
}
include /etc/nginx/conf.d/virtual.conf;
}
UPDATE 2011 12 11 GMT 20:11
これは、テスト中のnetstat -ntlaの出力です。
https://Gist.github.com/d74750cceba4d08668ea
UPDATE 2011 12 12 GMT 10:54。
明確にするために、テスト中はiptables（ファイアウォール）はオフになっています。
UPDATE 2011 12 12 GMT 22:47
これはsysctl -p | grep memダンプです。
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608
net.ipv4.route.flush = 1
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_max = 8388608
net.core.wmem_default = 65536
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096
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
UPDATE 2011 12 12 GMT 22:49
すべてのテストを実行するためにblitz.ioを使用しています。私がテストしているURLは http://dev.anuary.com/test.txt で、次のコマンドを使用します：--region ireland --pattern 200-250:30 -T 1000 http://dev.anuary.com/test.txt
UPDATE 2011 12 13 GMT 13:33
nginxユーザー制限（/etc/security/limits.confで設定）。
nginx hard nofile 40000
nginx soft nofile 40000
テスト中にネットワーク接続をダンプする必要があります。サーバーの負荷がほとんどない場合でも、TCP/IPスタックが課金されている可能性があります。 netstat出力でTIME_WAIT接続を探します。
この場合は、TCP待機状態、TCPリサイクリング）、および類似のメトリックに関連するtcp/ipカーネルパラメータのチューニングを確認する必要があります。
また、テスト対象を説明していません。
私はいつもテストします：
- 静的コンテンツ（画像またはテキストファイル）
- 単純なphpページ（phpinfoなど）
- アプリケーションページ
これはあなたのケースには当てはまらないかもしれませんが、パフォーマンステストのときに私がすることです。さまざまな種類のファイルをテストすると、ボトルネックを特定するのに役立ちます。
静的コンテンツを使用する場合でも、タイムアウトやその他のメトリックをダイヤルインするには、さまざまなサイズのファイルをテストすることが重要です。
3000以上のアクティブな接続を処理する静的コンテンツNginxボックスがいくつかあります。 Nginxは確かにそれを行うことができます。
更新：netstatは、開いている接続をたくさん示しています。 TCP/IPスタックをチューニングしてみてください。また、どのファイルを要求していますか？ Nginxはすぐにポートを閉じます。
Sysctl.confの提案を次に示します。
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
これらの値は非常に低いですが、同時実行性の高いNginxボックスで成功しました。
Apacheサーバーのアップストリームでロードバランサーとして機能するnginxボックスで非常によく似た問題が発生していました。
私の場合、上流のApacheサーバーが過負荷になったため、ネットワークに関連する問題を特定することができました。システム全体に負荷がかかっているときに、単純なbashスクリプトを使用して再作成できました。ハングしたプロセスの1つのstraceによると、接続呼び出しはETIMEDOUTを取得していました。
これらの設定（nginxおよび上流サーバー上）は私にとって問題を排除しました。これらの変更を行う前に、1分あたり1〜2回のタイムアウトが発生し（ボックスは100リクエスト/秒を処理）、現在は0を取得しています。
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_max_syn_backlog = 20480
net.core.netdev_max_backlog = 4096
net.ipv4.tcp_max_tw_buckets = 400000
net.core.somaxconn = 4096
Net.ipv4.tcp_tw_recycleやnet.ipv4.tcp_tw_reuseを使用することはお勧めしませんが、使用する場合は後者を使用します。レイテンシの種類がまったくなく、後者が少なくとも2つのうち安全である場合、奇妙な問題が発生する可能性があります。
上記のtcp_fin_timeoutを1に設定すると、問題が発生する可能性もあります。 20/30にしてみてください-まだデフォルトをはるかに下回っています。
さらに別の仮説。 worker_rlimit_nofile、ただしクライアントの最大数は ドキュメントで定義 として
max_clients = worker_processes * worker_connections
worker_connectionsに8192のように？または、十分なCPUコアがある場合は、worker_processes？
あなたはblitz.ioでテストしている間、多分nginxの問題ではありません：
tail -f /var/log/php5-fpm.log
（それは私がphpを処理するために使用しているものです）
これによりエラーがトリガーされ、タイムアウトが発生し始めます。
WARNING: [pool www] server reached pm.max_children setting (5), consider raising it
したがって、fmp confにmax_childrenを追加すれば完了です。 ; D
低すぎますmax open files（1024）、nginxを変更して再起動してみてください。 （cat /proc/<nginx>/limits 確認するために）
ulimit -n 10240
そして、worker_connections〜10240以上。