☰

Rendimiento de sufijo

tag-icon • tag-icon performance postfix performance-tuning
Rendimiento de sufijo

Ejecutando postfix en ubuntu, enviando una gran cantidad de 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.

Sólo 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 se esperaría de un solo disco?

sdb está dedicado a postfix.

Creo que es una cola aleatoria, desde entrante->activo->diferido

Más detalles de las preguntas:

Servidor: CPU Xeon(R) de cuatro núcleos E5405 a 2,00 GH con 4 GB de RAM

Promedio de carga: 464,88, 489,11, 483,91, 4 núcleos. pero la utilización de la memoria y la CPU es mínima

Instancias de Postfix entre 16 y 32

Respuesta1

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

  1. Reduzca el registro al mínimo necesario. Haga que syslog solo registre mail.err o superior.
  2. Añade más RAM. Sí, Postfix no lo necesita, pero RAM adicional significa caché de página adicional para el kernel.
  3. No mencionaste qué sistema de archivos hay en /dev/sdb (lo cual también importa), pero definitivamente cámbialo a noatime, lo que debería reducir la carga al menos un poco.
  4. Vea qué tan grande es su /var/spool/postfix. Si tiene menos de un par de funciones, considere moverlo a un disco RAM.

Respuesta2

No estoy de acuerdo con aquellos que han sugerido 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 se queda sin energía, los mensajes en la cola desaparecerán para siempre. Esto es realmente malo desde la perspectiva del cliente/usuario porque el mensaje ya ha sido aceptado exitosamente para su entrega. Peor aún, su servidor no enviará un aviso indicando que un correo electrónico rebotó o no pudo entregarse porque la cola estará vacía cuando el servidor vuelva a funcionar.

En lugar de eso, agregaría tantos discos rápidos como pueda permitirse; Realmente no puedo estimar cuántos necesitarás con la información proporcionada. Según el resultado "iostat" anterior, parece que estás haciendo ~ 120 IOPS a 'sdb' (suma de r/s y 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á.

Respuesta3

Ejecute postfix con algún generador de perfiles (gprof?) o busque en los registros. Postfix registra mucha información de tiempo que podría indicarle dónde está el retraso. Los lugares comunes para buscar son:

  1. Rendimiento del disco. Quizás sea el momento de incorporar RAID-10 a su cola.
  2. Cualquier tipo de IO de red en mensajes. ¿Listas negras de DNS? ¿SAV?
  3. Milters y otros filtros que haya instalado.
  4. Autenticación y búsquedas de UID que se realizan a través de la red o en un proceso (ldap, sql).
  5. no usar proxy: para mapas lentos (como el anterior)

Respuesta4

Definitivamente parece que su subsistema de disco al menos debería considerarse como parte del problema. Debido a la forma en que Postfix mezcla los archivos alrededor de /var, sugeriría buscar en Google "modificar el sistema de archivos ext3" (al menos configurando noatime y writeback) para ver si no se puede aumentar el rendimiento a nivel del sistema de archivos.

Tengo dos grupos de servidores que duplican la función DNS y SMTP saliente para el correo electrónico destinado al cliente y ejecutan 250.000 mensajes diarios (2.000-10.000/hora) sin ningún tipo de enlace de E/S.

información relacionada