Apio - minimiza el consumo de memoria

Question

Tenemos ~ 300 procesos apilados bajo Ubuntu 10.4 de 64 bits, en inactivo cada proceso requiere ~ 19mb RES, ~ 174mb VIRT, por lo tanto - hay alrededor de 6GB de RAM en reposo para todos los procesos. En estado activo: el proceso requiere hasta 100mb de RES y ~ 300mb VIRT

Cada proceso utiliza minidom (los archivos xml son < 500kb, estructura simple) y urllib.

Las consultas son, ¿cómo podemos disminuir el consumo de RAM? Al menos para los trabajadores ociosos, probablemente algunas opciones de apio o pitón pueden ayudar. ¿Cómo determinar qué parte ocupa la mayor parte de la memoria?

UPD: agentes de búsqueda de vuelo, un trabajador por una agencia/fecha. Tenemos 10 agencias, una búsqueda de usuario == 9 fechas, por lo tanto, tenemos 10 * 9 agentes por cada búsqueda de usuario.

¿Es posible iniciar procesos on demand para evitar trabajadores en inactividad (algo así como MaxSpareServers en apache)?

UPD2: Agente ciclo de vida es - enviar solicitud HTTP, esperar la respuesta de ~ 10-20 seg, analizar XML (se tarda menos de 0.02s), guardar el resultado a MySQL

Answer 1

leyeron:

http://docs.celeryproject.org/en/latest/userguide/workers.html#concurrency

Parece que tiene un trabajador por persona. Eso parece incorrecto Debe tener docenas de trabajadores por apéndice. Siga aumentando el número de trabajadores (y disminuya el número de apio) hasta que su sistema esté muy ocupado y muy lento.

Answer 2

S. Lott tiene razón. La instancia principal consume mensajes y los delega en procesos de grupos de trabajadores. ¡Probablemente no tenga sentido ejecutar 300 procesos de grupo en una sola máquina! Pruebe 4 o 5 multiplicado por la cantidad de núcleos de CPU. Puede que ganes algo ejecutando más que aplicándose con algunos procesos cada uno, algunas personas lo han hecho, pero tendrías que experimentar para tu aplicación.

Ver http://celeryq.org/docs/userguide/workers.html#concurrency

Para la próxima versión 2.2 estamos trabajando en apoyo de la piscina Eventlet, esto puede ser una buena alternativa para las tareas ligadas-IO, que le permitirá ejecutar más de 1000 hilos con un mínimo de memoria sobrecarga, pero sigue siendo experimental y se están corrigiendo errores para la versión final.

Ver http://groups.google.com/group/celery-users/browse_thread/thread/94fbeccd790e6c04

La próxima 2.2 versión también tiene soporte para escala automática, lo que añade/quita proceso bajo demanda. Ver el registro de cambios: http://ask.github.com/celery/changelog.html#version-2-2-0 (esta lista de cambios no está escrito completamente aún)

Answer 3

El número natural de los trabajadores está cerca del número de núcleos que tiene. Los trabajadores están ahí para que las tareas que requieren mucha CPU puedan usar un núcleo completo de manera eficiente. El agente está allí para que las solicitudes que no tienen un empleado a mano para procesarlas se mantengan en cola. El número de colas puede ser alto, pero eso no significa que necesite un alto número de intermediarios tampoco. Un único intermediario debería ser suficiente, o podría fragmentar las colas en un intermediario por máquina si luego resulta que la interacción rápida entre el empleado y la cola es beneficiosa.

Su problema parece no estar relacionado con eso.Supongo que sus agencias no proporcionan una API de cola de mensajes, y debe mantener un montón de solicitudes. Si es así, necesita algunos (énfasis en no muchos) procesos destacados, por ejemplo, twisted o node.js.

Answer 4

Utilice la función de escalado automático. Esto permite aumentar o disminuir la cantidad de trabajadores en cada instancia apical según sea necesario. http://docs.celeryproject.org/en/latest/userguide/workers.html#autoscaling