Administro un sitio web y envío un boletín informativo diario por correo electrónico legítimo a los suscriptores. Tanto el alojamiento web como el envío de correo electrónico se realizan mediante la misma máquina.
Tengo alrededor de 100.000 suscriptores que han optado por recibir mi boletín diario por correo electrónico. Mi script PHP hizo un buen trabajo enviándoles correo a todos hasta hace poco, pero a medida que la lista ha crecido no puedo seguir el ritmo.
Cuando ejecuto top, tengo una carga muy alta, generalmente al menos 6 o 7, a veces hasta 15, aunque solo tengo dos CPU. Sin embargo, cuando ejecuto sar, mi CPU está inactiva en promedio aproximadamente el 30% del tiempo. Entonces, parece que no estoy limitado a la CPU. Cuando ejecuto iostat, parece que no estoy vinculado al disco porque mi % de utilidad para cada dispositivo es muy bajo (no más del 5%).
Dado que no parece estar vinculado a la CPU ni al disco,¿Por qué top informa una carga tan alta?
Además, dado que no parece estar vinculado a la CPU ni al disco,¿Por qué mi secuencia de comandos de envío de correo electrónico no puede mantenerse al día?
Esto es lo que veo cuando ejecuto la parte superior:
top - 11:33:28 up 74 days, 18:49, 2 users, load average: 7.65, 8.79, 8.28
Tasks: 168 total, 5 running, 162 sleeping, 0 stopped, 1 zombie
Cpu(s): 38.9%us, 58.6%sy, 0.8%ni, 0.0%id, 0.7%wa, 0.2%hi, 0.8%si, 0.0%st
Mem: 3083012k total, 2144436k used, 938576k free, 281136k buffers
Swap: 2048248k total, 39164k used, 2009084k free, 1470412k cached
Esto es lo que veo cuando ejecuto iostat -mx:
avg-cpu: %user %nice %system %iowait %steal %idle
34.80 1.20 55.24 0.37 0.00 8.38
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sda 0.19 71.70 1.59 29.45 0.02 0.07 5.90 0.55 17.82 1.16 3.59
sda1 0.00 0.00 0.00 0.00 0.00 0.00 7.10 0.00 13.80 13.72 0.00
sda2 0.05 50.45 1.13 24.57 0.01 0.29 24.25 0.35 13.43 1.15 2.97
sda3 0.05 10.17 0.20 2.33 0.01 0.05 43.75 0.05 20.96 2.45 0.62
sda4 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 70.50 70.50 0.00
sda5 0.07 0.22 0.03 0.07 0.00 0.00 32.84 0.08 856.19 8.03 0.08
sda6 0.02 5.45 0.03 0.72 0.00 0.02 67.55 0.02 26.72 5.26 0.39
sda7 0.00 1.56 0.00 0.42 0.00 0.01 38.04 0.00 8.88 5.84 0.24
sda8 0.01 3.84 0.20 1.35 0.00 0.02 28.55 0.05 31.90 4.08 0.63
Esto es lo que veo cuando ejecuto sar:
09:40:02 AM CPU %user %nice %system %iowait %steal %idle
09:50:01 AM all 30.59 1.01 49.80 0.23 0.00 18.37
10:00:08 AM all 31.73 0.92 51.66 0.13 0.00 15.55
10:10:06 AM all 30.43 0.99 48.94 0.26 0.00 19.38
10:20:01 AM all 29.58 1.00 47.76 0.25 0.00 21.42
10:30:01 AM all 29.37 1.02 47.30 0.18 0.00 22.13
10:40:06 AM all 32.50 1.01 52.94 0.16 0.00 13.39
10:50:01 AM all 30.49 1.00 49.59 0.15 0.00 18.77
11:00:01 AM all 29.43 0.99 47.71 0.17 0.00 21.71
11:10:07 AM all 30.26 0.93 49.48 0.83 0.00 18.50
11:20:02 AM all 29.83 0.81 48.51 1.32 0.00 19.52
11:30:06 AM all 31.18 0.88 51.33 1.15 0.00 15.47
Average: all 26.21 1.15 42.62 0.48 0.00 29.54
Aquí están los principales procesos enumerados en el momento particular que ejecuté top -c:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8180 mysql 16 0 57448 19m 2948 S 26.6 0.7 4702:26 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql --user=mysql --pid-file=/var/lib/mysql/bristno.pid --skip-external-locking
26956 brristno 17 0 0 0 0 Z 8.0 0.0 0:00.24 [php] <defunct>
26958 brristno 17 0 94408 43m 37m R 5.0 1.4 0:00.15 /usr/bin/php /home/brristno/public_html/dbv.php
22852 nobody 16 0 9628 2900 1524 S 0.7 0.1 0:00.17 /usr/local/apache/bin/httpd -k start -DSSL
8591 brristno 34 19 96896 13m 6652 S 0.3 0.4 0:29.82 /usr/local/bin/php /home/brristno/bin/mailer.php 1qwqyb6 i0gbor
24469 nobody 16 0 9628 2880 1508 S 0.3 0.1 0:00.08 /usr/local/apache/bin/httpd -k start -DSSL
25495 nobody 15 0 9628 2876 1500 S 0.3 0.1 0:00.06 /usr/local/apache/bin/httpd -k start -DSSL
26149 nobody 15 0 9628 2864 1504 S 0.3 0.1 0:00.04 /usr/local/apache/bin/httpd -k start -DSSL
¡Gracias Dmitri!
1) Ya tengo un script que cancela la suscripción de direcciones de correo electrónico que han rebotado al menos cinco veces en el último mes, así que espero que eso mantenga mi lista relativamente limitada a direcciones de correo electrónico activas.
2) Estoy usando exim 4.69. Mi archivo de configuración está en
/etc/exim.conf
y mis archivos de registro están en:
/var/log/exim_mainlog
/var/log/exim_paniclog
/var/log/exim_rejectlog
Además, cuando miro en /etc/syslog.conf, veo lo siguiente:
# Log all the mail messages in one place.
mail.* -/var/log/maillog
No sé qué significa "-" al principio, -/var/log/maillogpero cuando miro ese archivo queda claro que se están registrando muchas cosas allí.
Además, se registran muchas cosas en este archivo:
/var/log/exim_mainlog
Desde entonces agregué a /etc/exim.conf esta línea:
no_message_logs
Pensé que eso deshabilitaría el registro de correo (reinicié exim), pero cuando miro /var/log/maillog y /var/log/exim_mainlog ambos archivos todavía reciben nuevas entradas de registro.
Pregunta:¿Cómo puedo desactivar la mayoría o todos los registros de exim?
3) Cuando miro en /var/log/exim_paniclog, veo un montón de entradas como esta:
2010-12-19 04:03:32 1PUFB1-0006xZ-GF User 0 set for local_delivery transport is on the never_users list
Después de mirar a su alrededor por un tiempo, parece que eso significa que exim está intentando realizar entregas a la dirección de correo electrónico raíz.¿Cuál es la mejor manera de manejar estas entregas de correo a root utilizando la menor cantidad de recursos de CPU posible?
Respuesta1
Como se señaló, el promedio de carga está relacionado con la cantidad de procesos en espera en la cola de ejecución. Si cada uno de esos procesos tiene muy poco trabajo que hacer y libera el procesador rápidamente, puede manejar promedios de carga mucho mayores que la regla general común de 1 por CPU.
El correo es prácticamente el ejemplo perfecto de esto, cada proceso necesita CPU para enviar un mensaje, pero muy, muy poca. He visto sistemas de correo ejecutando sendmail con una carga promedio en el rango de 25 a 35, y el sistema aún es interactivo y funciona bien.
Marca
Respuesta2
Las métricas del sistema (carga, CPU, E/S) son a menudo los únicos indicadores que la mayoría de la gente tiene del rendimiento de su sistema; sin embargo, el rendimiento transaccional real es algo bastante diferente. Estas métricas pueden proporcionar orientación sobre cómo se limita el rendimiento, pero en realidad es mucho más útil observar cuánto tiempo tardan realmente las transacciones.
¿Por qué mi secuencia de comandos de envío de correo electrónico no puede mantenerse al día?
¿Eso significa que está viendo problemas con la cola de correo que no se aclara? ¿O es el tiempo que tarda en ejecutarse el script? ¿O está infiriendo que hay un problema debido a la alta carga?
Como dice mfarver, una carga elevada no es infrecuente en los sistemas de correo electrónico, particularmente con el creciente número de comprobaciones sincrónicas realizadas por los servidores de correo para evitar el spam.
Personalmente, no soy un gran admirador de exim; he tenido experiencias mucho mejores con sendmail y postfix, aunque admito que han pasado varios años desde que hice pruebas serias con los MTA. Ciertamente, está entrando en el estadio en el que necesita ser mucho más sofisticado en el procesamiento de correo electrónico.
En lugar de desactivar el registro, podría ser una buena idea agregar temporalmente el reenvío para la cuenta raíz para ver exactamente de qué se tratan todos esos correos electrónicos que no se entregan.
Supongo que el MTA está configurado para enviar correo directamente a sus destinatarios. Si tiene problemas de rendimiento, podría considerar utilizar un relé inteligente para descargar mensajes de su servidor más rápido. Pero intente cambiar Exim a cola solo para ver si esto resuelve primero el problema de carga (y, más importante, cualquier problema de rendimiento). Además, eche un vistazo a su almacenamiento en caché de DNS y vea si se puede mejorar.
Si ya está utilizando un relé inteligente, verifique que esté configurado correctamente: IME, con una configuración basada en sendmail, las llamadas de php mail() se bloquean durante mucho tiempo (¿pero de alguna manera los mensajes aún se entregan?) si el MTA no puede conéctese al host inteligente.
Muchos proveedores de correo electrónico ahora implementan la limitación como método de bloqueo de spam; si bien ordenar la lista de correo electrónico por dominio ayudaría a reducir las búsquedas de DNS, podría terminar teniendo problemas con los sistemas remotos que limitan o bloquean el correo. Asegúrese de hacer todo lo práctico para evitar parecer un spammer (por ejemplo, SPF, DKIM). IIRC Exim no admite directamente milters; hay muchos milters útiles disponibles, en particular milter-limit.
Respuesta3
high loades el tamaño medio de run queue, por ejemplo, procesos que desean ejecutarse en la CPU. Parece que tu script hace mucho trabajo con la CPU. Por lo tanto, debes perfilarlo y publicar aquí sus fuentes. ¿Cómo se envían cartas?
Respuesta4
La entrada de su registro de correo está marcada para no vaciarse en cada entrada. Esto debería ayudar a reducir la sobrecarga de la CPU al escribir en este registro. Sin embargo, como utiliza Exim, este registro no se utiliza de forma predeterminada. Verifique su configuración para asegurarse de no haber habilitado el uso de syslog.
Para reducir lo que se registra, agregue una log_selectorespecificación a su configuración. Los valores posibles se detallan en la Especificación Exim (probablemente el capítulo 49). Aunque probablemente este no sea tu problema.
Intente ejecutar exiwhatpara ver qué entregas se están intentando. mailqNo debería haber muchos mensajes en espera de entrega ni mensajes que hayan estado en la cola durante una hora o más. Una larga lista de mensajes que han estado en la cola durante un tiempo indica que estás intentando realizar entregas que probablemente reboten.
Exim no maneja bien muchos procesos de entrega que se ejecutan simultáneamente. Debería buscar cambios en las configuraciones que puedan ayudar.
- Intente aumentar los tiempos entre reintentos y reducir el tiempo antes de rebotar mensajes como no entregados. Esto reducirá la cantidad de intentos necesarios para rebotar mensajes que no se pueden entregar.
- Desactive los intentos de entrega inmediata para que las entregas se ejecuten desde la cola. Es posible que desee utilizar
queue_only_loadpara hacer esto de forma condicional. - Establecido
queue_run_maxpara limitar el número de procesos de ejecución de cola.
Para resolver los intentos de entregas para enrutar tu puedes utilizar un transporte o un alias. Pongo un alias de root en mi dirección de correo electrónico. Ubuntu usa este enrutador para evitar que las entregas se ejecuten como root.
correo4root: debug_print = "R: mail4root para $local_part@$dominio" conductor = redirigir dominios = +dominios_locales datos = /var/correo/correo transporte_archivo = dirección_archivo local_parts = raíz usuario = correo grupo = correo