Batas waktu NGINX setelah +200 koneksi bersamaan

Ini adalah nginx.conf(konfigurasi saya telah saya perbarui untuk memastikan bahwa tidak ada PHP yang terlibat atau hambatan lainnya):

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";
    }
}

Saya menggunakan http://blitz.io/play untuk menguji server saya (saya membeli 10 000 paket koneksi bersamaan). Dalam 30 detik berjalan, saya mendapatkan 964hit dan 5,587 timeouts. Waktu tunggu pertama terjadi pada 40,77 detik saat pengujian ketika jumlah pengguna bersamaan adalah 200.

Selama pengujian, beban server adalah ( topkeluaran):

 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      

Oleh karena itu bukan masalah sumber daya server. Lalu apa itu?

UPDATE 2011 12 09 GMT 17:36.

Sejauh ini saya melakukan perubahan berikut untuk memastikan bahwa bottleneck bukan TCP / IP. Ditambahkan ke /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

Beberapa info debug lainnya:

[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 Itu worker_rlimit_nofilediatur ke 10240nginx config.

UPDATE 2011 12 09 GMT 19:02.

Sepertinya semakin banyak perubahan yang saya lakukan, semakin buruk, tetapi di sini file konfigurasi baru.

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.

Ini adalah output netstat -ntlaselama tes.

https://gist.github.com/d74750cceba4d08668ea

UPDATE 2011 12 12 GMT 10:54.

Hanya untuk memperjelas, iptables(firewall) tidak aktif saat pengujian.

UPDATE 2011 12 12 GMT 22:47.

Ini adalah sysctl -p | grep memdump.

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

Saya menggunakan blitz.iountuk menjalankan semua tes. URL yang saya uji adalah http://dev.anuary.com/test.txt , menggunakan perintah berikut:--region ireland --pattern 200-250:30 -T 1000 http://dev.anuary.com/test.txt

UPDATE 2011 12 13 GMT 13:33

nginxbatas pengguna (setel /etc/security/limits.conf).

nginx       hard nofile 40000
nginx       soft nofile 40000

Anda perlu membuang koneksi jaringan Anda selama pengujian. Meskipun server mungkin memiliki muatan mendekati nol, tumpukan TCP / IP Anda dapat ditagih. Cari koneksi TIME_WAIT dalam output netstat.

Jika ini masalahnya, maka Anda perlu memeriksa ke menyetel parameter kernel tcp / ip yang berkaitan dengan status TCP Wait, recyling TCP, dan metrik serupa.

Anda juga belum menjelaskan apa yang sedang diuji.

Saya selalu menguji:

• konten statis (gambar atau file teks)
• halaman php sederhana (misalnya phpinfo)
• halaman aplikasi

Ini mungkin tidak berlaku dalam kasus Anda tetapi sesuatu yang saya lakukan saat pengujian kinerja. Menguji berbagai jenis file dapat membantu Anda menentukan bottlneck.

Bahkan dengan konten statis, pengujian ukuran file yang berbeda juga penting untuk mendapatkan batas waktu dan metrik lainnya yang dihubungi.

Kami memiliki beberapa kotak Nginx konten statis yang menangani 3000+ koneksi aktif. Jadi itu Nginx pasti bisa melakukannya.

Pembaruan: Netstat Anda menunjukkan banyak koneksi terbuka. Mungkin ingin mencoba menyetel tumpukan TCP / IP Anda. Juga, file apa yang Anda minta? Nginx harus segera menutup port.

Berikut ini adalah saran untuk 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

Nilai-nilai ini sangat rendah tetapi saya telah berhasil dengan mereka di kotak Nginx concurrency tinggi.

Namun hipotesis lain. Anda telah meningkat worker_rlimit_nofile, tetapi jumlah maksimum klien didefinisikan dalam dokumentasi sebagai

max_clients = worker_processes * worker_connections

Bagaimana jika Anda mencoba menaikkan worker_connectionske, seperti, 8192? Atau, jika jumlah core CPU cukup, tambah worker_processes?

Saya mengalami masalah yang sangat mirip dengan kotak nginx yang berfungsi sebagai penyeimbang beban dengan server apache hulu.

Dalam kasus saya, saya dapat mengisolasi masalah yang terkait dengan jaringan karena server apache upstream menjadi kelebihan beban. Saya bisa membuatnya kembali dengan skrip bash sederhana sementara sistem keseluruhan sedang dimuat. Menurut sebuah strace dari salah satu proses yang digantung, panggilan connect mendapatkan sebuah ETIMEDOUT.

Pengaturan ini (pada server nginx dan upstream) menghilangkan masalah bagi saya. Saya mendapatkan 1 atau 2 batas waktu per menit sebelum melakukan perubahan ini (kotak menangani ~ 100 reqs / s) dan sekarang mendapatkan 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

Saya tidak akan merekomendasikan menggunakan net.ipv4.tcp_tw_recycle atau net.ipv4.tcp_tw_reuse, tetapi jika Anda ingin menggunakan yang satu pergi dengan yang terakhir. Mereka dapat menyebabkan masalah aneh jika ada jenis latensi sama sekali dan yang terakhir setidaknya lebih aman dari keduanya.

Saya pikir memiliki tcp_fin_timeout yang diatur ke 1 di atas dapat menyebabkan masalah juga. Coba letakkan di 20/30 - masih jauh di bawah standar.

mungkin bukan masalah nginx, saat Anda menguji pada blitz.io lakukan:

tail -f /var/log/php5-fpm.log

(Itulah yang saya gunakan untuk menangani php)

ini memicu kesalahan dan batas waktu mulai naik:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

jadi, tambah max_children di conf fmp dan selesai! ; D

Anda memiliki terlalu rendah max open files(1024), coba ubah dan mulai ulang nginx. ( cat /proc/<nginx>/limitsuntuk mengkonfirmasi)

ulimit -n 10240

Dan meningkat worker_connectionsmenjadi 10240 atau lebih tinggi.