如何调试 gunicorn [6383] [CRITICAL] 工作人员超时？答案

【问题标题】：How to debug gunicorn [6383] [CRITICAL] WORKER TIMEOUT?如何调试 gunicorn [6383] [CRITICAL] 工作人员超时？
【发布时间】：2020-12-02 02:37:24
【问题描述】：

在我繁忙的 Django 1.8 站点中，由于 gunicorn worker 超时，我收到大量 502 错误：

[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)

gunicorn.版本 19.9.0

这是我的 guniconrn.sh 配置

#!/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`

服务器有 128GB 的 RAM 和 24 核 CPU。

错误通常发生在负载为+20时

我从NUM_WORKERS、REQ_TIMEOUT、worker-class 和threads 调整了很多参数。但似乎没有一个有太大的影响。所以我的想法已经用完了，感谢您的提示。

【问题讨论】：

您的应用程序可能无法及时响应请求。你看过你的 django 日志吗？
@Stargazer which django 记录？
您的应用程序日志。您将请求时间定义为 10 秒，根据您的观点，这可能会非常短。
好吧，之前我尝试过REQ_TIMEOUT=120，但仍然有很多超时。
这就是为什么您需要检查您的观点为什么请求需要这么长时间才能完成。这几乎不是 gunicorn 的错

标签： django gunicorn

【解决方案1】：

为了记录，我的问题不是 gunicorn，而是 redis，它大量用于缓存数据。

随着缓存增长数百 MB，并且appendfsync everysec 处于活动状态，写入磁盘需要超过 1 秒的时间，因此阻塞了 gunicorn 进程。因此，在将其注释掉并改用 appendfsync no 保存策略之后，问题就消失了。

【讨论】：

我刚刚发现我的问题是由 LOGGING 引起的。总是值得一试。
@andyhasit 你能详细说明一下吗？
@amro_ghoneim 老实说，我不记得为什么要添加此评论，以及为什么要大写。如果 gunicorn 无法写入日志文件，您将收到 502，因为目录不存在，或者进程没有权限。可能是redis无法写入日志文件，由于超时而报504。

【解决方案2】：

如果适用，您可能需要检查您的应用是否可以连接到其数据库。对我来说，我在云中运行 Django REST API，必须检查数据库服务器上的安全组以允许连接，但 Django+Gunicorn 部署实际上并没有错。

【讨论】：

深呼吸一样。他们没有抛出错误/异常，而是超时。我快疯了。