Cómo minimizar el uso de la memoria SpamAssassin (spamd)

Estoy usando SpamAssassin en Debian (la configuración predeterminada con Pyzor, AWL y Bayes deshabilitados, y la compilación sa habilitada), y cada uno de los procesos secundarios no deseados consume alrededor de 100 a 150 MB de memoria (alrededor de 50 MB de memoria real) en el 32 servidores de bits, y aproximadamente el doble (lógicamente) en los servidores de 64 bits. Generalmente hay dos procesos secundarios, pero en los momentos de mayor actividad puede haber cinco (el máximo) en ejecución.

ISTM dice que de 200 a 600 MB es mucha memoria para esta tarea. Me gustaría seguir usando SA como parte de mi estructura de filtrado, pero cada vez es más difícil justificar tanta memoria.

¿Hay alguna forma de reducir la cantidad de memoria que utiliza cada proceso secundario? (O, alternativamente, hacer que un solo proceso hijo sea tan rápido que pueda establecer el máximo de hijos en algo así como 2? Estoy dispuesto a considerar cualquier opción, incluidas las que reducirán o reducirán la precisión.

Ya leí la página "Problemas de memoria insuficiente" en el wiki de SA ; nada hay de ninguna utilidad. Los mensajes de más de 5 MB no se analizan con SA.

Creo que está malinterpretando la forma en que Linux informa el uso de memoria. Cuando un proceso se bifurca, resulta en un segundo proceso que comparte muchos recursos con el proceso original. Incluido en eso está la memoria. Sin embargo, Linux utiliza una técnica conocida como Copia en escritura (COW) para esto. Lo que eso significa es que cada proceso secundario bifurcado verá los mismos datos en la memoria que el proceso original, pero cada vez que esos datos cambien (por el elemento secundario o principal), los cambios se copian y solo entonces apuntan a una nueva ubicación.

Hasta que uno de los procesos realice cambios en esos datos, estarán compartiendo la misma copia. Como resultado, podría tener un proceso que usa 100 MB de RAM y bifurcarlo 10 veces. Cada uno de esos procesos bifurcados mostraría 100 MB de RAM en uso, pero si observa el uso general de la memoria en la caja, solo podría mostrar que se están usando 130 MB de RAM (100 MB compartidos entre los procesos, más unos pocos MB de sobrecarga) , más otra docena de MB o dos para el resto del sistema).

Como último ejemplo, tengo un cuadro en este momento con 30 procesos de apache en ejecución. Cada proceso muestra un uso de 22 MB de RAM. Sin embargo, cuando ejecuto free -m para mostrar mi uso general de RAM, obtengo:

topher@crucible:/tmp$ free -m
             total       used       free     shared    buffers     cached
Mem:           349        310         39          0         24         73
-/+ buffers/cache:        212        136
Swap:          511         51        460

Como puede ver, este cuadro ni siquiera tiene suficiente RAM para ejecutar 30 procesos que usaban cada uno 18 MB de RAM "real". A menos que literalmente se esté quedando sin RAM o sus aplicaciones se intercambien fuertemente, no me preocuparía por las cosas.

ACTUALIZACIÓN: Además, consulte esta herramienta llamada smem , mencionada por jldugger en la respuesta a otra pregunta sobre el uso de memoria de Linux aquí .

Usando sa-compile puede mejorar la velocidad de coincidencia de muchas reglas.

Esto es lo que he hecho.

Tengo una configuración en la que muchos mensajes tienden a entregarse aproximadamente al mismo tiempo; para una serie de experimentos ejecuto SA en mensajes que se copian en un carrete temporal y luego se entregan mediante un trabajo cron cada cinco minutos.

spamd seguía imprimiendo "tal vez debería aumentar el parámetro max-children" y lo hice subir hasta 40 en un punto, pero hice que el servidor consumiera todo su espacio de intercambio y fallara.

Ahora he implementado un régimen diferente donde la entrega se rige por un archivo de bloqueo de Procmail. Debido a que era simple de hacer, solo uso el último dígito de la ID del proceso y corro con 10 hijos. No estoy del todo seguro de que esto sea óptimo, pero ya ha ayudado a evitar los picos de carga locos que experimentaba de vez en cuando.

LINEBUF=10240

# Grab last digit of PID for lockfile
PID=$$
:0
* PID ?? ()\/[0-9]$
{ D=$MATCH }
:0
* > 512000
{ SA="(too large)" }
:0Ew:/tmp/20spamc.$D
SA=| spamc -p 38783 -l -y

Además, empiezo spamdcon una serie de ulimitrestricciones. Los números fueron tomados de http://svn.apache.org/repos/asf/spamassassin/trunk/contrib/run-masses excepto que eliminé la ulimit -urestricción. (No estoy seguro de lo que está sucediendo. 32 es demasiado pequeño en cualquier caso. Con algo como 500 podría seguir spamdcorriendo por un tiempo, pero eventualmente llegando al límite).

ulimit -v 204800
ulimit -m 204800
ulimit -n 256
#ulimit -u 32

perl -T -I lib -w spamd --min-children 2 --max-children 10 --max-spare 5 etc etc

Supongo que terminaré con fallas de entrega si la carga es demasiado alta durante un tiempo prolongado, pero hasta ahora, parece que he logrado reducir la carga a niveles manejables con esto; y un montón de entregas fallidas sigue siendo mucho mejor que la máquina que se queda sin intercambio.

Los promedios de carga alta son (a veces) un síntoma indirecto de que su máquina se está quedando sin RAM (y está utilizando muchos procesos de intercambio de CPU de memoria virtual), por lo que puede intentar configurar su servidor de correo para que no pase correo a través de SpamAssassin si el los promedios de carga son demasiado altos.

No menciona qué MTA está ejecutando, pero si llama a SA desde una lista de control de acceso en exim4, entonces la sugerencia al final de este mensaje es efectiva.

Además, puede aliviar la carga en SA y, por lo tanto, reducir el uso de la memoria, al colocar otros métodos de filtrado de correo no deseado que requieren menos recursos (es decir, procesan y rechazan algo de correo no deseado antes de que llegue a SA): por ejemplo, las listas grises y el remitente verifican que las llamadas usan relativamente poca RAM.

Estuvimos en una situación similar hace varios meses. SpamAssassin y ClamAV estaban usando mucha memoria en un servidor alojado. Tuvimos la opción de agregar más memoria al servidor, pero resultó ser más rentable y rentable cambiar a Postini. YMMV.