Nginx verimini bir yukarı akış unix soketine yükseltmeniz mi gerekiyor - linux çekirdek ayarı?


28

Bir yukarı akış unix soketine proxy işlevi yapan bir nginx sunucusu çalıştırıyorum, şunun gibi:

upstream app_server {
        server unix:/tmp/app.sock fail_timeout=0;
}

server {
        listen ###.###.###.###;
        server_name whatever.server;
        root /web/root;

        try_files $uri @app;
        location @app {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_pass http://app_server;
        }
}

Bazı uygulama sunucusu işlemleri, sırayla, /tmp/app.sockkullanılabilir olduklarında istekleri geri çeker . Burada kullanılan belirli uygulama sunucusu Unicorn'dur, ancak bunun bu soru ile alakalı olduğunu sanmıyorum.

Mesele şu ki, belli bir yük geçmişinde, nginx soketten yeterince hızlı bir şekilde istek alamıyor gibi görünüyor. Kaç tane uygulama sunucusu işlemi kurduğumun önemi yok.

Nginx hata günlüğünde şu mesajlardan bir sel alıyorum:

connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream

Birçok istek, 502 durum koduyla sonuçlanır ve bu işlemlerin tamamlanması uzun sürmez. Nginx yazma kuyruğu statüsü 1000 civarında.

Her neyse, burada bariz bir şeyi kaçırdığımı hissediyorum, çünkü nginx ve uygulama sunucusunun bu özel yapılandırması, özellikle Unicorn'da oldukça yaygındır (aslında önerilen yöntemdir). Ayarlanması gereken herhangi bir linux çekirdek seçeneği veya nginx'te bir şey var mı? Giriş soketindeki verimi artırma konusunda bir fikriniz var mı? Açıkça yanlış yaptığım bir şey mi?

Çevre hakkında ek bilgi:

$ uname -a
Linux servername 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64 GNU/Linux

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

$ unicorn -v
unicorn v4.3.1

$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled

Güncel çekirdek tweaks:

net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288

Nginx kullanıcısı için Ulimit ayarları:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

ulimitÖzellikle açık dosyaların sayısını kontrol ettiniz mi?
Khaled

@Khaled, ulimit -ndiyor 65535.
Ben Lee

Yanıtlar:


16

Darboğaz gibi geliyor Giden Nginx olmak yerine sokete güç veren uygulama. TCP / IP bağlantısına karşı soketlerle kullanıldığında PHP ile çok şey görüyoruz. Bizim durumumuzda, PHP darboğazları Nginx'in şimdiye kadar beklediğinden daha erken.

Sysctl.conf bağlantı izleme limitini, soket backlog limitini kontrol ettiniz mi?

  • net.core.somaxconn
  • net.core.netdev_max_backlog

2
Sorunu çözdüm. Gönderdiğim cevaba bakın. Aslında oldu sen varsaymak gibi, uygulama darboğazla değil soket. Yanlış tanılama nedeniyle bunu daha önce ekarte etmiştim, ancak sorunun başka bir sunucuya verilmediği ortaya çıktı. Bunu birkaç saat önce anladım. Size bu ödülü vereceğim, çünkü soruyu yanlış tanımaya rağmen sorunun kaynağını çok çivilediniz; bununla birlikte, cevabımı onay işareti olarak vereceğim, çünkü cevabım kesin koşulları açıklıyor, böylece gelecekte benzer bir konuda birisine yardımcı olabilir.
Ben Lee,

Yeterli verim sağlayacak yeni bir sunucuya taşınmış, sistemi tamamen yeniden inşa etmiş ve hala aynı sorunu yaşıyor. Sonuçta sorunum çözülmedi, sonuçta ... = (Hala uygulamaya özel olduğunu düşünüyorum, ancak hiçbir şey düşünemiyorum. Bu yeni sunucu tam olarak iyi çalıştığı başka bir sunucu gibi kuruluyor. Evet, somaxconn ve netdev_max_backlog doğru ayarlandı
Ben Lee

Sorununuz nginx değil, yetenekli olmaktan öte bir şey; ancak bu, hileli bir ayarınız olmadığı anlamına gelmiyor. Limitler doğru yapılandırılmadığında soketler özellikle yüksek yük altında hassastır. Uygulamanızı bunun yerine tcp / ip ile deneyebilir misiniz?
Ben Lessani - Sonassi

tcp / ip kullanarak daha da kötü bir boyutta bile aynı sorun (yazma kuyruğu daha hızlı tırmanıyor). Nginx / unicorn / kernel'im farklı bir makinede tamamen aynı şekilde ayarlandı (söyleyebildiğim kadarıyla) ve diğer makinede bu sorunu göstermiyor. (Canlı yük testi için iki makine arasında dns değiştirebilirim ve 60 saniyelik bir ttl'de dns yapabilirim)
Ben Lee

Her makine ve bir db makine arasındaki verim şimdi aynıdır ve yeni makine ile db makine arasındaki gecikme eski makine ve db arasında olduğundan yaklaşık% 30 daha fazladır. Ancak% 30 daha fazla bir milisaniyenin onda biri sorun değil.
Ben Lee,

2

Bakmayı deneyebilirsin unix_dgram_qlen, proc belgelerine bak . Her ne kadar bu sırada kuyrukta daha fazla işaret ederek sorunu artırabilir mi? Bakmanız gerekecek (netstat -x ...)


Bununla ilgili herhangi bir gelişme var mı?
jmw

1
Fikir için teşekkürler, ama bu herhangi bir fark yaratmadı.
Ben Lee

0

Config / unicorn.rb içindeki backlog sayısını artırarak çözdüm ... 64 backlog kullanıyordum.

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 64

ve ben bu hatayı alıyordum:

 2014/11/11 15:24:09 [error] 12113#0: *400 connect() to unix:/path/tmp/sockets/manager_rails.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.101.39, server: , request: "GET /welcome HTTP/1.0", upstream: "http://unix:/path/tmp/sockets/manager_rails.sock:/welcome", host: "192.168.101.93:3000"

Şimdi, 1024'e yükselttim ve hatayı anlamadım:

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 1024

0

tl; Dr.

  1. Unicorn backlog'unun büyük olduğundan emin olun (soket kullanın, TCP'den hızlı) listen("/var/www/unicorn.sock", backlog: 1024)
  2. Örneğin, NGINX performans ayarlarını optimize edinworker_connections 10000;

Tartışma

Aynı problemi yaşadık - Unicorn tarafından NGINX ters proxy sunucusunun arkasında sunulan bir Rails uygulaması.

Nginx hata günlüğünde bunun gibi satırlar alıyorduk:

2019/01/29 15:54:37 [error] 3999#3999: *846 connect() to unix:/../unicorn.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: xx.xx.xx.xx, request: "GET / HTTP/1.1"

Diğer cevapları okuyarak belki Unicorn'un suçlanabileceğini de düşündük, bu yüzden onun birikimini arttırdık, ancak bu sorunu çözmedi. Sunucu işlemlerinin izlenmesi Unicorn'un çalışma isteklerini yerine getirmediği açıktı, bu nedenle NGINX darboğaz olarak göründü.

nginx.confBu performans ayarlama makalesinde ince ayar yapmak için NGINX ayarlarının aranması , özellikle NGINX'in kaç paralel isteği işleyebileceğini etkileyebilecek birkaç ayar olduğuna dikkat çekti:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 400000; # important

events {    
  worker_connections 10000; # important
  use epoll; # important
  multi_accept on; # important
}

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  keepalive_requests 100000; # important
  server_names_hash_bucket_size 256;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;
  gzip on;
  gzip_disable "msie6";
  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.