[FUG-BR] RES: Problema Indefinido

[Paulo Henrique]

Em 6 de fevereiro de 2013 19:06, Marcelo Gondim <gondim em bsdinfo.com.br>escreveu:

> Em 06/02/13 14:17, Paulo Quartieri escreveu:
> >
> >> -----Mensagem original-----
> >> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> >> nome de Marcelo Gondim
> >> Enviada em: quarta-feira, 6 de fevereiro de 2013 10:10
> >> Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> >> Assunto: Re: [FUG-BR] Problema Indefinido
> >>
> >> Em 06/02/13 08:34, Paulo Quartieri escreveu:
> >>> À quem ajudar possa
> >>>
> >>> Tenho um servidor com FREEBSD 9.0 current 2 com Postfix + Mysql +
> >>> dovecot + roundcube (desabilitei o spamassassin por enquanto),
> >> apache,
> >>> etc.. que estava funcionando sem problemas por vários anos mas de
> >>> novembro/2012 em diante começou a acontecer o seguinte problema, que
> >>> não sei diagnosticar (por pura incompetência), e por isto peço
> >> auxilio à lista:
> >>> De tempo em tempo, aleatoriamente, as conexões com o banco de dados
> >>> ficam 'retesados' (consulto as conexões ativas no Mysql e são
> >>> centenas) e depois de alguns minutos volta ao normal. Neste intervalo
> >>> os clientes não conseguem enviar emails e o servidor recusa muitos
> >>> emails de outros servidores. Noto pelos log's que o problema pode ser
> >>> o Mysql, mas não chego a uma conclusão definitiva. Já atualizei o
> >>> Postfix, Postgrey, mudei diversas vezes a configuração do postfix e
> >> do
> >>> mysql e simplesmente não consigo resolver. Este problema começou a
> >>> acontecer, coincidentemente, após o começo de utilização da porta
> >> 587/465 para pop. Mas pode ser coincidência.
> >>> Se alguém puder ajudar, fico agradecido.
> >>>
> >>> Obrigado
> >>> Paulo Quartieri
> >>>
> >>> ERRO que recebo por email:
> >>>
> >>> Out: 220 qbserver4.qbnet.com.br ESMTP Postfix
> >>>    In:  EHLO qa3.leadsdemarketing.com
> >>>    Out: 250-qbserver4.qbnet.com.br
> >>>    Out: 250-PIPELINING
> >>>    Out: 250-SIZE 20480000
> >>>    Out: 250-VRFY
> >>>    Out: 250-ETRN
> >>>    Out: 250-STARTTLS
> >>>    Out: 250-AUTH PLAIN LOGIN
> >>>    Out: 250-AUTH=PLAIN LOGIN
> >>>    Out: 250-ENHANCEDSTATUSCODES
> >>>    Out: 250-8BITMIME
> >>>    Out: 250 DSN
> >>>    In:  MAIL FROM:<mkt em leadsdemarketing.com> SIZE=3074
> >>>    Out: 250 2.1.0 Ok
> >>>    In:  RCPT TO:<lucca em qbnet.com.br> ORCPT=rfc822;lucca em qbnet.com.br
> >>>    Out: 250 2.1.5 Ok
> >>>    In:  DATA
> >>>    Out: 354 End data with <CR><LF>.<CR><LF>
> >>>    Out: 451 4.3.0 Error: queue file write error
> >>>    In:  QUIT
> >>>    Out: 221 2.0.0 Bye
> >>>
> >> Olá Paulo,
> >>
> >> Vamos começar com umas coisas mais básicas que no passado foram as
> >> causas de problemas que tive.
> >> 1º já fez um teste no disco ou discos? Faz um teste de escrita com o
> >> comando de exemplo abaixo:
> >>
> >> # dd if=/dev/zero of=/mnt/teste.bin bs=4k count=200000
> >> 200000+0 records in
> >> 200000+0 records out
> >> 819200000 bytes transferred in 7.252038 secs (112961350 bytes/sec) # bc
> >> 112961350/1024/1024
> >> 107
> >>
> > Olá, Gondim. Nesta deu 78,80
> Ummm bem 78MB/s não tá legal não. Checa com o: gstat como está o I/O no
> disco. Veja se tá com uso intenso. Se tiver tranquilo refaça o teste pra
> gente, agora se o uso estiver intenso temos que descobrir o que está
> gerando esse consumo.
>
> >
> >> No exemplo acima a velocidade +/- é de 107MB/s Valores abaixo de
> >> 100MB/s em HDs SATA II já não é legal. Já peguei casos dando 10MB/s,
> >> valores bem baixos e que normalizaram quando ativei o AHCI na Bios.
> >> Pode ser uma idéia.
> >> Cheque também por problemas físicos no disco, dê uma olhada nos logs
> >> para ver se existe alguma possível indicação disso.
> >>
> > O smartd não acusa problemas, MAS o fsck acusa alguns. Pode ser a causa?
> Se está usando UFS e puder abrir uma janela de manutenção... então dê um
> boot, entre em single user e faça um fsck -y para acertar os problemas.
> Não preciso dizer que um backup atualizado dos dados é sempre
> importante.  :D
>
> >
> >> 2º já fez um mysqlcheck na base de dados para ver se não tem nada
> >> corrompido? Procure habilitar o log do slow queries para gerar um log
> >> das queries mais lentas e tentar identificar algum outro tipo de
> >> problema.
> > Fiz e não acusou problemas
> Blz, menos um problema. Habilitou ou se já tem habilitado o log de slow
> queries, checou se está tendo queries lentas com mais de 2 segundos?
>
> >
> >> 3º procure checar com o tcpdump na interface de rede se existe algum um
> >> provável ataque nas portas 25,587 e 465 tentando floodar esses
> >> serviços.
> >>
> > Como descubro que estou sofrendo ataques? Rodei o tcpdump mas como meu
> > conhecimento é zero, não soube medir. Mas esta é uma possibilidade.
> Ummm se você nunca mexeu com o tcpdump então será complicado você
> interpretar os dados coletados.  :(
>
> >
> >
> >> 4º ZFS, no passado tive um problema usando o ZFS no meu servidor de
> >> correio. Eu usava o UFS e funcionava perfeito, quis experimentar o ZFS
> >> e do nada o amavisd ficava travando em 100% de uso de CPU, o disco
> >> ficava com um I/O muito alto e aí a fila ficava parada aglomerando
> >> emails.
> >> Voltei para o UFS e pronto, meus problemas acabaram.  :)  Isso foi na
> >> versão 9.0-RELEASE ainda. Não sei agora na 9.1 ainda mais que houveram
> >> algumas melhorias no ZFS.
> >>
> >> Podes começar por essas dicas aí.  :)
> >>
> >> Grande abraço,
> >> Gondim
> > Abraço e obrigado.
> >
>
>
Apenas para fins de debug, depois que ajustar o fsck em single user com o
-y, muda as conexões persistentes para off.
Não compreendo nada de mysql, como dito anteriormente, mais com a
experiencias, conexões percistentes mantem recursos alocado que pode estar
fazendo falta.

Att.



-- 
:=)><(=:
Linux é igual brasileiro, pode não ser a melhor solução mais para tudo tem
um jeito.
Windows é igual americano, não gosta de velharia e toda mudança muda a cara
mais não os hábitos.
Solaris é igual europeu, pinta as paredes para dizer que a casa é nova mais
a fundação é do seculo passado.
UNIX/BSD é igual russo, mudanças só se julgar necessário, e quando muda
ninguém nota.
Flamers > /dev/null !!!