gunicorn + django + nginx unix: // soquete falhou (11: Recurso temporariamente indisponível)

Question

Executando tráfego de muito alto volume nesses servidores configurados com django, gunicorn, supervisor e nginx. Mas muitas vezes eu vejo erros no 502. Então eu chequei os logs nginx para ver qual erro e isso é o que está registrado:

[error] 2388#0: *208027 connect() to unix:/tmp/gunicorn-ourapp.socket failed (11: Resource temporarily unavailable) while connecting to upstream

Alguém pode ajudar a depurar o que pode estar causando isso?

Esta é a nossa configuração nginx:

sendfile on;
tcp_nopush on;
tcp_nodelay off;

listen 80 default_server;
server_name imp.ourapp.com;
access_log /mnt/ebs/nginx-log/ourapp-access.log;
error_log /mnt/ebs/nginx-log/ourapp-error.log;

charset utf-8;
keepalive_timeout 60;
client_max_body_size 8m;

gzip_types text/plain text/xml text/css application/javascript application/x-javascript application/json;

location / {
    proxy_pass http://unix:/tmp/gunicorn-ourapp.socket;
    proxy_pass_request_headers on;
    proxy_read_timeout 600s;
    proxy_connect_timeout 600s;
    proxy_redirect http://localhost/ http://imp.ourapp.com/;
    #proxy_set_header Host              $host;
    #proxy_set_header X-Real-IP         $remote_addr;
    #proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    #proxy_set_header X-Forwarded-Proto $my_scheme;
    #proxy_set_header X-Forwarded-Ssl   $my_ssl;
}

Nós configuramos o Django para rodar em Gunicorn como um aplicativo WSGI genérico. O Supervisord é usado para lançar os trabalhadores do gunicorn:

home/user/virtenv/bin/python2.7 /home/user/virtenv/bin/gunicorn --config /home/user/shared/etc/gunicorn.conf.py daggr.wsgi:application

Isto é o que o arquivo gunicorn.conf.py se parece com:

import multiprocessing

bind = 'unix:/tmp/gunicorn-ourapp.socket'
workers = multiprocessing.cpu_count() * 3 + 1
timeout = 600
graceful_timeout = 40

Alguém sabe onde eu posso começar a cavar para ver o que pode estar causando o problema?

Esta é a aparência da minha saída ulimit -a no servidor:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 59481
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 50000
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) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

    

Answer 1

Consegui contornar esse problema editando /proc/sys/net/core/somaxconn de 128 para 20.000. Isso permite maiores transbordamentos de tráfego. Eu posso não ter precisado defini-lo tão alto, mas esse aplicativo pode explodir muito alto. Eu também estou usando gunicorn & nginx.

    

Answer 2

No meu caso, esse erro foi causado por minha configuração de gunicorn:

worker_class = "sync"

Que eu consertei usando:

worker_class = "gevent" # "sync"

    

Answer 3

Consegui reproduzir este problema com este exemplo: link

Aumentar o net.core.somaxconn acabou consertando.

Se não for um contêiner docker, você pode fazer isso com sysctl -w net.core.somaxconn=<your value> . Se for um contêiner docker, você poderá usar esse sinalizador: --sysctl net.core.somaxconn=1024

    

Answer 4

Parece que isso seria causado porque todos os trabalhadores do gunicorn estão em uso. Eu temporariamente ligaria o loggin em gunicorn. Veja as configurações de registro aqui . Isso deve permitir que você veja o estado dos trabalhadores do gunicorn e por que uma nova conexão não pode ser feita no momento em que o 502 acontece.