Как отладить Gunicorn [6383] [КРИТИЧЕСКИЙ] РАБОЧИЙ ВРЕМЯ? - PullRequest
Новая
       9

Как отладить Gunicorn [6383] [КРИТИЧЕСКИЙ] РАБОЧИЙ ВРЕМЯ?

0 голосов
/ 11 июня 2019

На моем загруженном сайте Django 1.8 я получаю множество ошибок 502 из-за тайм-аута работника Gunicorn: 

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

Сервер имеет 128 ГБ оперативной памяти и 24-ядерный процессор.

Ошибка обычно возникает, когда нагрузка + 20

Я настроил множество параметров из NUM_WORKERS, REQ_TIMEOUT, worker-class и threads. Но ни один из них, кажется, не имеет большого эффекта. Поэтому у меня закончились идеи, и я ценю ваши намеки.

1 Ответ

0 голосов
/ 14 июня 2019

Для справки, моя проблема была не с gunicorn, а с redis, который интенсивно используется для кэширования данных.

Поскольку кэш-память выросла на несколько сотен МБ, а appendfsync everysec был активен, запись на диск заняла более 1 секунды, что привело к блокировке процессов Gunicorn.Так что после комментирования и использования appendfsync no политики сохранения проблема исчезла.

...