O que está acontecendo com o meu servidor? Carga alta, muito tempo de CPU inativo, baixa utilização de disco

Question

Eu gerencio um site e envio de newsletter por e-mail para assinantes. Tanto a hospedagem na web quanto o envio de e-mail são feitos pela mesma máquina.

Tenho cerca de 100.000 inscritos que optaram pelo meu boletim informativo diário por e-mail. Meu script PHP fez um bom trabalho enviando e-mails para todos eles até bem recentemente, mas à medida que a lista cresceu, não consegui acompanhar.

Quando corro na parte superior, tenho carga muito alta - geralmente pelo menos 6 ou 7, às vezes até 15 - mesmo que eu tenha apenas duas CPUs. No entanto, quando executo o sar, minha CPU fica inativa em média 30% do tempo. Então, parece que não estou ligado à 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 ligado à CPU ou ligado ao disco, porque é que o topo reporta uma carga tão elevada?

Além disso, como não pareço estar ligado à CPU ou ao disco vinculado, por que meu script de envio de e-mail não consegue acompanhar?

Veja o que eu vejo quando está no topo:

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

Veja o que eu vejo quando estou executando o 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

Veja o que vejo ao executar o 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 em que aconteceu a execução de 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, Dmitri!

1) Já tenho um script que cancela a inscrição de endereços de e-mail que foram rejeitados pelo menos cinco vezes no último mês, portanto, 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

Eu não sei o que o "-" significa no início de -/var/log/maillog , mas quando olho naquele arquivo, fica claro que muito está sendo registrado lá.

Além disso, muita coisa está sendo registrada neste arquivo:

/ var / log / exim_mainlog

Desde que adicionei ao /etc/exim.conf esta linha:

no_message_logs

Eu pensei que isso desabilitaria o log de mensagens (eu reiniciei o exim), mas quando eu olho para / var / log / maillog e em / var / log / exim_mainlog ambos os arquivos ainda estão recebendo novas entradas de log.

Pergunta: Como posso desabilitar a maioria / todos os registros de exim?

3) Quando eu olho em / var / log / exim_paniclog, vejo uma tonelada 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

Depois de procurar por um tempo, parece que isso significa que o Exim está tentando entregar o endereço de e-mail raiz. Qual é a melhor maneira de lidar com essas entregas de e-mail para o usuário root usando o mínimo possível de recursos da CPU?

    

Answer 1

Como a média de carga indicada 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 o comum 1 por regra geral do CPU.

Mail é praticamente o exemplo perfeito disso, cada processo precisa de CPU para enviar uma mensagem, mas muito, muito pouco. Eu vi sistemas de correio executando o sendmail em uma média de carga no intervalo de 25 a 35, e o sistema ainda é interativo e está funcionando bem.

Marcar

    

Answer 2

As métricas do sistema (carga, CPU, E / S) são geralmente os únicos indicadores que a maioria das pessoas tem do desempenho de seu sistema - no entanto, o desempenho transacional real é algo bem diferente. Essas métricas podem fornecer orientações sobre como o desempenho é restrito, mas na verdade é muito mais útil analisar quanto tempo as transações realmente levam.

why is my email sending script not able to keep up?

Isso significa que você está vendo problemas na fila de e-mails não estarem limpos? Ou é o período de tempo que o script leva para executar? Ou você está inferindo que há um problema baseado na carga alta?

Como mfarver diz, alta carga não é incomum nos sistemas de e-mail, particularmente com o aumento do número de verificações síncronas feitas pelos servidores de e-mail para evitar spam.

Pessoalmente, não sou muito fã do exim - tive experiências muito melhores com o sendmail e o postfix, embora admito que já faz vários anos desde que fiz testes sérios em MTAs. Certamente você está chegando ao ponto em que precisa ser muito mais sofisticado sobre o processamento de e-mail.

Em vez de desativar o registro, pode ser uma boa ideia adicionar temporariamente o encaminhamento para a conta raiz para ver exatamente o que são todos os emails que não estão sendo entregues.

Eu estou supondo que o MTA está configurado para enviar e-mail diretamente para seus destinatários. Se você tiver problemas de desempenho, considere o uso de um retransmissor inteligente para descarregar as mensagens do seu servidor mais rapidamente. Mas tente alternar o Exim para a fila apenas para ver se isso resolve o problema de carga (e, mais importante, qualquer desempenho) primeiro. 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, php mail () chama bloco por um longo tempo (mas de alguma forma as mensagens ainda são entregues?) se o MTA não pode se conectar ao host inteligente.

