Eu administro um site e envio um boletim informativo diário legítimo por e-mail aos assinantes. Tanto a hospedagem na web quanto o envio de e-mail são feitos pela mesma máquina.
Tenho cerca de 100.000 assinantes que optaram por receber meu boletim informativo diário por e-mail. Meu script PHP fez um ótimo trabalho enviando e-mails para todos eles até recentemente, mas como a lista cresceu, não consigo acompanhar.
Quando executo o top, tenho uma carga muito alta - geralmente pelo menos 6 ou 7, às vezes até 15 - mesmo tendo apenas duas CPUs. No entanto, quando executo o sar, minha CPU fica ociosa em média cerca de 30% do tempo. Então, parece que não estou vinculado à CPU. Quando executo o iostat, parece que não estou vinculado ao disco porque meu %util para cada dispositivo é muito baixo (não mais que 5%).
Dado que não pareço estar vinculado à CPU ou ao disco,por que os relatórios principais estão com uma carga tão alta?
Além disso, como não pareço estar vinculado à CPU ou ao disco,por que meu script de envio de e-mail não consegue acompanhar?
Aqui está o que vejo ao executar top:
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
Aqui está o que vejo ao executar 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
Aqui está o que vejo ao executar 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
Aqui estão os principais processos listados no momento específico em que executei 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
Obrigado, Dimitri!
1) Já tenho um script que cancela a assinatura de endereços de e-mail que foram devolvidos pelo menos cinco vezes no mês passado, então espero que isso mantenha minha lista relativamente limitada a endereços de e-mail ativos.
2) Estou usando o exim 4.69. Meu arquivo de configuração está em
/etc/exim.conf
e meus arquivos de log estão em:
/var/log/exim_mainlog
/var/log/exim_paniclog
/var/log/exim_rejectlog
Além disso, quando olho em /etc/syslog.conf, vejo o seguinte:
# Log all the mail messages in one place.
mail.* -/var/log/maillog
Não sei o que significa "-" no início, -/var/log/maillogmas quando olho nesse arquivo fica claro que muita coisa está sendo registrada lá.
Além disso, muita coisa está sendo registrada neste arquivo:
/var/log/exim_mainlog
Desde então, adicionei esta linha ao /etc/exim.conf:
no_message_logs
Achei que isso desabilitaria o registro de e-mail (reiniciei o exim), mas quando olho para /var/log/maillog e /var/log/exim_mainlog ambos os arquivos ainda estão recebendo novas entradas de log.
Pergunta:Como posso desabilitar a maioria/todos os logs do exim?
3) Quando olho em /var/log/exim_paniclog, vejo muitas 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
Depois de olhar em volta por um tempo, parece que isso significa que o exim está tentando entregar no endereço de e-mail raiz.Qual é a melhor maneira de lidar com essas entregas de e-mail para root usando o mínimo possível de recursos de CPU?
Responder1
Conforme observado, a média de carga está relacionada ao número de processos em espera na fila de execução. Se cada um desses processos tiver muito pouco trabalho a fazer e liberar o processador rapidamente, você poderá lidar com médias de carga muito maiores do que a regra prática comum de 1 por CPU.
Mail é praticamente o exemplo perfeito disso, cada processo precisa de CPU para enviar uma mensagem, mas muito, muito pouco. Já vi sistemas de e-mail executando o sendmail com uma carga média na faixa de 25 a 35, e o sistema ainda é interativo e funciona bem.
Marca
Responder2
As métricas do sistema (carga, CPU, E/S) são frequentemente os únicos indicadores que a maioria das pessoas tem do desempenho do seu sistema - no entanto, o desempenho transacional real é algo bem diferente. Essas métricas podem fornecer orientação sobre como o desempenho é limitado, mas na verdade é muito mais útil observar quanto tempo as transações realmente levam.
por que meu script de envio de e-mail não consegue acompanhar?
Isso significa que você está tendo problemas com a fila de e-mails que não está sendo limpa? Ou é o tempo que o script leva para ser executado? Ou você está inferindo que há um problema baseado na alta carga?
Como diz mfarver, alta carga não é incomum em sistemas de e-mail, especialmente com o número crescente de verificações síncronas feitas por servidores de e-mail para evitar spam.
Pessoalmente, não sou um grande fã do exim - tive experiências muito melhores com o sendmail e o postfix, embora admita que já se passaram vários anos desde que fiz testes sérios em MTAs. Certamente você está chegando ao ponto em que precisa ser muito mais sofisticado no processamento de e-mail.
Em vez de desativar o registro, pode ser uma boa ideia adicionar temporariamente o encaminhamento para a conta root para ver exatamente do que se tratam todos os e-mails que não estão sendo entregues.
Suponho que o MTA esteja configurado para enviar mensagens diretamente aos destinatários. Se você tiver problemas de desempenho, considere usar um retransmissor inteligente para descarregar mensagens do seu servidor mais rapidamente. Mas tente mudar o Exim para a fila apenas para ver se isso resolve primeiro o problema de carga (e, mais importante, qualquer desempenho). Além disso, dê uma olhada no seu cache DNS e veja se ele pode ser melhorado.
Se você já estiver usando um retransmissor inteligente, verifique se ele está configurado corretamente - IME, com uma configuração baseada em sendmail, as chamadas php mail() são bloqueadas por um longo tempo (mas de alguma forma as mensagens ainda são entregues?) se o MTA não puder conecte-se ao host inteligente.
Muitos provedores de e-mail agora implementam a limitação como um método de bloqueio de spam - embora a classificação da lista de e-mail por domínio ajudasse a reduzir as pesquisas de DNS, você pode acabar tendo problemas com a limitação ou bloqueio de e-mails de sistemas remotos. Certifique-se de fazer tudo o que for prático para evitar parecer um spammer (por exemplo, SPF, DKIM) - IIRC Exim não oferece suporte direto a milters - há muitos milters úteis disponíveis - notavelmente milter-limit.
Responder3
high loadé o tamanho médio de run queue- por exemplo, processos que desejam ser executados na CPU. Parece que seu script faz muito trabalho de CPU. Então, você deve traçar um perfil e postar aqui suas fontes. Como você envia cartas?
Responder4
Sua entrada de maillog está marcada para não ser liberada em cada entrada. Isso deve ajudar a reduzir a sobrecarga da CPU ao gravar neste log. No entanto, como você está usando o Exim, esse log não é usado por padrão. Verifique sua configuração para garantir que você não habilitou o uso do syslog.
Para reduzir o que está sendo registrado, adicione uma log_selectorespecificação à sua configuração. Os valores possíveis estão detalhados na Especificação Exim (provavelmente capítulo 49). Embora isso provavelmente não seja problema seu.
Tente correr exiwhatpara ver quais entregas estão sendo tentadas. mailqnão deve haver muitas mensagens aguardando entrega e que estejam na fila há uma hora ou mais. Uma longa lista de mensagens que estão na fila há algum tempo indica que você está tentando entregas que provavelmente serão devolvidas.
O Exim não lida bem com muitos processos de entrega executados simultaneamente. Você deve procurar alterações nas configurações que podem ajudar.
- tente aumentar o tempo entre as tentativas e reduzir o tempo antes de você devolver as mensagens como não entregues. Isso reduzirá o número de tentativas necessárias para devolver mensagens não entregues.
- Desative as tentativas de entrega imediata, para que as entregas sejam executadas a partir da fila. Você pode querer usar
queue_only_loadpara fazer isso condicionalmente. - Configure
queue_run_maxpara limitar o número de processos do executor de filas.
Para resolver as tentativas de entrega para rotear você pode usar um transporte ou um alias. Eu alias root para meu endereço de e-mail. O Ubuntu usa este roteador para evitar que entregas sejam executadas como root.
mail4root: debug_print = "R: mail4root para $local_part@$domain" motorista = redirecionar domínios = +domínios_locais dados = /var/mail/mail arquivo_transporte = endereço_arquivo partes_locais = raiz usuário = email grupo = correio