Helio Jose Poffo Junior wrote:
Ola... Demanha ate as 9:15 quando o envio e recebimento esta fora do pico ele da conta, a partir das 9:15 ate aproximadamente 12:00 ele apanha (demora uns 10 min pro email chegar ao destino). load average: 3.38, 4.59, 4.65 (esse load average é de agora, horario ainda com pouco pico) De manha o average rodava praticamente de 7 chegando a 9 (o disco devia estar colado já :p)
O load average diz mais ou menos, o numero de processos que estão disputando a fila do escalonador de processos. Ou seja, vc já chegou a ter 9 processos disputando tempo de execução... eu diria que isso é bem maior que o aceitável. Até uns 3 ou 4 por algum tempo ainda tá razoável, mais que isso significa que sua CPU não está dando conta.
Que tal se voce removesse o amavis por algum tempo, talvez por uma meia hora, pra observar o impacto no uso de CPU? Seria muito arriscado? Veja mais comentários abaixo...
Minhas configuracoes do MTA (postfix):
---master.cf---
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - 50 smtpd
#submission inet n - n - - smtpd
# -o smtpd_etrn_restrictions=reject
#628 inet n - n - - qmqpd
pickup fifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
rewrite unix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 300 0 flush
proxymap unix - - n - - proxymap
smtp unix - - n - 50 smtp
relay unix - - n - - smtp
# -o smtp_helo_timeout=5 -o smtp_connect_timeout=5
showq unix n - n - - showq
error unix - - n - - error
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
---master.cf---
--- main.cf ---
content_filter = smtp-amavis:[127.0.0.1]:10024
soft_bounce = yes
smtpd_helo_required = yes
smtpd_banner = $myhostname ESMTP $mail_name
biff = no
smtpd_helo_restrictions =
reject_invalid_hostname
smtpd_sender_restrictions =
permit_mynetworks,
reject_unknown_sender_domain,
reject_invalid_hostname,
reject_unauth_destination,
reject_non_fqdn_sender,
reject_unknown_recipient_domain
smtpd_client_restrictions =
permit_mynetworks,
reject_rbl_client relays.ordb.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.mail-abuse.org
smtpd_recipient_restrictions =
permit_auth_destination,
permit_mynetworks,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_non_fqdn_recipient
setgid_group = postdrop
biff = no
strict_rfc821_envelopes = yes
myhostname = mail.xxx.com.br
mydomain = xxx.com.br
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
transport_maps = hash:/etc/postfix/transport
myorigin = $mydomain
mydestination = localhost.$mydomain, localhost, $myhostname, $mydomain
mynetworks = 127.0.0.0/8
mynetworks_style = host
local_recipient_maps =
recipient_delimiter = +
--- main.cf ---
Já faz um tempo que eu não manjo tanto assim de postfix, mas fui capaz de achar esse documento:
http://www.postfix.org/TUNING_README.htmlO problema é que vc tem que saber quem está sendo o gargado do seu sistema. Pode ser a CPU mesmo (por causa do amavis), pode ser o acesso em disco (talvez o amavis esteja gravando muita coisa em disco e isso segura tudo), pode ser o postfix que entrega e-mails muito lentamente, ou limita em poucas conexoes simultaneas... são muitas variáveis, e o que voce deveria fazer é identificar os principais vilões da história.
Algumas coisas que eu penso agora: vc pode aumentar o numero de 'workers' pre-carregados pra processar os e-mails, eventualmente implementar um processo de fila que entrega os e-mails de 2 em 2 min pra aproveitar e entregar e-mails de mesmo domínio de uma só vez (tipo grandes provedores como UOL, yahoo, etc); colocar HDs separados para os programas e o TEMP usado pelo amavis/postfix; e eventualmente, até mesmo, reduzir algumas restrições.
As vezes a gente gasta um tempão tentanto otimizar parametros do sistema pra ter um ganho de 10%; quando uma outra atitude simples ajudaria muito mais (ex: se trocasse o HD por um mais rápido, ou usasse RAID, o desempenho subiria em 30%). O importante realmente é detectar quem está sendo o gargalo.
-----Mensagem original----- Fazendo uma continha rápida: 300000 por dia -> 12500 por hora -> 208,3 por minuto -> 3,472 por segundo
-- Marcos