Muitos provedores de e-mail agora implementam a aceleração como um método de bloqueio de spam - enquanto a classificação da lista de e-mail por domínio ajudaria a reduzir as pesquisas de DNS, você pode acabar tendo problemas com a otimização de sistemas remotos ou bloqueio de e-mail. Certifique-se de que você está fazendo tudo de maneira prática para evitar parecer um spammer (por exemplo, SPF, DKIM) - o IIRC Exim não suporta diretamente milters - há muitos milters úteis disponíveis - especialmente milter-limit.

    

Answer 3

high load é o tamanho médio de run queue - por ex. processos que querem ser executados em cpu. Parece que o seu script faz muito trabalho de CPU. Então, você deve criar um perfil e postar aqui suas fontes. Como você envia cartas?

    

Answer 4

Em primeiro lugar, sua carga não é tão alta. A carga de 8 em 2 CPU significa uma carga de 4 por CPU. Também o CPU moderno é normalmente dual core, então é como 2 CPUs em um, então a carga é realmente mais parecida com 2 por CPU.

No que diz respeito ao processamento de e-mails, há duas coisas que você pode fazer para diminuir a carga: 1) verifique se há um script que processa os e-mails devolvidos para que você possa marcar um endereço de e-mail como 'saltando' enviar para esse endereço mais. A taxa de rejeição normal para uma grande lista de e-mail, até mesmo uma opção de inclusão, é de cerca de 20%. Os saltos realmente incomodam o servidor porque não apenas o servidor precisa enviar e-mails que as pessoas não vêem, mas também receber e processar os e-mails devolvidos.

2) Desabilite o logging para o maillog. Em uma lista de e-mails de alto volume, a entrada é adicionada ao maillog em todos os e-mails que saem, bem como em todos os e-mails devolvidos recebidos de volta. Escrever para o maillog é muito intensivo em recursos porque envolve gravações em disco. Simplesmente desabilitando o maillog você pode diminuir a carga do sistema em "muito", às vezes em até 50% Eu não sei qual servidor de e-mail você está usando, mas no Linux você normalmente procuraria no /etc/syslog.conf

Apenas comente a entrada de e-mail e reinicie o serviço syslog.

Mais uma coisa: os e-mails devolvidos geralmente voltam para a conta root. É muito comum um sistema atingir o limite de caixa de correio da conta raiz, que geralmente é de 100 MB. Quando o limite é atingido, você está iniciando outro problema em que não é possível aceitar e-mails devolvidos, portanto, o sistema pode estar enviando suas próprias mensagens devolvidas, adicionando ainda mais carga.

Conclusão: monitore sua rejeição e mantenha sua lista limpa - marque as contas de bouncning e não envie mais mensagens para elas.

    

Answer 5

Sua entrada no maillog está marcada para não flush em cada entrada. Isso deve ajudar a reduzir a sobrecarga da CPU nesse 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 ativou o uso do syslog.

Para reduzir o que está sendo registrado, adicione uma especificação log_selector à sua configuração. Os valores possíveis são detalhados na Especificação do Exim (provável capítulo 49). Embora, isso provavelmente não seja seu problema.

Tente executar exiwhat para ver quais entregas estão sendo tentadas. mailq não deve ter muitas mensagens esperando entrega e fer que estiveram na fila por uma hora ou mais. Uma longa lista de mensagens que estão na fila há algum tempo indica que você está tentando fazer entregas com probabilidade de serem devolvidas.

O Exim não lida com muitos processos de entrega funcionando simultaneamente bem. Você deve procurar mudanças nas configurações que possam ajudar.

• experimente aumentar os tempos entre novas tentativas e reduzir o tempo antes de você rejeitar as mensagens como não entregues. Isso reduzirá o número de tentativas necessárias para rejeitar mensagens não entregues.
• Desative tentativas de entrega imediata para que as entregas sejam executadas na fila. Você pode querer usar queue_only_load para fazer isso condicionalmente.
• Defina queue_run_max para limitar o número de processos de execução de fila.

Para resolver as tentativas de encaminhamento, você pode usar um transporte ou um alias. Eu alias root ao meu endereço de e-mail. O Ubuntu usa esse roteador para impedir que as entregas sejam executadas como root.

mail4root:
  debug_print = "R: mail4root for $local_part@$domain"
  driver = redirect
  domains = +local_domains
  data = /var/mail/mail
  file_transport = address_file
  local_parts = root
  user = mail
  group = mail