gunicorn + django + nginx unix:// сокет не удалось (11: ресурс временно недоступен)

Выполнение очень большого объема трафика на этих серверах, настроенных с помощью django, gunicorn, supervisor и nginx. Но часто я вижу 502 ошибки. Поэтому я проверил логи nginx, чтобы увидеть, что за ошибка, и вот что записано:

[ошибка] 2388#0: *208027 connect() для unix:/tmp/gunicorn-ourapp.socket не удалось (11: ресурс временно недоступен) при подключении к восходящему каналу

Может кто-нибудь помочь отладить, что может быть причиной этого?

Это наша конфигурация 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;
}

Мы настроили Django для запуска в Gunicorn как универсальное приложение WSGI. Supervisord используется для запуска оружейных рабочих:

home / user / virtenv / bin / python2.7 / home / user / virtenv / bin / gunicorn --config /home/user/shared/etc/gunicorn.conf.py daggr.wsgi: приложение

Вот как выглядит gunicorn.conf.py:

import multiprocessing

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

Кто-нибудь знает, где я могу начать копать, чтобы увидеть, что может быть причиной проблемы?

Вот как мой вывод 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) 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

4 ответа

Я смог обойти эту проблему путем редактирования /proc/sys/net/core/somaxconn от 128 до 20000. Это позволяет большие всплески трафика. Возможно, мне не нужно было устанавливать его так высоко, но это приложение может взорваться очень высоко. Я также использую Gunicorn & Nginx.

В моем случае эта ошибка была из-за моей конфигурации gunicorn:

worker_class = "sync"

Что я исправил с помощью:

worker_class = "gevent" # "sync"

Мне удалось воспроизвести эту проблему в следующем примере: https://github.com/pawl/somaxconn_test

Увеличение net.core.somaxconn в конечном итоге это исправить.

Если это не докер-контейнер, вы можете сделать это с sysctl -w net.core.somaxconn=<your value>, Если это Docker-контейнер, вы можете использовать этот флаг: --sysctl net.core.somaxconn=1024

Звучит так, как будто бы это вызвано тем, что все рабочие-оружейники используются. Я бы временно включил логин в gunicorn. Смотрите настройки регистрации здесь. Это должно позволить вам увидеть состояние рабочих-оружейников и почему новое соединение не может быть установлено во время 502.

Другие вопросы по тегам