[FUG-BR] RES: RES: Problema Indefinido

Quinta Fevereiro 7 08:06:37 BRST 2013

> -----Mensagem original-----
> De: freebsd-bounces at fug.com.br [mailto:freebsd-bounces at fug.com.br] Em
> nome de Paulo Henrique
> Enviada em: quinta-feira, 7 de fevereiro de 2013 06:11
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] RES: Problema Indefinido
> 
> Em 6 de fevereiro de 2013 19:06, Marcelo Gondim
> <gondim at bsdinfo.com.br>escreveu:
> 
> > Em 06/02/13 14:17, Paulo Quartieri escreveu:
> > >
> > >> -----Mensagem original-----
> > >> De: freebsd-bounces at fug.com.br [mailto:freebsd-bounces at 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 at leadsdemarketing.com> SIZE=3074
> > >>>    Out: 250 2.1.0 Ok
> > >>>    In:  RCPT TO:<lucca at qbnet.com.br>
> ORCPT=rfc822;lucca at 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.
> 

Meu servidor fica hospedado num lugar sem acesso e consigo apenas um kvmip.
Se eu der um shutdown o sistema fica em stand-alone, mas montado. Se eu rodo
fsck -y ele coloca um NO WRITE bem grande. Como 'desmonto' de uma maneira
segura para rodar o fsck -y?

> 
> --
> :=)><(=:
> 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 !!!
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd