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.html
O 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
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
