[FUG-BR] RES: Problema Indefinido

Quarta Fevereiro 6 19:06:25 BRST 2013

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