Kra, valeu pelas dicas, isso ajudou bastante já ;) O gargalo eh gerado pelo amavis. Fiz os testes aqui e vejo que o postfix recebe o email e ele fica em fila esperando o amavis... O CPU esta com 40% livre +/- (tenho um problema aki, ele esta ficando cada vez mais 'cheio', ontem ele estava com 50% livre, mas isso eh outro problema :p) Estou muito desconfiado que seja disco mesmo, porem não entendo pq o uso do processador não varia. Ele fica praticamente sempre com 50% ocupado (não oscila em nada)... Bem, deixei direto por um tempo...os emails são instantaneos...nao para nada... Peguei o mail.log de ontem e vo ver quantos emails ele enviou/recebeu (so pra ter uma ideia, o arquivo tem aprox 100 Mb, so 1 dia)... Na verdade quero ter certeza que estou rodando com as configuracoes certa. A troca do hardware ira ocorrer, essa maquina eh somente para testes. O problema eh que nunca trabalhei com uma quantidade tao consideravel de trafego (na verdade esse servidor eh so um smarthost, ele entrega tudo pro Exchange). Bem, irei verificar, se tiver alguma ideia, agradeco. []'s Helio -----Mensagem original----- De: Marcos Vinicius Lazarini [mailto:lazarini@nics.unicamp.br] Enviada em: quarta-feira, 6 de abril de 2005 12:51 Para: Debian user portuguese list Assunto: Re: RES: Postfix+Amavis lento 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 debian-user-portuguese-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Attachment:
smime.p7s
Description: S/MIME cryptographic signature