Desempenho pós-fixado

Question

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

Todas as mensagens neste servidor são enviadas.

Eu teria que assumir que o gargalo é o disco.

Apenas uma atualização, aqui está 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 de acordo com o desempenho que você esperaria de um único disco?

sdb é dedicado ao postfix.

Eu acho que é embaralhamento de fila, de entrada-> ativo-> adiado

Mais detalhes das perguntas:

Servidor: CPU Quad core Xeon(R) E5405 @ 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 CPU é mínima

Instâncias Postfix entre 16 e 32

Answer 1

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

1. Reduza o registro ao mínimo necessário. Faça com que o syslog registre apenas 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 definitivamente mude para noatime, o que deve reduzir a carga pelo menos um pouco.
4. Veja o tamanho do seu /var/spool/postfix. Se estiver em alguns shows, considere movê-lo para um disco RAM.

Answer 2

Tenho que discordar daqueles que sugeriram o uso de um disco RAM para "/var/spool/postfix". Isso significa que toda a sua fila de e-mail será armazenada na RAM. Se o seu servidor travar ou ficar sem energia, as mensagens na fila desaparecerão para sempre. Isso é muito ruim do ponto de vista do cliente/usuário porque a mensagem já foi aceita para entrega com sucesso. Pior ainda, 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, eu adicionaria quantos discos rápidos você puder pagar; Não consigo estimar quantos você precisará com as informações fornecidas. Pela 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 suportará 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 se isso resolverá completamente o seu problema, mas definitivamente não irá piorá-lo.

Answer 3

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

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

Answer 4

Definitivamente parece que o seu subsistema de disco deveria pelo menos ser visto como parte do problema. Devido à maneira como o postfix embaralha os arquivos em /var, sugiro pesquisar no Google por "ajustar o sistema de arquivos ext3" (pelo menos configurando noatime e writeback) para ver se você não consegue aumentar o desempenho no nível do sistema de arquivos.

Eu tenho dois clusters de servidores que duplicam o DNS e o SMTP de saída para e-mails destinados ao cliente e executam 250 mil mensagens diariamente (2 mil a 10 mil/hora) sem nenhum tipo de ligação de E/S.