在繁忙的Django 1.8站点中，由于gunicorn工作者超时而导致出现502个错误：
[“boo”,[1,2,3]]gunicorn。版本 19.9.0
这是我的guniconrn.sh配置
[2019-06-11 04:56:29 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:6550)
[2019-06-11 04:56:31 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:6439)
[2019-06-11 04:56:31 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:7210)
[2019-06-11 04:56:33 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:6429)
[2019-06-11 04:56:46 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:6562)
[2019-06-11 04:59:41 +0000] [6383] [CRITICAL] WORKER TIMEOUT (pid:6560)
该服务器具有128GB的RAM和24核CPU。
通常在负载为+20时发生错误
我从#!/bin/bash
NAME="myapp"
SOCKFILE=/tmp/gunicorn.sock
USER=myuser
GROUP=www-data
NUM_WORKERS=48
DJANGO_SETTINGS_MODULE=myapp.settings
DJANGO_WSGI_MODULE=myapp.wsgi
MAX_REQ=20000
REQ_TIMEOUT=10
LOG_FILE=/var/log/gunicorn/error.log
echo "Starting $NAME as `whoami`"
cd $DJANGODIR
source /home/myuser/.myappenv/bin/activate
export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE
export PYTHONPATH=$DJANGODIR:$PYTHONPATH
# Create the run directory if it doesn't exist
RUNDIR=$(dirname $SOCKFILE)
test -d $RUNDIR || mkdir -p $RUNDIR
exec /home/myuser/.myappenv/bin/gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--user=$USER --group=$GROUP \
--bind=unix:$SOCKFILE \
--log-level=error \
--log-file $LOG_FILE \
--max-requests=$MAX_REQ \
--timeout=$REQ_TIMEOUT
--worker-class="egg:meinheld
# --worker-class=eventlet
--threads=2000`
，NUM_WORKERS，REQ_TIMEOUT和worker-class调整了很多参数。但是似乎没有什么作用。所以我用尽了所有想法，感谢您的提示。
答案 0 :(得分：0)
记录下来，我的问题不是使用gunicorn，而是使用redis，redis被大量用于缓存数据。
当高速缓存增长了数百MB，并且appendfsync everysec处于活动状态时，写入磁盘花费了超过1秒的时间，因此阻止了gunicorn进程。
因此，在将其注释掉并使用appendfsync no保存策略后，问题就消失了。
答案 1 :(得分：0)
您可能需要检查您的应用程序是否可以连接到其数据库（如果适用）。对我来说，我正在云中运行Django REST API，不得不检查数据库服务器上的安全组以允许连接，但Django + Gunicorn部署实际上并没有错。