Compartir Python Intérprete en Apache Prefork/WSGI

Question

Estoy intentando ejecutar una aplicación de Python dentro de Apache (prefork) con WSGI de tal manera que se utilizará un solo intérprete de Python. Esto es necesario ya que la aplicación utiliza sincronización de subprocesos para evitar que ocurran condiciones de carrera. Como el prefork de Apache genera múltiples procesos, el código termina siendo no compartido entre los intérpretes y, por lo tanto, la sincronización del subproceso es irrelevante (es decir, cada subproceso solo ve sus propios bloqueos que no tienen relación con los otros procesos).

Aquí es la configuración:

• Apache 2,0 (prefork)
• WSGI
• Python 2,5

Aquí es la configuración relevante Apache:

WSGIApplicationGroup %{GLOBAL} 
<VirtualHost _default_:80> 

WSGIScriptAlias//var/convergedsecurity/apache/osvm.wsgi 

Alias /admin_media/ /var/www/html/admin_media/ 

<Directory /var/www/html/admin_media> 
Order deny,allow 
Allow from all 
</Directory> 

Alias /media/ /var/www/html/media/ 

<Directory /var/www/html/media> 
Order deny,allow 
Allow from all 
</Directory> 

</VirtualHost> 

Aquí es lo que intenté hasta ahora (ninguno de whi ch trabajó):

1. Adición de WSGIApplicationGroup %{GLOBAL}

2. Especificación WSGIDaemonProcess y WSGIProcessGroup dentro del huésped virtual:

   hilos WSGIDaemonProcess osvm = 50
   WSGIProcessGroup osvm

Es no hay forma de ¿obligar a Apache prefork a usar un solo intérprete de Python con WSGI? Los documentos parecen implicar que puede hacerlo con las opciones WSGIDaemonProcess y WSGIApplicationGroup pero Apache aún crea un intérprete de Python separado para cada proceso.

Answer 1

No se puede ejecutar la aplicación WSGI en modo integrado en sistemas UNIX, ya sea prefork o MPM worker, ya que de hecho habrá múltiples procesos. Ver:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Creación de un grupo que consiste en proceso de demonio solo proceso y delegar aplicación WSGI a que debe lograr lo que quiere. Ni siquiera debería necesitar usar WSGIApplicationGroup si solo está una aplicación WSGI montada de la que está hablando. Si quieres estar absolutamente seguro, también puedes configurarlo.

este modo de configuración dentro VirtualHost sería:

WSGIDaemonProcess osvm 
WSGIProcessGroup osvm 
WSGIApplicationGroup %{GLOBAL} 

WSGIScriptAlias//var/convergedsecurity/apache/osvm.wsgi 

Aunque 'procesos = 1' para WSGIDaemonProcess hace explícito que se crea un proceso, no proporcionan la opción sin embargo y dejarlo por defecto a un proceso de . Cualquier uso de la opción 'procesos', incluso si para un proceso se verá 'wsgi.multiprocess' establecido en True.

En lugar de utilizar su aplicación WSGI real, le sugiero que pruebe con el siguiente programa de prueba simple.

import cStringIO 
import os 

def application(environ, start_response): 
    headers = [] 
    headers.append(('Content-Type', 'text/plain')) 
    write = start_response('200 OK', headers) 

    input = environ['wsgi.input'] 
    output = cStringIO.StringIO() 

    print >> output, "PID: %s" % os.getpid() 
    print >> output 

    keys = environ.keys() 
    keys.sort() 
    for key in keys: 
     print >> output, '%s: %s' % (key, repr(environ[key])) 
    print >> output 

    output.write(input.read(int(environ.get('CONTENT_LENGTH', '0')))) 

    return [output.getvalue()] 

En la salida de eso, el valor PID siempre debe ser el mismo. El indicador wsgi.multiprocess debe ser False. El mod_wsgi.El valor de process_group debe ser lo que haya llamado el grupo de procesos de daemon. Y el mod_wsgi.application_group debería ser una cadena vacía.

Si esto no es lo que está viendo, asegúrese de reiniciar Apache después de hacer cambios en la configuración. También agregue:

LogLevel debug 

a la configuración de Apache para VirtualHost. Hacer eso hará que mod_wsgi registre muchos más mensajes en el registro de errores de Apache sobre la creación de procesos y la carga de scripts, incluidos los detalles del grupo de procesos y las cosas de los grupos de aplicaciones.

Para más información sobre la depuración, ver:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

Si los problemas siguen, sugiero que vaya a la lista de correo mod_wsgi en Google Groups.