Cuando un amavisdproceso consume el 100% de la CPU, o casi el 100%, el objetivo no es simplemente eliminarlo. Una solución eficaz debería restablecer el flujo normal de correo, reducir la latencia de procesamiento, mantener activas las protecciones antivirus y antispam, e impedir que la cola de Postfix siga creciendo.
En Zimbra, Amavisd-New se sitúa entre el MTA y los escáneres de contenido. La guía de administración actual de Zimbra Daffodil describe a Amavisd-New como la interfaz entre el MTA de Zimbra, ClamAV y SpamAssassin. Esto significa que un pico de uso de CPU puede deberse al propio Amavisd, a las reglas o al contenido de los mensajes de SpamAssassin, al análisis antivirus o a una acumulación de mensajes que mantiene ocupados a todos los procesos disponibles. Consulte la Guía del administrador de Zimbra Daffodil .
Un resultado satisfactorio presenta cuatro indicadores: el uso de CPU de Amavis desciende a un nivel sostenible, las colas de mensajes diferidos y activos dejan de aumentar, los mensajes nuevos se procesan sin demoras inusuales y los servicios antivirus y antispam funcionan correctamente. Si el uso de CPU disminuye únicamente porque se desactivó el filtrado, el problema subyacente no se ha solucionado.
Comience por el sistema operativo. No dé por sentado que Amavis es el responsable simplemente porque la entrega de correo sea lenta. Revise los procesos que consumen más recursos y confirme si uno o más amavisdprocesos están utilizando de forma constante un núcleo completo de la CPU.
top -c
ps -eo pid,user,pcpu,pmem,etime,cmd --sort=-pcpu | head -20
Leyenda: Vista de una terminal donde amavisd es el principal consumidor de CPU, que es la primera condición que se debe verificar antes de cambiar la configuración de Zimbra.
Un pico breve puede ser normal mientras se analiza un mensaje grande o un archivo adjunto comprimido. Considere el problema como persistente si el mismo síntoma continúa mientras aumentan los retrasos en el correo o la profundidad de la cola. Verifique también la carga promedio, la memoria libre, la actividad de intercambio y el tiempo de espera de E/S. Un alto uso de CPU con una gran contención de intercambio o almacenamiento puede requerir una investigación más exhaustiva a nivel del host en lugar de un cambio solo en Amavis.
Acceda a la cuenta de Zimbra y revise el estado del servicio. La documentación de Zimbra utiliza zmcontrol statuseste método como comprobación estándar para los servicios habilitados.
su - zimbra
zmcontrol status
zmamavisdctl status
Leyenda: Estado del servicio Zimbra que muestra los componentes Amavis, antispam, antivirus y MTA en funcionamiento antes de que comience la resolución de problemas.
Este paso es importante porque "100 % de CPU" y "servicio caído" son modos de fallo diferentes. Si Amavis no se está ejecutando, investigue los errores de inicio. Si Amavis se está ejecutando pero está saturado, continúe con el análisis de la cola y los registros.
La profundidad de la cola indica si el alto uso de la CPU está afectando la entrega. Consulte la documentación de Zimbra zmqstatpara la resolución de problemas de colas y los comandos de cola de Postfix para obtener detalles sobre los mensajes. Ejecute las comprobaciones repetidamente con intervalos de unos minutos.
sudo /opt/zimbra/libexec/zmqstat
postqueue -p
Leyenda: Las estadísticas de la cola y los mensajes diferidos proporcionan una mejor medida del impacto en el flujo de correo que el porcentaje de CPU por sí solo.
Busque una tendencia general, no un dato aislado. Una cola que aumenta con cada muestra indica que el rendimiento es inferior a la tasa de llegada. Una cola que disminuye progresivamente tras un cambio es una de las señales más claras de que dicho cambio ha sido efectivo.
Si utiliza una implementación con varios MTA, verifique específicamente el nodo MTA afectado. No dé por sentado que la cola en otro nodo presenta el mismo cuello de botella.
Los mensajes de solución de problemas de Amavis y SpamAssassin se escriben en /var/log/zimbra.log. Busque en torno al momento del pico de CPU y correlacione los ID de los mensajes, los ID de los procesos y las duraciones de los escaneos.
grep -iE 'amavis|spamassassin|clam' /var/log/zimbra.log | tail -n 200
Leyenda: Las líneas de registro de Amavis y SpamAssassin pueden revelar si los mensajes individuales o las etapas de escaneo están tardando un tiempo inusualmente prolongado.
Entre los patrones útiles se incluyen escaneos largos y repetidos de SpamAssassin, reintentos repetidos para los mismos ID de cola, errores de comunicación de ClamAV, fallos relacionados con la descompresión o un pequeño conjunto de mensajes que consumen repetidamente recursos de los trabajadores. La documentación de solución de problemas de Zimbra recomienda específicamente el registro de depuración de Amavis y SpamAssassin cuando los retrasos en el escaneo interrumpen el flujo de correo. Consulte la referencia de solución de problemas de registro de Zimbra .
Zimbra ofrece controles de registro independientes para Amavis y SpamAssassin. El rango documentado de Amavis va de 0 a 5, mientras que SpamAssassin zimbraAmavisSALogLevelutiliza 0 o 1. Comience con el nivel 2 de Amavis en lugar del nivel máximo de detalle, a menos que necesite una depuración más profunda.
su - zimbra
zmprov mcf zimbraAmavisLogLevel 2
zmprov mcf zimbraAmavisSALogLevel 1
Leyenda: Los cambios temporales en el registro de eventos facilitan la correlación entre la duración del escaneo y el comportamiento de SpamAssassin con el pico de uso de la CPU.
Reproduzca u observe el problema solo el tiempo suficiente para obtener datos útiles. Un nivel de registro más alto genera escrituras en disco y puede aumentar el ruido en un servidor con mucha actividad. Tras la investigación, vuelva a los valores anteriores; Zimbra documenta el nivel de registro predeterminado de SpamAssassin como 0 y el de Amavis como de bajo volumen.
zmprov mcf zimbraAmavisSALogLevel 0
zmprov mcf zimbraAmavisLogLevel 1Si los registros apuntan consistentemente a SpamAssassin, verifique si el problema comenzó después de un cambio en las reglas, la implementación de reglas personalizadas o una actualización de reglas fallida. Las expresiones regulares mal diseñadas y las reglas problemáticas pueden resultar costosas en ciertos cuerpos de mensajes.
El material oficial de solución de problemas de Amavis de Zimbra documenta el comando de actualización de SpamAssassin incluido para ZCS 8.8 y versiones posteriores de la siguiente manera:
su - zimbra
/opt/zimbra/common/bin/sa-update -D
Leyenda: Es apropiado actualizar las reglas de SpamAssassin incluidas en el paquete cuando los registros o los errores de inicio indican que los datos de las reglas están obsoletos o dañados.
No lo considere sa-updateuna solución universal para la CPU. Si el pico comenzó inmediatamente después de agregar una regla personalizada, pruebe primero esa regla. Zimbra almacena las reglas personalizadas modernas de SpamAssassin en /opt/zimbra/data/spamassassin/localrules/. Elimine o desactive solo la personalización sospechosa en una ventana de mantenimiento controlada y luego compare el tiempo de escaneo y el comportamiento de la cola.
La wiki oficial de Zimbra también menciona la actualización automática de reglas y la configuración de compilación para las versiones más recientes de ZCS. Revise las estrategias antispam de Zimbra antes de habilitar el comportamiento automatizado en un servidor ya establecido.
Reiniciar el sistema puede eliminar los procesos bloqueados y cargar las reglas actualizadas, pero debe realizarse después del diagnóstico, no reemplazarlo. Reinicie solo Amavis primero, a menos que haya indicios de que el problema esté en el conjunto de herramientas de MTA.
su - zimbra
zmamavisdctl restart
Leyenda: Reiniciar Amavis recarga el servicio después de un cambio específico en las reglas o la configuración, sin reiniciar innecesariamente todos los servicios de Zimbra.
Si la CPU vuelve inmediatamente al 100%, es una prueba útil: la causa persiste. Revise los registros e identifique si el mismo mensaje, escáner o regla vuelve a aparecer. Reiniciar el servicio repetidamente puede reducir temporalmente los síntomas, aunque esto permite que la cola siga creciendo.
No considere que el incidente está resuelto después de ver una disminución en el número de uso de CPU una sola vez. Verifique la carga del proceso, la dirección de la cola y el estado del servicio en conjunto.
top -c
sudo /opt/zimbra/libexec/zmqstat
zmcontrol status
Leyenda: La recuperación es más eficaz cuando el uso de la CPU, la profundidad de la cola y el estado del servicio Zimbra mejoran simultáneamente.
Luego, envíe un mensaje de prueba a través del MTA afectado y confirme que se entrega dentro de su rango de latencia habitual. Para un mensaje que debería pasar el filtrado, inspeccione sus encabezados para verificar los campos de análisis de virus y spam esperados de Zimbra/Amavis. Zimbra documenta encabezados como X-Virus-Scannedy X-Spam-Statuscuando estas comprobaciones están activas.
| Lo que observas | Mejor siguiente paso | Por qué |
|---|---|---|
| Un mensaje provoca repetidamente escaneos largos. | Ponga en cuarentena o inspeccione ese mensaje de forma segura y correlacione su ID de cola con los registros. | El cuello de botella puede ser específico del contenido en lugar de estar relacionado con la capacidad. |
| El timing de SpamAssassin es dominante. | Revise las reglas personalizadas, las actualizaciones de reglas y la salida de depuración. | Los conjuntos de reglas con muchas expresiones regulares o dañados pueden hacer que la puntuación sea costosa. |
| Los errores o tiempos de espera de ClamAV son predominantes. | Investigar el estado del antivirus y actualizarlo. | Es posible que Amavis simplemente esté esperando al escáner al que llama. |
| El uso de la CPU es alto, pero las colas se mantienen cerca de cero. | Observar durante más tiempo antes de realizar cambios disruptivos | Una alta utilización puede ser aceptable si el rendimiento y la latencia se mantienen dentro de límites saludables. |
| Las colas siguen aumentando incluso después de realizar correcciones específicas. | Escalar a análisis de capacidad, patrón de mensajes o nivel de soporte. | El servidor puede ser insuficiente, estar bajo ataque o estar sufriendo un fallo específico del software. |
No desactive permanentemente el análisis antivirus o antispam solo para reducir el uso de la CPU. Zimbra admite políticas de omisión para tráfico específico de confianza/origen, pero esto modifica el modelo de seguridad y debe ser una decisión deliberada de la política de correo, no un ajuste genérico de rendimiento. La documentación de Zimbra sobre la omisión de SpamAssassin de origen deja claro que esta está vinculada a redes internas de confianza.
Evite también aumentar indiscriminadamente el número de trabajadores de Amavis. Si bien un mayor número de trabajadores puede incrementar la concurrencia, también aumenta la presión sobre la memoria y puede empeorar la contención de la CPU. El valor correcto depende de la combinación de mensajes, el tamaño de los archivos adjuntos, el comportamiento del escáner, los núcleos disponibles, la memoria y las operaciones de entrada/salida. Pruebe los cambios comparándolos con el rendimiento y la latencia de la cola, en lugar de asumir que un mayor número de trabajadores resulta más rápido.
Este procedimiento está diseñado para el caso común en el que Amavis se está ejecutando pero consume muchos recursos de la CPU de forma persistente. No reemplaza la guía de soporte de Zimbra específica para cada versión en caso de un defecto confirmado del producto, un servidor comprometido, una campaña de denegación de servicio mediante mensajes mal formados o una arquitectura de varios nodos con escáneres externos.
El material técnico de la comunidad de Zimbra documenta casos históricos donde mensajes especialmente diseñados o el comportamiento de SpamAssassin podían sobrecargar los servidores de Amavis durante periodos prolongados. Dado que la exposición exacta depende de las versiones instaladas de Zimbra y SpamAssassin, no aplique una actualización de paquete antigua sin antes verificar su versión. Primero, registre su versión de Zimbra zmcontrol -v, compárela con la versión y el nivel de parche compatibles y siga las instrucciones del proveedor para las actualizaciones.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
