+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      

したがって、サーバーリソースの問題ではありません。それは何ですか？

更新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

NBそれworker_rlimit_nofileは10240nginxの設定に設定されています。

更新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;
}

更新2011 12 11 GMT 20:11。

これはnetstat -ntla、テスト中の出力です。

https://gist.github.com/d74750cceba4d08668ea

2011年12月12日GMT 10:54更新。

明確にするために、iptablesテスト中は（ファイアウォール）はオフになっています。

更新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

更新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

更新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ボックスで成功しています。

さらに別の仮説。を増やしましたworker_rlimit_nofileが、クライアントの最大数はドキュメントで次のように定義されています

max_clients = worker_processes * worker_connections

worker_connections8192 にレイズしようとした場合はどうなりますか？または、十分なCPUコアがある場合、増やしworker_processesますか？

Apacheサーバーのアップストリームでロードバランサーとして機能するnginxボックスで、非常によく似た問題を抱えていました。

私の場合、アップストリームのapacheサーバーが過負荷になったため、ネットワーク関連の問題を切り分けることができました。システム全体に負荷がかかっているときに、単純なbashスクリプトで再作成できました。ハングしたプロセスの1つの痕跡によると、接続呼び出しはETIMEDOUTを取得していました。

これらの設定（nginxおよびアップストリームサーバー）は、問題を解決しました。これらの変更を行う前に、1分間に1つまたは2つのタイムアウトが発生していました（ボックスは100リクエスト/秒を処​​理します）。

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に設定してみてください-デフォルトよりはるかに低いです。

多分nginxの問題ではありませんが、blitz.ioでテストします：

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以上に増やします。