Запуск очень большого объема трафика на этих серверах, настроенных с помощью 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.