3 votos

Sitios de Python Django en Apache mod_wsgi con proxy nginx: rendimiento altamente fluctuante

Tengo un Ubuntu 10.04 cuadro de la ejecución de varias docenas de Python Django sitios y el uso de mod_wsgi (modo incrustado; el modo más rápido, si está configurado correctamente). Rendimiento muy fluctúa. A veces rápido, a veces de varios segundos de retraso. El smokeping los gráficos están al cargo del lugar.

Recientemente, también he añadido un proxy nginx para el contenido estático, con la esperanza de que acabaría con la gran fluctuación de rendimiento. Pero, aunque se redujo el número de solicitudes de Apache tiene que procesar de manera significativa, no ayuda con el problema principal.

Al dar clic en los sitios web mientras se ejecuta htop, se puede ver que a veces las solicitudes son casi instantánea, mientras que a veces causa de Apache a consumir el 100% de la CPU durante unos segundos. Realmente no entiendo donde esta fluctuación viene.

He configurado el mpm_worker para Apache como este:

StartServers          1
MinSpareThreads      50
MaxSpareThreads      50
ThreadLimit          64
ThreadsPerChild      50
MaxClients           50
ServerLimit          1
MaxRequestsPerChild  0
MaxMemFree           2048

1 server con 50 hilos, max 50 clientes. Munin y apache2ctl -t ambos muestran una consistente presencia de los trabajadores; que no sean destruidos y creando todo el tiempo. Sin embargo, se comporta como tal.

Esto me dice que una vez un sub intérprete se crea, debe permanecer en la memoria, sin embargo, parece que los sitios tienen que volver a cargar todo el tiempo.

También tengo un nginx+gunicorn caja, que se lleva a cabo muy bien. Realmente me gustaría saber por qué Apache es tan aleatorio.

Este es un host virtual config:

<VirtualHost *:81>
    ServerAdmin bla@bar.com
    ServerName example.com

    DocumentRoot /srv/http/site/bla

    Alias /static/ /srv/http/site/static
    Alias /media/ /srv/http/site/media
    WSGIScriptAlias / /srv/http/site/passenger_wsgi.py

    <Directory />
            AllowOverride None
    </Directory>

    <Directory /srv/http/site>
            Options -Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

  • Ubuntu 10.04
  • Apache 2.2.14
  • mod_wsgi 2.8
  • nginx 0.7.65

Edit: he puesto el código en el settings.py archivo de un sitio que escribe la fecha a un archivo tmp cada vez que se carga. Ahora puedo ver que el sitio no es al azar vuelve a cargar todo el tiempo, de manera que Apache se debe mantener en la memoria. Así que, eso es bueno, excepto que no me trae más cerca de una respuesta...

Edit: acabo de encontrar un error que podría también estar relacionada con esto:

  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)

  File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
    self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

El servidor tiene 600 de 2000 MB de espacio libre, que debería ser suficiente. Hay un límite que se establece en Apache o WSGI en algún lugar?

2voto

Jason Puntos 8799

Has probado a utilizar la Nueva Reliquia para intentar identificar si es un problema en la aplicación web? Nivel gratuito disponible y también un total inicial de prueba. Resumen de lo que se puede dar en:

Si un problema específico con la aplicación web de servicio de fondo que se utiliza no se destaca como un problema, la WSGI la capacidad del servidor de informes de análisis puede mostrar algo, como le dirá si tienes la capacidad. También puede decirle si usted tiene más de aprovisionar y el desperdicio de recursos, que en realidad es muy a menudo el caso.

BTW, en general, yo recomendaría no usar 50 solicitud de subprocesos en el proceso. Es mejor usar alrededor de 5 hilos y varios procesos. Exactamente lo que es mejor ¿a pesar de que realmente dependen de la aplicación específica, si está haciendo un montón de CPU trabajo, y cuánto tiene que manejar mucho ejecución de solicitudes. Ya sea sirviendo un montón de archivos estáticos a través de la misma Apache puede también impactar, con el modo de demonio de mod_wsgi, posiblemente, incluso siendo una mejor solución global.

También está en una muy antigua mod_wsgi versión, aunque no creo que pueda ocasionar un problema.

Finalmente, para evitar problemas con algunos terceros C módulos de extensión de Python, si esta es la única WSGI de la aplicación en el servidor, establece:

WSGIApplicationGroup %{GLOBAL}

2voto

Halfgaar Puntos 2866

Me fijo. Me he convertido todos los sitios de la producción para el uso de su propio proceso (y todos los sitios de desarrollo todos juntos en un solo proceso), en modo demonio. El Smokeping los gráficos son mucho mejores que ahora. El rendimiento es constante.

Esto todavía me deja en la oscuridad acerca de por qué modo incrustado tenido estos problemas, porque la medida de lo que puedo decir que yo no he tenido el proceso de creación/destrucción, pero al menos tengo un mejor funcionamiento del servidor.

Editar:

Como un ejemplo de que en un sitio de apache configuración:

WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12

Y, a continuación, para la baja prioridad de los sitios de poner esto en wsgi.conf:

WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}

Y, a continuación, en un conf de apache:

WSGIProcessGroup developmentsites

Mira la diferencia (también porque de nginx proxy):

enter image description here

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: