Postfix performance

Ejecutando postfix en ubuntu, enviando mucho correo (~ 1 millón de mensajes) por día. Las cargas son extremadamente altas, pero no mucho en términos de CPU y carga de memoria. ¿Alguien en una situación similar y sabe cómo eliminar el cuello de botella?

Todo el correo en este servidor es saliente.

Tendría que asumir que el cuello de botella es el disco.

Solo una actualización, así es como se ve iostat:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

¿Están estos números en línea con el rendimiento que esperaría de un solo disco?

sdb está dedicado a postfix.

Creo que es una mezcla aleatoria, de entrante-> activo-> diferido

Más detalles de las preguntas:

Servidor: CPU de cuatro núcleos Xeon (R) E5405 @ 2.00GH con 4 GB de ram

Promedio de carga: 464.88, 489.11, 483.91, 4 núcleos. pero la utilización de memoria y CPU es mínima

Postfix instancias entre 16 - 32

Esto puede sonar un poco loco, pero deberías:

1. Rechace el registro al mínimo que necesita. Haga que syslog solo registre mail.err o superior.
2. Agrega más RAM. Sí, Postfix no lo necesita, pero RAM adicional significa caché de página adicional para el núcleo.
3. No mencionó qué sistema de archivos está en / dev / sdb (que también es importante), pero definitivamente cámbielo a noatime, lo que debería reducir la carga al menos un poco.
4. Vea qué tan grande es su / var / spool / postfix. Si está bajo un par de conciertos, considere moverlo a un disco RAM.

Tengo que estar en desacuerdo con aquellos que sugirieron usar un disco RAM para "/ var / spool / postfix". Esto significa que toda su cola de correo se almacenará en la RAM. Si su servidor falla o pierde energía, los mensajes en la cola desaparecen para siempre. Esto es realmente malo desde la perspectiva del cliente / usuario porque el mensaje ya ha sido aceptado con éxito para la entrega. Peor aún, su servidor no enviará un aviso indicando que un correo electrónico rebotó o no se pudo entregar porque la cola estará vacía cuando el servidor vuelva a funcionar.

En cambio, agregaría tantos discos rápidos como pueda permitirse; Realmente no puedo estimar cuántos necesitará con la información proporcionada. Desde la salida "iostat" anterior, parece que estás haciendo ~ 120 IOPS a 'sdb' (suma de r / sy w / s). Puede estimar razonablemente que un solo disco SCSI o FC de 15k RPM manejará 150 IOPS. Comenzaría con 5 discos SCSI de 15k RPM y un controlador RAID decente. Configúrelo como RAID-10 en 4 unidades con 1 repuesto dinámico. No estoy seguro de que esto resuelva completamente su problema, pero definitivamente no lo empeorará.

Ejecute postfix bajo algún generador de perfiles (gprof?), O busque en los registros. Postfix registra una gran cantidad de información de temporización que podría indicarle dónde está la demora. Los lugares comunes para buscar son:

1. Rendimiento del disco. Tal vez sea hora de RAID-10 para su cola.
2. Cualquier tipo de red IO en mensajes. Listas negras de DNS? SAV?
3. Milters y otros filtros que has instalado.
4. La autenticación y las búsquedas de UID se realizan a través de la red o en un proceso (ldap, sql).
5. no usa proxy: para mapas lentos (como el anterior)

Un millón de mensajes al día es de aproximadamente 11 por segundo, suponiendo que el rendimiento sea constante. Postfix por sí mismo debería ser capaz de manejar al menos un orden de magnitud mayor que el del hardware del servidor de nivel de entrada. Así que sospecho que tiene más que solo postfix ejecutándose, o picos de rendimiento distribuidos de manera muy desigual.

Su situación ciertamente parece un servidor fuertemente vinculado a E / S. Esto es de esperarse con un MTA, que necesita hacer muchas escrituras pequeñas para garantizar que no perderá correo.

Tómese el tiempo para sintonizar E / S en ambos /var/spool/postfixy /var/log. La mejor práctica para los servidores de postfix ocupados es separar los dos en diferentes ejes y asegurarse de que el registro asincrónico esté habilitado. prefija el nombre del archivo de registro para su registro de correo con un guión en Linux.

mail.info                              -/var/log/mail.log

o similar.

Si está utilizando amavisd-new, asegúrese de que su área de trabajo esté en un sistema de archivos tmpfs. Usualmente lo ponemos /tmp/vscan/. Esto es seguro, ya que amavisd-new no devuelve una respuesta de fin de datos hasta que el salto descendente (post-filtro) haya aceptado el mensaje.

Algunas personas recomiendan noatimeopciones de montaje para el carrete postfix. Esto es potencialmente imprudente, debido a la forma en que postfix depende de la semántica del sistema de archivos. Ver por ejemplo http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

Definitivamente parece que su subsistema de disco debería al menos considerarse como parte del problema. Debido a la forma en que postfix baraja los archivos alrededor de / var, sugeriría buscar en Google "ajustar el sistema de archivos ext3" (al menos configurar noatime y escribir de nuevo) para ver si no puede aumentar el rendimiento en el nivel del sistema de archivos.

Tengo dos grupos de servidores que duplican el servicio DNS y SMTP saliente para el correo electrónico destinado al cliente y ejecutan mensajes de 250k diariamente (2k-10k / hora) sin ese tipo de bindup de E / S.

A mí me parece un cuello de botella de rendimiento de almacenamiento.

El iowait de 99.88 le dice que su sistema está pasando mucho tiempo esperando en su almacenamiento.

Estoy de acuerdo con Bill Weiss. Deberías buscar una configuración de raid10 para la cola.

o comenzar con

vmstat 1

"iostat 1" sugerido por moshen también es bueno

de sus estadísticas claramente subsistema de disco más rápido sería bueno. raid-10 en discos de 6-8 15k rpm tal vez con algo de caché, un par de conciertos de memoria a bordo.

monte su directorio de spool con las opciones noatime, nodiratime. considere ajustar o cambiar su sistema de archivos para manejar muchos archivos pequeños [supongo].

Brian

Realmente necesita obtener un disco más rápido, o preferiblemente pasar a una solución de ataque. ¿Qué tipo de servidor es este?

James

Si está ejecutando amavis para el filtrado de spam + virus, debe aumentar el número de procesos simultáneos de amavis. De acuerdo con su configuración, es posible que necesite aumentar tanto la cantidad de procesos smtp-amavis de postfix master.cf como la configuración relevante en amavis.conf.

¿Cuántos núcleos hay en la caja y cuál es la carga real? ¿Cuál es la tasa real de envío de mensajes?

Como la mayoría, mi primer pensamiento es el disco, así que verifíquelo.

Sin embargo, la utilización de la red puede ser la causa, ya que puede ser una carga de interrupción alta (¿tarjeta defectuosa?), Así que verifíquelas. Descubrí que incluso para un servidor de correo modesto, tener un servidor DNS de almacenamiento en caché rápido (soy parcial a "desvinculado") en el mismo cuadro ayuda a aliviar la latencia y la carga de la red.

con usted haciendo 630 lecturas y 1042 escrituras por segundo, definitivamente sugiero aumentar su memoria en el sistema (para manejar mejor el sistema operativo y una unidad de memoria ram) y luego hacer que su carpeta de postfix sea un disco RAM.

También sugeriría colocar sus registros de correo en su propia partición, si no en su propio disco por completo.

Este no es un problema de E / S, es un problema de configuración de postfix. Le está pidiendo que haga demasiado de una vez y se cree un cuello de botella. Consulte el archivo Léame de ajuste de rendimiento de postfix y / o publique su main.cf para que podamos ayudarlo.

Parece que tienes un disco poco fiable. Su servidor solo realiza 72 solicitudes de lectura / segundo y 42 de escritura / segundo. Mi unidad de disco duro de escritorio seagate 7200 RPM puede realizar más de 100 solicitudes de lectura / escritura aleatorias por segundo y aún así hacer frente.

Intente montar el carrete en sda y vea si la carga mejora.

Pero antes de gastar más dinero en el disco, haga lo siguiente:

1. Ejecute qshape activo, qshape diferido y qshape entrante y díganos el total de cada comando.

   Un número inusualmente alto de correo en cola diferida significa que su servidor de correo podría ser utilizado por spammer para retransmitir su correo no deseado (por ejemplo, enviar correo electrónico a un dominio inexistente que hará que su postfix vuelva a intentarlo una y otra vez).

2. Asegúrese de que su servidor de correo no esté en la lista negra ( http://www.mxtoolbox.com/blacklists.aspx )

3. Verifique el tiempo de respuesta de DNS y ejecute un caché de DNS local.

   El servidor de correo usa mucho el DNS. Do dig somedomain.com mx Run por encima de unos anfitriones diferentes. En general, el tiempo de respuesta debe ser inferior a 100 - 400 ms. Si obtiene una respuesta más alta, es posible que su DNS no funcione bien. Pruebe diferentes DNS (puede probar google 8.8.8.8 o OpenDNS: 208.67.222.222)

4. Revisa tu red. (por ejemplo, ifconfig) y ver cuántos paquetes de error. Comprueba si tu enlace está saturado o tiene forma. Verifique si hubo un alto número de operaciones de tiempo de espera en los registros de correo. Haga tcpdump y asegúrese de que los paquetes no se pierdan ni se vuelvan a transmitir.

5. ¿Puede decirnos si la consola responde (por ejemplo, cuando escribe algún comando, ¿qué tan rápido el sistema le da retroalimentación?)

   En general, los problemas de red (por ejemplo, DNS) harán que la carga se dispare, pero el sistema sigue respondiendo.