+200 eşzamanlı bağlantıdan sonra NGINX zaman aşımı

Bu benim nginx.conf(PHP dahil veya başka herhangi bir darboğaz olmadığından emin olmak için yapılandırmayı güncelledim):

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

Sunucumu test etmek için http://blitz.io/play kullanıyorum (10.000 eşzamanlı bağlantı planını satın aldım). 30 saniyede koştuğumda 964isabet alırım 5,587 timeouts. İlk zaman aşımı, eşzamanlı kullanıcı sayısı 200 iken teste 40,77 saniyede gerçekleşti.

Test sırasında sunucu yükü ( topçıktı):

 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      

Bu nedenle, sunucu kaynak sorunu değildir. Öyleyse nedir?

GÜNCELLEME 2011 12 09 GMT 17:36.

Şimdiye kadar, darboğazın TCP / IP olmadığından emin olmak için aşağıdaki değişiklikleri yaptım. Eklenme tarihi /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

Bazı hata ayıklama bilgileri:

[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 Bu nginx config worker_rlimit_nofileolarak ayarlanmıştır 10240.

GÜNCELLEME 2011 12 09 GMT 19:02.

Ne kadar çok değişiklik yaparsam o kadar kötüleşir, ama burada yeni yapılandırma dosyası.

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

GÜNCELLEME 2011 12 11 GMT 20:11.

Bu netstat -ntlatest sırasında çıktıdır .

https://gist.github.com/d74750cceba4d08668ea

GÜNCELLEME 2011 12 12 GMT 10:54.

Açıklığa kavuşturmak için, iptablestest sırasında (güvenlik duvarı) kapalıdır.

GÜNCELLEME 2011 12 12 GMT 22:47.

Bu sysctl -p | grep memçöplük.

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

GÜNCELLEME 2011 12 12 GMT 22:49

blitz.ioTüm testleri yapmak için kullanıyorum . Test ettiğim URL şu komutu kullanarak http://dev.anuary.com/test.txt şeklindedir :--region ireland --pattern 200-250:30 -T 1000 http://dev.anuary.com/test.txt

GÜNCELLEME 2011 12 13 GMT 13:33

nginxkullanıcı sınırları (belirlenmiş /etc/security/limits.conf).

nginx       hard nofile 40000
nginx       soft nofile 40000

Test sırasında ağ bağlantılarınızı boşaltmanız gerekir. Sunucu sıfıra yakın yüke sahip olsa da, TCP / IP yığınınız faturalandırılıyor olabilir. Bir netstat çıkışında TIME_WAIT bağlantılarını arayın.

Bu durumda, TCP Bekleme durumları, TCP geri dönüşümü ve benzer metriklerle ilgili tcp / ip çekirdek parametrelerini ayarlamayı kontrol etmek isteyeceksiniz.

Ayrıca, neyin test edildiğini açıklamamışsınızdır.

Her zaman test ederim:

• statik içerik (resim veya metin dosyası)
• basit php sayfası (örneğin phpinfo)
• uygulama sayfası

Bu sizin durumunuz için geçerli olmayabilir, ancak performans testi yaparken yaptığım bir şeydir. Farklı dosya türlerini test etmek, tıkanıklığı belirlemenize yardımcı olabilir.

Statik içerikle bile, zaman aşımlarını ve diğer metrikleri çevirmek için farklı dosya boyutlarını test etmek de önemlidir.

3000'den fazla aktif bağlantıyı işleyen bazı statik içerik Nginx kutularımız var. Böylece Nginx kesinlikle yapabilir.

Güncelleme: netstat'ınız birçok açık bağlantı gösteriyor. TCP / IP yığınınızı ayarlamayı denemek isteyebilirsiniz. Ayrıca, hangi dosyayı talep ediyorsunuz? Nginx bağlantı noktasını hızla kapatmalıdır.

İşte sysctl.conf için bir öneri:

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

Bu değerler çok düşük ama yüksek eşzamanlı Nginx kutularında onlarla başarılı oldum.

Yine başka bir hipotez. Sen arttı worker_rlimit_nofile, ancak istemcilerin sayısı olduğu belgelerinde tanımlandığı şekilde

max_clients = worker_processes * worker_connections

worker_connections8192'ye yükselmeye çalışırsanız ne olur ? Veya yeterli CPU çekirdeği varsa, artış worker_processesmı?

Apache sunucuları yukarı akış ile yük dengeleyici olarak hizmet veren bir nginx kutusu ile çok benzer bir sorun yaşıyordu.

Benim durumumda, yukarı akış apache sunucuları aşırı hale geldikçe ağla ilgili sorunu izole edebildim. Genel sistem yük altındayken basit bash komut dosyalarıyla yeniden oluşturabilirim. Asılı işlemlerden birinin sıkıntısına göre bağlantı çağrısı bir ETIMEDOUT alıyordu.

Bu ayarlar (nginx ve upstream sunucularda) benim için sorunu ortadan kaldırdı. Bu değişiklikleri yapmadan önce dakikada 1 veya 2 zaman aşımı alıyordum (kutular ~ 100 reqs / s) ve şimdi 0 alıyorum.

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 veya net.ipv4.tcp_tw_reuse kullanmanızı tavsiye etmem, ancak ikincisini kullanmak istiyorsanız. Herhangi bir gecikme varsa ve ikincisi en azından ikisinin daha güvenli olması durumunda tuhaf sorunlara neden olabilirler.

Yukarıdaki 1 için ayarlanan tcp_fin_timeout olması da bazı sorunlara neden olabilir düşünüyorum. 20 / 30'a koymayı deneyin - hala varsayılanın çok altında.

blitz.io üzerinde test yaparken belki nginx sorunu değil:

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

(bu php işlemek için ne kullanıyorum)

bu bir hatayı tetikler ve zaman aşımları artmaya başlar:

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

yani, daha fazla max_children fmp conf koymak ve bitti! D

Çok düşük max open files(1024) var, değiştirmeyi deneyin ve nginx'i yeniden başlatın. ( cat /proc/<nginx>/limitsonaylamak için)

ulimit -n 10240

Ve worker_connections10240 veya daha yükseğe yükseltin .