Desempenho do Postfix

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

Todo o correio neste servidor é de saída.

Eu teria que assumir que o gargalo é o disco.

Apenas uma atualização, eis a aparência do 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 é embaralhar fila, de entrada-> ativo-> adiado

Mais detalhes das perguntas:

Servidor: CPU Quad core Xeon (E5) E5405 a 2.00GH com 4 GB de RAM

Média de carga: 464.88, 489.11, 483.91, 4 núcleos. mas a utilização de memória e a CPU são mínimas

Instâncias de Postfix entre 16 e 32

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

1. Reduza o log para o mínimo necessário. Crie syslog apenas para registrar mail.err ou superior.
2. Adicione mais RAM. Sim, o Postfix não precisa, 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 também), mas definitivamente mude para noatime, o que deve reduzir a carga pelo menos um pouco.
4. Veja quão grande é seu / var / spool / postfix. Se estiver em um show, considere movê-lo para um ramdisk.

Eu tenho que discordar daqueles que sugeriram o uso de um disco RAM para "/ var / spool / postfix". Isso significa que toda a sua fila de emails será armazenada na RAM. Se o 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 êxito para entrega. Pior, seu servidor não enviará um aviso informando que um email foi devolvido ou não pôde ser entregue porque a fila ficará vazia quando o servidor voltar a funcionar.

Em vez disso, eu adicionaria quantos discos rápidos você puder pagar; Eu realmente não posso estimar quantos você precisará com as informações fornecidas. A partir da saída "iostat" acima, parece que você está fazendo ~ 120 IOPS para 'sdb' (soma de r / sew / s). Você pode razoavelmente estimar que um único disco SCSI ou FC de 15k RPM processará 150 IOPS. Eu começaria com 5 discos SCSI de 15k RPM e um controlador RAID decente. Configure-o como RAID-10 em 4 unidades com 1 hot spare. Não tenho certeza de que isso resolverá completamente o seu problema, mas definitivamente não o tornará pior.

Execute o postfix em algum criador de perfil (gprof?) Ou procure nos logs. O Postfix registra muitas informações de tempo que podem indicar onde está o atraso. Lugares comuns para procurar são:

1. Desempenho do disco. Pode ser a hora do RAID-10 para sua fila.
2. Qualquer tipo de E / S de rede nas mensagens. Listas negras de DNS? SAV?
3. Milters e outros filtros que você instalou.
4. Pesquisas de autenticação e UID sendo feitas pela rede ou para um processo (LDAP, SQL).
5. não usa proxy: para mapas lentos (como o acima)

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

Sua situação certamente parece um servidor fortemente ligado a E / S. Isso é de se esperar com um MTA, que precisa fazer muitas gravações pequenas para garantir que ele não perderá correio.

Reserve um tempo para ajustar a E / S em ambos /var/spool/postfixe /var/log. A melhor prática para servidores postfix ocupados é separar os dois em eixos diferentes e garantir que o log assíncrono esteja ativado. prefixe o nome do arquivo de log para seu log de correio com um traço no Linux.

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

ou similar.

Se você estiver usando o amavisd-new, verifique se a área de trabalho está em um sistema de arquivos tmpfs. Costumamos colocá-lo /tmp/vscan/. Isso é seguro, pois o amavisd-new não retorna uma resposta de final de dados até que o salto a jusante (pós-filtro) aceite a mensagem.

Algumas pessoas recomendam noatimeopçõ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, http://archives.neohapsis.com/archives/postfix/2006-01/1916.html .

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

Eu tenho dois clusters de servidores que dobram o DNS de serviço e o SMTP de saída para email destinado ao cliente e executam 250k mensagens diariamente (2k-10k / hora), sem chegar perto desse tipo de ligação de E / S.

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 raid10 para a fila.

ou comece com

vmstat 1

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

a partir de suas estatísticas, o subsistema de disco claramente mais rápido seria bom. RAID-10 em discos de 6-8 a 15k RPM, talvez com algum cache, alguns shows de memória a bordo.

monte seu diretório de spool com as opções noatime, nodiratime. considere ajustar ou alterar seu sistema de arquivos para lidar com muitos arquivos pequenos [eu assumo].

Brian

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

James

Se você estiver executando o amavis para filtragem de spam e vírus, aumente o número de processos simultâneos do amavis. De acordo com sua configuração, pode ser necessário aumentar o número de processos smtp-amavis do postfix master.cf e também a configuração relevante no amavis.conf.

Quantos núcleos na caixa e qual é a carga real? Qual é a taxa real de recebimento de mensagens?

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

No entanto, a utilização da rede pode ser a causa, assim como a alta carga de interrupção (cartão defeituoso?), Portanto verifique-os. Descobri que, mesmo para um servidor de correio modesto, ter um servidor DNS com cache rápido (sou parcial para "não estar ligado") na mesma caixa ajuda a aliviar a latência e a carga da rede.

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 ram) e depois tornar sua pasta postfix um ramdisk.

Também sugeriria colocar seus logs de correio em sua própria partição, se não inteiramente em seu próprio disco.

Este não é um problema de IO, é um problema de configuração do postfix. Você está pedindo para fazer muita coisa de uma só vez e criando um gargalo para si mesmo. Confira o leia-me do ajuste de desempenho do postfix e / ou publique o arquivo main.cf para que possamos ajudar.

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

Tente montar o carretel na sda e veja se a carga melhora.

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

1. Execute qshape active, qshape adiado e qshape de entrada e informe-nos o total de cada comando.

   Um número invulgarmente alto de mensagens na fila adiada significa que o servidor de email pode ser usado pelo remetente de spam para retransmitir o spam (por exemplo, enviar email para um domínio inexistente, o que fará com que o seu postfix tente novamente várias vezes).

2. Verifique se o servidor de email não está na lista negra ( http://www.mxtoolbox.com/blacklists.aspx )

3. Verifique o tempo de resposta do DNS e execute um cache DNS local.

   O servidor de correio usa muito o DNS. Do dig somedomain.com mx executá-lo sobre alguns servidores diferentes. Geralmente, o tempo de resposta deve ser menor que 100 - 400ms. Se você receber uma resposta mais alta, seu DNS pode não ter um bom desempenho. Tente DNS diferente (você pode tentar o 8.8.8.8 do Google ou o OpenDNS: 208.67.222.222)

4. Verifique sua rede. (por exemplo, ifconfig) e veja quantos pacotes de erros. Verifique se o seu link está saturado ou com formato. Verifique se houve algum número alto de operações de tempo limite nos logs de mensagens. Faça 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, com que rapidez o sistema fornece feedback)?

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