Kernel tenta matar o MySQL com sigkill

Question

Estou executando um servidor Ubuntu para o MySQL.

Informações do servidor

• Ubuntu 12.10
• MySQL instalado via apt
• RAM: 512 M
• innodb_buffer_pool_size : 300 milhões
• Não há outro aplicativo com uso intensivo de memória em execução nesta caixa.

Problema

Todas as manhãs, às aprox. 6:40 am algo acontece para causar uma mudança perceptível na memória:

link

Ao mesmo tempo, um "kill" sistemático de processos em execução parece ocorrer, fazendo com que o MySQL seja reiniciado.

Apr 10 06:43:40 mysql-01 kernel: [1866472.511966] select 1 (init), adj 0, size 41, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.511973] select 385 (dbus-daemon), adj 0, size 44, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.511975] select 389 (rsyslogd), adj 0, size 124, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.511982] select 4578 (snmpd), adj 0, size 160, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.514157] select 1 (init), adj 0, size 41, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.514164] select 385 (dbus-daemon), adj 0, size 44, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.514166] select 389 (rsyslogd), adj 0, size 124, to kill

Apr 10 06:43:40 mysql-01 kernel: [1866472.514171] select 4578 (snmpd), adj 0, size 160, to kill

Apr 10 06:43:44 mysql-01 /etc/mysql/debian-start[21807]: Upgrading MySQL tables if necessary.

Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21810]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored

Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21810]: Looking for 'mysql' as: /usr/bin/mysql

Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21810]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck

Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21810]: This installation of MySQL is already upgraded to 5.5.29, use --force if you still need to run mysql_upgrade

Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21821]: Checking for insecure root accounts. Apr 10 06:43:45 mysql-01 /etc/mysql/debian-start[21826]: Triggering myisam-recover for all MyISAM tables

Qualquer ajuda para diagnosticar isso seria muito apreciada!

    

Answer 1

O kernel está detectando que está ficando sem memória, possivelmente porque algum processo está em execução.

Normalmente, OOM killer tentará identificar esse processo e eliminá-lo. A razão pela qual ele está matando o mysql é porque este é provavelmente o processo que está atualmente ocupando a maior quantidade de memória ram, então é um candidato muito provável para o processo de execução.

No entanto, também parece que snmpd é o culpado. (está levando 160MB que é muito) O snmpd é um deamon responsável por escutar o snmp tráfego, parece estranho para ele ter tanta memória.

Como isso está acontecendo todos os dias ao mesmo tempo, verifique seus cron jobs diários. E verifique seu arquivo de log snmpd. Verifique também se há conexões incomming nesse período. (do sshd)

Todos esses arquivos de log devem estar aparecendo em algum lugar em / var / log / xxx

Se isso não for nada inesperado, procure nos arquivos de log os outros processos mencionados no log. (mysql e rsyslogd)

Além disso, a partir do seu gráfico você tem apenas 66MB livres em média, e está correndo para problemas de memória muito mais do que apenas 6,40, quase 20% do tempo você parece ter menos do que alguns MB's gratuitos, nunca mais do que isso 100MB grátis. (se eu ver corretamente que a barra magenta é a memória livre?)