Configuré gunicornio con 3 trabajadores 30 conexiones de trabajador y uso de clase de trabajador eventlet. Está configurado detrás de Nginx. Después de cada pocas solicitudes, veo esto en los registros.Error de tiempo de espera de trabajador de Gunicorn
[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514
¿Por qué ocurre esto? ¿Cómo puedo averiguar qué está yendo mal?
gracias
Run Gunicorn con --log-level=DEBUG.
Debe darle un seguimiento de la pila de la aplicación.
No es mi caso. – Joe
ahora es '--log-level debug' – psychok7
Me encantaría obtener una stracktrace, pero ninguna de ellas funciona aquí, usando gunicorn 19.4.5. Se muestra material de depuración, así que supongo que se reconoció el indicador, pero no stacktrace en tiempo de espera. – orzel
¿Podría ser esto? http://docs.gunicorn.org/en/latest/settings.html#timeout
Otras posibilidades podrían ser que su respuesta demore demasiado o que esté esperando.
Esta URL ahora es http://docs.gunicorn.org/en/latest/settings.html#timeout – JasonB
Necesitas utilizado otro tipo de clase trabajadora una asíncrono uno como GEvent o tornado ver esto para más información: Primera explantion:
También es posible que desee instalar Eventlet o GEvent si espera que su código de aplicación puede necesitar para hacer una pausa durante largos períodos de tiempo durante el procesamiento de la solicitud
segunda:
Los trabajadores síncronos predeterminados asumen que su aplicación está vinculada a recursos en términos de CPU y ancho de banda de red. En general, esto significa que su aplicación no debe hacer nada que lleve un tiempo indefinido. Por ejemplo, una solicitud a internet cumple este criterio. En algún momento, la red externa fallará de tal forma que los clientes se acumularán en sus servidores.
Tuvimos el mismo problema al usar Django + nginx + gunicorn. De la documentación de Gunicorn hemos configurado el elegante tiempo de espera que casi no hizo diferencia.
Después de algunas pruebas, encontramos la solución, el parámetro para configurar es: timeout (Y no elegante timeout). Funciona como un reloj ..
Así, Do:
1) abrir el fichero de configuración gunicorn
2) establecer el tiempo a lo que usted necesita - el valor está en segundo
NUM_WORKERS=3
TIMEOUT=120
exec gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE
Gracias, esta es la respuesta correcta. Y luego, para ahorrar recursos con muchas conexiones simultáneas: 'pip install gevent' , luego' worker_class gevent' en su archivo de configuración o '-k gevent' en la línea de comandos. –
usando gevent resuelve mi problema. – LiberiFatali
tuve problema muy similar, también intentado usar "de ejecución del servidor" para ver si podía encontrar nada, pero todo lo que tenía era un mensaje Killed
Así que t Pensé que podría ser un problema de recursos, y me adelanté a dar más RAM a la instancia, y funcionó.
Estaba viendo este problema incluso con gevent y el tiempo de espera configurado correctamente, el problema era la falta de memoria – bcattle
En Google Cloud Sólo tiene que añadir --timeout 90 al punto de entrada en app.yaml
entrypoint: gunicorn -b :$PORT main:app --timeout 90
que fueron capaces de resolver el problema? Por favor, comparta sus ideas ya que también me quedé con eso. 'Gunicorn == 19.3.1' y' gevent == 1.0.1' –
Encontré la solución para ello. Aumentó el tiempo de espera a un valor muy grande y luego pude ver el seguimiento de pila –