Uso de Memoria de Zope

Bueno esto es un referente práctico pero no muy exacto basado en la experiencia

Wake Up

Primero hay que tener claro que zope cuando accede a un objeto (wakeup en terminología de zope) lo carga desde la base de datos completo a memoria, esto trae una serie de problemas:

• Si el objeto es binario y es grande, ocupa bastante memoria. Si tenemos muchos objetos de considerable tamaño empiezan los problemas, es más, si colocamos, por ejemplo un vídeo de 100Mbytes, primero lo carga en memoria y cuando termina lo sirve, tardando un tiempo considerable en comenzar la transferencia. Este problema actualmente tiene solución.
• Al programar plantillas / scripts hay que tener cuidado en no despertar demasiados objetos. Si utilizamos referencias o listamos contenidos completos de carpetas sin utilizar el catálogo, el sistema se vuelve lentísimo, tengo pruebas en las que las referencias tardan más de un minuto en mostrar un listado. Por tanto, es muy importante poner en el catálogo todo lo que podamos, es más, crear incluso catálogos nuevo si fuera necesario.

Conclusión: Intentar sólo acceder al objeto activo en la url y evitar despertar el resto en cualquier plantilla que hagamos

Uso de memoria

• Directiva global zserver-threads por defecto a 4, os recomiendo que no la pongáis a mas de 6 he colgado varios servidores por ponerlos a 10. Cuando los hilos no dan a basto, el uptime llega a sobrepasar 25 y no se puede ni ejecutar un shell de root para reiniciar la máquina o parar zope. Tener muchos hilos no resuelve nada.
  
• Directiva particular de cada base de datos cache-size por defecto a 5000. En principio por cada hilo que tenga la instancia de zope se guardan en memoria un máximo de 5000 objetos, es decir, con 4 hilos tendremos un máximo de 4x5000=20000 objetos en memoria. La clave ahora es saber cual es el tamaño medio de los objetos.

Problema de python e hilos

Este problema se soluciona con un ZEO y varios ZOPES en paralelo.

Podeís encontrar más información sobre el problema de los hilos en: http://docs.python.org/api/threads.html

Cache

Realmente los tamaños de los objetos son variables en cada sitio. En uno de los sitios que tengo con mayor actividad hay unos 20000 objetos de todo tipo por lo que puede ser relevante. Se ha evitado incluir fichero binarios grandes mediante productos encargados de mantenerlos en el sistema de ficheros (External Storage, Attachment Field, LocalFolderNG, Reflecto, etc..). Estos productos también requieren unos comentarios que escribiré en otro documento parecido a este (estoy en ello)

Estas estadísticas las usé para optimizar el uso de la memoria de la máquina e intentar evitar la paginación del sistema: (Zope 2.8/ Zope 2.9 plone 2.1.X)

Estadísticas en el servidor de las en las primeras 12 horas de salida. No se utilizó la directiva "ignore-reload" de squid, todas las recargas atravesaron el caché:  (esta directiva de squid se puede utilizar cuando comienzan los problemas en zope, mientras se busca solución)

• 1279922 accesos
• 63332 fallos de caché (acierto del 95%)

Hubo problemas con "transient-objects" se aumentó en el archivo de configuración de cada instancia de zope. El entorno constó de 4 zopes: 1 con 6 hilos para escritura y 3 con 4 hilos sólo lectura. Todos con un caché de objetos de 10000.

• Zope de 6 hilos: 656MB, 60000 objetos en caché
• Zopes de 4 hilos: 452MB, 40000 objetos en caché

Aproximadamente son unos 116MB/10000 Objetos. Este cálculo es simple pero funciona para optimizar el uso de RAM en el servidor, lo he utilizado varias veces:

Conclusión: 12K por objeto de media. Uso de memoria=12K * CacheSize * ServerThreads