Vraag Nginx doorvoer naar een upstream unix socket - linux kernelafstemming verhogen?


Ik run een nginx-server die fungeert als een proxy voor een upstream-unix-socket, zoals deze:

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

Sommige app-serverprocessen trekken beurtelings aanvragen af /tmp/app.sock zodra ze beschikbaar zijn. De specifieke app-server die hier wordt gebruikt, is Unicorn, maar ik denk niet dat dit relevant is voor deze vraag.

Het probleem is, het lijkt alleen dat een bepaalde hoeveelheid belasting voorbij is, nginx kan niet snel genoeg aanvragen via de socket ontvangen. Het maakt niet uit hoeveel app-serverprocessen ik heb ingesteld.

Ik krijg een stortvloed van deze berichten in het nginx-foutenlogboek:

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

Veel verzoeken resulteren in statuscode 502 en die vragen die niet lang duren om te voltooien. De statische nginx-wachtrij schommelt rond de 1000.

Hoe dan ook, ik heb het gevoel dat ik hier iets duidelijk mis, omdat deze specifieke configuratie van nginx en app-server vrij algemeen is, vooral met Unicorn (het is in feite de aanbevolen methode). Zijn er Linux-kernelopties die moeten worden ingesteld of iets in Nginx? Enig idee over hoe de doorvoer naar de stroomopwaartse contactdoos te vergroten? Iets dat ik duidelijk verkeerd doe?

Aanvullende informatie over de omgeving:

$ 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

Huidige kernel 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

Ulimit-instellingen voor de nginx-gebruiker:

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

24
2018-06-14 22:46


oorsprong


Heb je de uitvoer gecontroleerd van ulimit, specifiek aantal open bestanden? - Khaled
@Khaled, ulimit -n zegt 65535. - Ben Lee


antwoorden:


Het lijkt erop dat het knelpunt is dat de app de socket van stroom voorziet in plaats van dat het Nginx zelf is. We zien dit veel met PHP wanneer gebruikt met sockets versus een TCP / IP-verbinding. In ons geval zouden PHP-knelpunten veel eerder dan Nginx ooit al hebben.

Hebt u de sysctl.conf-limiet voor het volgen van verbindingen gecontroleerd, de limiet voor het blokkeren van de socket

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

15
2018-06-20 20:05



Ik heb het probleem ontdekt. Zie het antwoord dat ik heb gepost. Het eigenlijk was de bottlenecking van de app, niet de socket, net zoals jij stelt. Ik had dit eerder uitgesloten vanwege een verkeerde diagnose, maar het probleem bleek de doorvoer naar een andere server te zijn. Ik heb dit een paar uur geleden al uitgevonden. Ik ga je de premie toekennen, omdat je vrijwel de oorzaak van het probleem hebt genageld, ondanks de verkeerde diagnose die ik in de vraag stelde; echter, ik ga het vinkje geven bij mijn antwoord, omdat mijn antwoord de exacte omstandigheden beschrijft, dus misschien iemand in de toekomst helpen met een soortgelijk probleem. - Ben Lee
Ik heb een nieuwe server laten verhuizen naar een locatie om voldoende doorvoer te bieden, het systeem volledig opnieuw te bouwen en nog steeds hetzelfde probleem te hebben. Dus het blijkt dat mijn probleem tenslotte onopgelost is ... = (ik denk nog steeds dat het app-specifiek is, maar kan niets bedenken.) Deze nieuwe server is precies zo opgezet als een andere server waar het prima werkt. netdev_max_backlog zijn correct. - Ben Lee
Uw probleem is niet nginx, het is meer dan capabel - maar dat wil niet zeggen dat u misschien geen malafide instelling hebt. Sockets zijn bijzonder gevoelig bij hoge belasting wanneer de limieten niet correct zijn geconfigureerd. Kun je in plaats daarvan je app met tcp / ip proberen? - Ben Lessani - Sonassi
hetzelfde probleem met zelfs een slechtere omvang met behulp van TCP / IP (schrijfrij stijgt nog sneller). Ik heb nginx / unicorn / kernel allemaal exact hetzelfde opgezet (voor zover ik kan zien) op een andere machine en die andere machine vertoont dit probleem niet. (Ik kan dns schakelen tussen de twee machines om live load-testen te krijgen, en heb dns op een 60-sec ttl) - Ben Lee
De doorvoer tussen elke machine en een db-machine is nu hetzelfde, en de latentie tussen de nieuwe machine en db-machine is ongeveer 30% meer dan tussen de oude machine en db. Maar 30% meer dan een tiende milliseconde is niet het probleem. - Ben Lee


Je zou kunnen proberen om naar te kijken unix_dgram_qlen, zien proc docs. Hoewel dit het probleem kan vergroten door meer in de wachtrij te zetten? Je zult moeten kijken (netstat -x ...)


2
2018-06-17 01:53



Enige vooruitgang hiermee? - jmw
Bedankt voor het idee, maar dit leek geen enkel verschil te maken. - Ben Lee


Ik loste het op door het aantal reserveorders in de config / unicorn.rb te verhogen ... Ik had een achterstand van 64.

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

en ik kreeg deze foutmelding:

 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"

Nu ben ik gestegen naar 1024 en krijg ik de fout niet:

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

0
2017-11-11 15:39





achterstand standaardwaarde is 1024 in eenhoorn config.

http://unicorn.bogomips.org/Unicorn/Configurator.html

listen "/path/to/.unicorn.sock", :backlog => 1024

1024-client is een unix domein socketlimiet.


-1
2017-09-29 15:02