Daemon do MySQL parando sozinho [RESOLVIDO]

sandro-mechi
(usa Debian)

Enviado em 16/09/2013 - 16:20h

Boa tarde pessoal do VoL,

Estou quebrando a cabeça com este problema. Tenho um MySQL 5.6.12 instalado em um ubuntu 12.0.4 x64.
Tudo esta funcionando normalmente, até que, sem razão aparente perco a conexão com o banco. Quando vou checar no servidor, o daemon não esta rodando.
Na console, inicio o mysql normalmente através do comando # service mysql start e ele funciona normalmente. Andei pesquisando e parece que o sistema esta dando kill nos processos que consomem muita memória / cpu, entretanto eu não realizei nenhuma configuração neste sentido. Alguém tem alguma dica?

Obrigado.

danniel-lara
(usa Fedora)

Enviado em 16/09/2013 - 16:36h

inicia ele e fica analisando os logs do servidor
pode ajudar muito

sandro-mechi
(usa Debian)

Enviado em 16/09/2013 - 16:38h

Obrigado pela resposta.

Então, através do error.log, aparece apenas o registro "Killed". Depois eu inicio o daemon e ele funciona normalmente.

Vlw

removido
(usa Nenhuma)

Enviado em 16/09/2013 - 16:45h

Já analisou o syslog?

removido
(usa Nenhuma)

Enviado em 16/09/2013 - 16:58h

Tem uma atualização. Pessoalmente não li. Mas dá uma olhada, veja se não é um bug => http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html

Esse server é seu ou de empresa? Está em produção? Pessoalmente nunca promovo a ultima versão de nada para produção. Promovo apenas em ambiente controlado.

sandro-mechi
(usa Debian)

Enviado em 17/09/2013 - 15:26h

Amarildo, obrigado pela resposta.

Encontrei no syslog uma pista: Sep 17 14:18:06 saotdb02 kernel: [344346.207912] send sigkill to 7204 (mysqld), adj 0, size 42826

Entretanto não vi nenhum script dentro das pastas do cron que possa estar fazendo isso. Este servidor não esta em produção, é um servidor de testes. Entretanto, temos um servidor em produção com a mesma versão do Mysql, rodando sobre a mesma versão de S.O. e não esta com este problema.
Vou checar o artigo que me enviou. Mais uma vez obrigado.

Atte.,
Sandro

sandro-mechi
(usa Debian)

Enviado em 17/09/2013 - 15:59h

Pessoal,

Há fortes motivos para crer que o recurso OOM KILLER do Kernell esta matando o daemon do mysql. Estou pesquisando formas para evitar que isso aconteça. Logo mais, posto o que eu fiz e o resultado.

Abraços!

sandro-mechi
(usa Debian)

Enviado em 17/09/2013 - 16:43h

Amarildo e Danniel,

Seguindo a linha de raciocínio da minha última resposta, fiz o seguinte teste:

Criei um script com o nome mysql-no-oom.sh e salvei na pasta /root/scripts. Ele tem o seguinte conteúdo:

#!/bin/bash
pgrep -f "/usr/libexec/mysqld" | while read PID; do echo -1000 >
/proc/$PID/oom_score_adj; done

Configurei permissão de execução para o root e grupo e, ler / executar para outros com chmod 775.

Configurei o CRON para executar o script de 15 em 15 minutos com a seguinte linha no crontab:

0,15,30,45 * * * * root bash /root/scripts/mysql-no-oom.sh


Dando créditos, tirei a dica daqui: http://lists.mysql.com/mysql/227187

Pelo que entendi, o script diminui a pontuação do daemon do mysql no oom_score dentro do /proc (No respectivo PID).
Quando o sistema atinge um certo limite de memória o OOM KILLER faz um select e procura o daemon que tem a maior pontuação dentro do do /proc configurado anteriormente, ao encontrar a pontuação do MYSQL, que com certeza deve ser a mais alta, ele mata o processo.

Configurei às 16h35 de hoje, vou ficar monitorando para ver se resolveu. Posto o resultado aqui para que outros também possam se beneficiar.

sandro-mechi
(usa Debian)

Enviado em 18/09/2013 - 16:16h

Pessoal,

Somente para mantê-los atualizados, o procedimento foi feito ontem, por volta das 16h30 e até agora o mysql não sofreu nenhum kill. Vou aguardar mais um dia e volto a postar a última atualização sobre esse assunto e marcar o tópico como solucionado.

sandro-mechi
(usa Debian)

Enviado em 20/09/2013 - 08:54h

Bom dia Pessoal,

Estou finalizando este tópico, o procedimento que postei anteriormente funcionou perfeitamente e o daemon do mysql não sofreu mais nenhum kill desde a configuração.
Concluindo, é claro que é melhor ter um servidor de banco com bastante memória, pois é sabido que os SGBDs invariavelmente consomem muito este recurso. Não tive tempo de pesquisar a fundo sobre o OOM Killer, mas gostaria de compartilhar alguns links onde percebe-se que vários administradores usam o mesmo recurso que usei na prevenção de seus processos mais críticos:
http://ubuntuforums.org/showthread.php?t=1524536
http://stackoverflow.com/questions/15237067/how-do-i-configure-oom-killer
http://stackoverflow.com/questions/9199731/understanding-the-linux-oom-killers-logs
http://askubuntu.com/questions/51172/set-oom-killer-adjustment-for-process-on-startup
http://backdrift.org/how-to-create-oom-killer-exceptions

Agradeço especialmente os camaradas danniel-lara e amarildosertorio pela atenção dispensada e por me mostrarem o caminho.

Espero que as contribuições ajudem outras pessoas.