7 votos

Apache/wsgi de secuencia de Comandos "tiempo de espera agotado antes de regresar encabezados"

Tengo una costumbre Django app que hace que no responda aproximadamente cada 5.000 solicitudes. En los logs de apache, que yo vea el siguiente:

Apr 13 11:45:07 www3 apache2[27590]: **successful view render here**
...
Apr 13 11:47:11 www3 apache2[24032]: [error] server is within MinSpareThreads of MaxClients, consider raising the MaxClients setting
Apr 13 11:47:43 www3 apache2[24032]: [error] server reached MaxClients setting, consider raising the MaxClients setting
...
Apr 13 11:50:34 www3 apache2[27617]: [error] [client 10.177.0.204] Script timed out before returning headers: django.wsgi
(repeated 100 times, exactly)

Creo que estoy corriendo WSGI 2.6(/usr/lib/apache2/modules/mod_wsgi.so-2.6) con la siguiente config:

de configuración de apache

WSGIDaemonProcess site-1 user=django group=django threads=50
WSGIProcessGroup site-1
WSGIScriptAlias / /somepath/django.wsgi

/somepath/django.wsgi

import os, sys
sys.path.append('/home/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings'    
import django.core.handlers.wsgi    
application = django.core.handlers.wsgi.WSGIHandler()

Cuando esto sucede, puede matar a la wsgi proceso y el servidor va a recuperar.

>ps aux|grep django # process is running as user "django"
django   27590  5.3 17.4 908024 178760 ?       Sl   Apr12  76:09 /usr/sbin/apache2 -k start
>kill -9 27590

Esto me lleva a pensar que el problema es un problema conocido:

interbloqueo-timeout=sss (2.0+)

Define el número máximo de segundos permite pasar antes de que el demonio el proceso se apaga y reinicia después de un potencial de interbloqueo en el Python GIL ha sido detectado. El por defecto es 300 segundos. Esta opción existe para combatir el problema de una demonio proceso de congelación como el resultado de un rouge de Python C módulo de extensión que no libera correctamente las Python GIL al entrar en un el bloqueo o la larga marcha de la operación.

Sin embargo, no estoy seguro de por qué esta condición es no borrar automáticamente. Veo que el tiempo de espera del script se produce exactamente 5 minutos después de la última página de procesamiento, por lo que el interbloqueo-tiempo de espera es llegar activa. Pero en realidad no matar el proceso.

Edit: más info

  • versión de apache 2.2, mediante el MPM worker
  • wsgi versión 2.8
  • SELinux NO se instala l
  • paquete xml que se utiliza, con poca frecuencia
  • Ubuntu 10.04

2voto

wkoot Puntos 41

Usted podría intentar añadir un límite de solicitudes después de que el demonio de los procesos de reciclado (antes de un proceso externo lo hace). Esto se hace mediante la adición de la maximum-requests parámetro de WSGIDaemonProcess.

Ver https://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#Defining_Process_Groups

Alternativamente, usted podría investigar cuánto procesos de su 'django' usuario está autorizado a tener. Usted puede comprobar esto mediante la apertura de una shell como usuario su - django -s /bin/bash y comprobación de la salida de ulimit -a.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: