Назад | Перейти на главную страницу

gunicorn + django + nginx unix: // socket failed (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. Супервайзер используется для запуска рабочих-пулеметчиков:

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

Вот как выглядит файл 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

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

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

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

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

worker_class = "синхронизация"

Что я исправил, используя:

worker_class = "gevent" # "синхронизация"

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

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