Desempenho do postfix

Question

Executando postfix no Ubuntu, enviando um monte de mensagens (~ 1 milhão de mensagens) por dia. As cargas são extremamente altas, mas não muito em termos de carga da CPU e memória. Alguém em uma situação semelhante e sabe como remover o gargalo?

Todos os e-mails neste servidor são de saída.

Eu teria que assumir que o gargalo é disco.

Apenas uma atualização, aqui está o 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

Esses números estão alinhados com o desempenho que você esperaria de um único disco?

sdb é dedicado ao postfix.

Eu acho que é o embaralhamento de filas, de entrada- > ativo- > diferido

Mais detalhes das perguntas:

Servidor: CPU Xeon (R) quad core E5405 @ 2.00GH com ram de 4 GB

Média da carga: 464,88, 489,11, 483,91, 4 núcleos. mas a utilização de memória e cpu é mínima

Instâncias de postfix entre 16 e 32

    

Answer 1

Isso pode parecer um pouco maluco, mas você deve:

1. Reduza o registro para o mínimo necessário. Faça com que o syslog registre somente mail.err ou superior.
2. Adicione mais RAM. Sim, o Postfix não precisa disso, mas RAM extra significa cache de página extra para o kernel.
3. Você não mencionou qual sistema de arquivos está em / dev / sdb (o que também é importante), mas mude definitivamente para noatime , o que deve reduzir a carga pelo menos um pouco.
4. Veja o tamanho do seu / var / spool / postfix. Se é sob um show de casal, considere movê-lo para um disco voador.

Answer 2

Eu tenho que discordar daqueles que sugeriram usar um disco RAM para "/ var / spool / postfix". Isso significa que toda a fila de mensagens será armazenada na RAM. Se o seu servidor travar ou perder energia, as mensagens na fila desaparecerão para sempre. Isso é muito ruim da perspectiva do cliente / usuário porque a mensagem já foi aceita com sucesso para entrega. Pior, seu servidor não enviará um aviso informando que um e-mail foi devolvido ou não pôde ser entregue porque a fila estará vazia quando o servidor voltar a funcionar.

Em vez disso, adiciono quantos discos velozes você puder pagar; Eu realmente não posso estimar quantos você precisará com a informação dada. A partir da saída "iostat" acima, parece que você está fazendo ~ 120 IOPS para 'sdb' (soma de r / s e w / s). Você pode estimar razoavelmente que um único disco SCSI ou FC de 15k RPM manipulará 150 IOPS. Gostaria de começar com 5 discos SCSI de 15k RPM e um controlador RAID decente. Configure-o como RAID-10 em 4 unidades com 1 hot spare. Eu não tenho certeza se isso vai resolver completamente o seu problema, mas definitivamente não vai piorar.

    

Answer 3

Execute o postfix em algum profiler (gprof?) ou examine os logs. O Postfix registra muitas informações de tempo que podem lhe dizer onde está o holdup. Lugares comuns para procurar são:

1. Desempenho do disco. Pode ser a hora do RAID-10 para sua fila.
2. Qualquer tipo de rede IO em mensagens. Listas negras de DNS? SAV?
3. Milters e outros filtros que você instalou.
4. Pesquisas de autenticação e UID realizadas na rede ou em um processo (ldap, sql).
5. não usando proxy: para mapas lentos (como o acima)

Answer 4

Um milhão de mensagens por dia é de cerca de 11 por segundo, supondo que a taxa de transferência seja constante. O postfix por si só deve ser capaz de lidar com pelo menos uma ordem de grandeza maior que a do hardware do servidor de nível de entrada. Então, eu suspeito que você tenha mais do que apenas postfix em execução, ou picos de taxa de transferência muito desigualmente distribuídos.

Sua situação certamente se parece com um servidor altamente vinculado a E / S. Isso é esperado com um MTA, que precisa fazer muitas pequenas gravações para garantir que ele não perca mensagens.

Reserve um tempo para ajustar a E / S nos dois /var/spool/postfix e /var/log . A prática recomendada para servidores postfix ocupados é separar os dois em eixos diferentes e certificar-se de que o log assíncrono esteja habilitado. prefixar o nome do arquivo de log para seu log de correio com um travessão no Linux.

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

ou similar.

Se você estiver usando o amavisd-new, certifique-se de que sua área de trabalho esteja em um sistema de arquivos tmpfs. Nós geralmente colocamos em /tmp/vscan/ . Isso é seguro, já que o amavisd-new não retorna uma resposta de fim de dados até que o salto downstream (pós-filtro) aceite a mensagem.

Algumas pessoas recomendam noatime opções de montagem para o spool postfix. Isso é potencialmente imprudente, devido à maneira como o postfix depende da semântica do sistema de arquivos. Veja por exemplo o link .

    

Answer 5

