[pyar] si se ve como un pato y suena como un pato...

[Claudio Freire]

2010/10/6 Nicolas Echaniz <nico en rakar.com>

> Hicimos muchas pruebas de deployment con mod_wsgi, fastcgi, gunicorn+nginx,
> spawning, etc. En cualquier caso, no logramos que cada proyecto de django
> (cada instancia de Cyclope) ocupara menos de 20Mb en RAM; salvo usando CGI
> :)
>

Por otro lado, los programas de python casi nunca pueden ocupar poco en
memoria, porque el conteo de referencias destruye las optimizaciones de
linux que hacen posible esto en otras plataformas.

Me refiero al copy-on-write de las páginas de memoria ante un fork.

Podrías levantar tu entorno (importás todo django y demás bibliotecas
comunes), y luego hacés fork() para levantar cada subsitio. Supuestamente,
toda la memoria compartida (las bibliotecas) deberían estar una sola vez en
memoria, porque linux hace copy-on-write durante el fork. Es decir, no copia
las páginas de memoria hasta que intentás escribir sobre ellas.

Pero como todo objeto de python contiene un contador de referencias,
cualquier cosa que hagas con tus objetos dispara esa copia. A veces muy al
pedo.

Yo trabajé en un parche a Python para evitar esto, y en algunos patrones de
uso (particularmente con multiprocessing) el efecto es enorme. Pero tiene
defectos.

Por un lado, no emparché el garbage collector, así que los ciclos de
colección disparan la copia. El parche sirve con multiprocessing porque
usualmente no pasás tanto tiempo dentro de un subproceso como para disparar
un ciclo de colección, y hay muchos objetos compartidos que no son
colectables, esos no se copian. Fácilmente... bue... no tan fácil pero
posiblemente, podría completar el parche para corregir el garbage collector
y hacerlo completo.

Por otro lado, el parche agrega un nivel de indirección al contador de
referencias. Hay que recompilar toooodas las extensiones escritas en C,
algunas no son compatibles "out-of-the-box" (como en el caso de scipy). El
parche ya emparcha toda las bibliotecas estándar, pero aunque las que no son
estándar corregirlas es relativamente sencillo, es toda una tarea.

Además, al agregar un nivel de indirección, impacta en la performance. Pasé
mucho tiempo optimizándolo, y aún así se siente en promedio un 10% de
ralentamiento.

O sea... podrías trabajar como un perro para hacer que cada instancia de
django ocupe poco. Pero tu solución está más copada :)

(sin embargo, si te ves en la necesidad, podrías probar el parche)
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20101006/7f82699f/attachment.html>