Em 06/02/13 14:17, Paulo Quartieri escreveu: > >> -----Mensagem original----- >> De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@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:<m...@leadsdemarketing.com> SIZE=3074 >>> Out: 250 2.1.0 Ok >>> In: RCPT TO:<lu...@qbnet.com.br> ORCPT=rfc822;lu...@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 > ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