Definitivamente, parece que o subsistema de disco deve, pelo menos, ser visto como parte do problema. Devido à maneira como o postfix embaralha os arquivos em / var, eu sugeriria googling para "tweak ext3 filesystem" (pelo menos definindo noatime e writeback) para ver se você não pode aumentar o desempenho no nível do sistema de arquivos.

Eu tenho dois clusters de servidores que duplicam o DNS de serviço e o SMTP de saída para e-mail destinado ao cliente e executam 250k mensagens diariamente (2k-10k / hora) sem se aproximar desse tipo de conexão de E / S.

    

Answer 6

Parece um gargalo de desempenho de armazenamento para mim.

O iowait de 99.88 informa que seu sistema está gastando muito tempo aguardando seu armazenamento.

Eu concordo com Bill Weiss. Você deve procurar uma configuração do raid10 para a fila.

    

Answer 7

ou comece com

vmstat 1

"iostat 1" sugerido por moshen também é bom

do seu subsistema de disco claramente mais rápido seria agradável. raid-10 em 6-8 discos de 15k rpm talvez com algum cache, alguns gigs de memória on-board.

monte seu diretório de spool com opções noatime e nodiratime. considere ajustar ou alterar seu sistema de arquivos para lidar com muitos arquivos [i supostos] pequenos.

    

Answer 8

Brian

Você realmente precisa obter um disco mais rápido ou, de preferência, mudar para uma solução de ataque. Que tipo de servidor é esse?

James

    

Answer 9

Se você estiver executando o amavis para filtragem de vírus + spam, deverá aumentar o número de processos amavis concorrentes. De acordo com sua configuração, você pode precisar aumentar os números dos processos smtp-amavis a partir do postfix master.cf, e também a configuração relevante em amavis.conf.

    

Answer 10

Quantos núcleos na caixa e qual é a carga real? Qual é a taxa real em que você está recebendo as mensagens enviadas?

Como a maioria, meu primeiro pensamento é disco, então verifique isso.

No entanto, a utilização da rede pode ser a causa, pois pode haver alta carga de interrupção (cartão ruim?), portanto, verifique-as. Descobri que mesmo para um servidor de e-mail modesto, ter um servidor DNS de cache rápido (estou parcial para "desvinculado") na mesma caixa ajuda a aliviar a latência e a carga da rede.

    

Answer 11

com você fazendo 630 leituras e 1042 gravações por segundo, eu definitivamente sugiro aumentar sua memória no sistema (para lidar melhor com o sistema operacional e uma unidade de memória RAM) e, em seguida, tornar sua pasta postfix um disco.

Também sugeriria colocar seus registros de e-mail em sua própria partição, se não em seu próprio disco.

    

Answer 12

Este não é um problema de IO, é um problema de configuração do postfix. Você está pedindo para fazer tudo de uma vez e criar um gargalo para você mesmo. Confira o ajuste de desempenho do postfix leiame e / ou poste seu arquivo main.cf para que possamos ajudar.

    

Answer 13

parece que você tem um disco desonesto. Seu servidor fazendo apenas 72 solicitações de leitura / seg & 42 gravação / segundo. Meu HDD de desktop Seagate 7200 RPM pode fazer 100 + solicitações aleatórias de leitura / gravação por segundo e ainda lidar com isso.

Tente montar o carretel em sda e veja se a carga melhorou.

Mas antes de gastar mais dinheiro no disco, faça o seguinte:

1. Execute qshape active, qshape deferred e qshape incoming e nos informe o total de cada comando.

   Um número excepcionalmente alto de mensagens na fila adiada significa que seu servidor de e-mail pode ser usado pelo spammer para transmitir seu spam (por exemplo, enviar e-mail para domínios inexistentes, o que fará com que seu postfix tente novamente).

2. Verifique se o seu servidor de e-mail não está na lista negra ( link )

3. Verifique o tempo de resposta do DNS & Execute um cache DNS local.

   O servidor de email usa bastante o DNS. Faz dig somedomain.com mx Execute-o em alguns hosts diferentes. Geralmente o tempo de resposta deve ser menor que 100 - 400ms. Se você obtiver uma resposta maior, seu DNS pode não ter um bom desempenho. Experimente DNS diferente (você pode tentar o 8.8.8.8 do Google ou o OpenDNS: 208.67.222.222)

4. Verifique sua rede. (eg ifconfig) e ver quantos pacotes de erro. Verifique se o seu link está saturado ou em forma. Verifique se houve algum número alto de operações de tempo limite nos logs de mensagens. Faça o tcpdump e verifique se os pacotes não estão sendo perdidos ou retransmitidos.

5. Você pode nos dizer se o console é responsivo (por exemplo, quando você digita algum comando, quão rápido o sistema lhe dá feedback)?

   Geralmente, um problema de rede (por exemplo, DNS) fará com que a carga dispare, mas o sistema ainda responde.