MySQL intermitente trava com o erro "Erro fatal: não é possível alocar memória para o buffer pool"

40

Adicionado em editar, 29/05/2013: Como essa é uma pergunta e discussão longas, aqui está um breve resumo da pergunta e da solução. Eu tive problemas ao executar o MySQL e o Apache em um pequeno servidor Linux (1 GB de memória). O Apache continuou exigindo mais memória e, como conseqüência, o sistema operacional sempre matou o MySQL para recuperar sua memória. A solução foi substituir o Apache pelo Lighttpd. Depois disso, o uso da memória no servidor ficou completamente estável por vários meses e não tive nenhum tipo de falha. fim de edição

Sou administrador de sistema iniciante em um pequeno servidor virtual. A principal função do servidor é executar o software do sistema de gerenciamento de cursos Moodle de código aberto, escrito em PHP. Ele se baseia em um banco de dados, neste caso, MySQL, e um servidor web, neste caso, Apache.

O servidor está executando o CentOS de 64 bits, versão 5.8 (Final), com 1 GB de memória e 200 GB de disco, versão do kernel 2.6.18-308.8.2.el5xen. A versão do MySQL é a Ver 14.14 Distrib 5.5.25, para Linux (x86_64) usando o readline 5.1.

Eu não acho que o software Moodle seja um usuário tão pesado do MySQL. Atualmente, apenas cerca de dez professores têm acesso a ele e, quando despejo e comprimo com o bzip2 todo o banco de dados, o tamanho do despejo resultante é menor que 1 MB.

Eu configurei o sistema há alguns meses atrás. O servidor Apache permaneceu estável o tempo todo, mas o MySQL travou várias vezes. Eu tentei aprender sobre a configuração ideal da Web e, na última vez que alterei o /etc/my.cnfarquivo, usei o arquivo /usr/share/doc/mysql55-server-5.5.25/my-large.cnfque acompanha o MySQL como exemplo. O arquivo diz que ele é destinado a sistemas com 512 MB de memória, então pensei que o uso de seus parâmetros de configuração relacionados à memória seria seguro para esse sistema. (Eu já havia configurado os parâmetros relacionados à memória do MySQL com números muito menores, e pensei que isso poderia ter causado as falhas. Enquanto as falhas ainda ocorrem, o sistema é pelo menos mais rápido agora.) Estes são os conteúdos atuais de /etc/my.cnf:

# /etc/my.cfg

# The main and only MySQL configuration file on [WEBSITE ADDRESS REDACTED].
# Last updated 2012-09-23 by Teemu Leisti.

# Most of the memory settings are set to be the same as the example setting file
# /usr/share/doc/mysql55-server-5.5.25/my-large.cnf, which is meant for systems
# with 512M of memory.  This server currently has twice that, i.e. 1G of memory,
# which should make these settings safe.


[client]
default_character_set           = utf8
port                            = 3306
socket                          = /var/lib/mysql/mysql.sock

[mysqld]
character_set_filesystem        = utf8
character_set_server            = utf8
datadir                         = /var/lib/mysql
innodb_additional_mem_pool_size = 20M
innodb_buffer_pool_size         = 256M # You can set .._buffer_pool_size up to
                                       # 50..80% of RAM, but beware of setting
                                       # memory usage too high
innodb_data_file_path           = ibdata1:10M:autoextend
innodb_data_home_dir            = /var/lib/mysql
innodb_flush_log_at_trx_commit  = 1
innodb_lock_wait_timeout        = 50
innodb_log_buffer_size          = 8M
innodb_log_file_size            = 64M # Set .._log_file_size to 25% of buffer
                                      # pool size
innodb_log_group_home_dir       = /var/lib/mysql
interactive_timeout             = 60
key_buffer_size                 = 256M
long_query_time                 = 10
max_allowed_packet              = 1M
max_connections                 = 30
port                            = 3306
query_cache_limit               = 2M # see http://emergent.urbanpug.com/?p=61
query_cache_size                = 16M
read_buffer_size                = 1M
read_rnd_buffer_size            = 4M
skip_networking                 # Only local processes need to use MySQL
skip_symbolic_links             # Disabling symbolic_links is recommended to
                                # prevent assorted security risks
slow_query_log_file             = /var/log/mysql-slow-queries.log
socket                          = /var/lib/mysql/mysql.sock
sort_buffer_size                = 1M
table_open_cache                = 256
thread_cache_size               = 8
thread_concurrency              = 2 #    = number of CPUs * 2
user                            = mysql
wait_timeout                    = 10

[mysqld_safe]
log_error                       = /var/log/mysqld.log
open_files_limit                = 4096
pid_file                        = /var/run/mysqld/mysqld.pid

[mysqldump]
quick
max_allowed_packet              = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
safe-updates

[myisamchk]
key_buffer_size                 = 128M
sort_buffer_size                = 128M
read_buffer                     = 2M
write_buffer                    = 2M

[mysqlhotcopy]
interactive-timeout

Como você pode ver na configuração, a instalação usa o mecanismo InnoDB e serve apenas solicitações do host local. Além do administrador do sistema (eu), o Moodle é o único usuário do MySQL.

Quando o MySQL trava, o seguinte é invariavelmente gravado no arquivo de log /var/log/mysqld.log(exceto os registros de data e hora, é claro):

120926 08:00:51 mysqld_safe Number of processes running now: 0
120926 08:00:51 mysqld_safe mysqld restarted
120926  8:00:53 [Note] Plugin 'FEDERATED' is disabled.
120926  8:00:53 InnoDB: The InnoDB memory heap is disabled
120926  8:00:53 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120926  8:00:53 InnoDB: Compressed tables use zlib 1.2.3
120926  8:00:53 InnoDB: Using Linux native AIO
120926  8:00:53 InnoDB: Initializing buffer pool, size = 256.0M
InnoDB: mmap(274726912 bytes) failed; errno 12
120926  8:00:53 InnoDB: Completed initialization of buffer pool
120926  8:00:53 InnoDB: Fatal error: cannot allocate memory for the buffer pool
120926  8:00:53 [ERROR] Plugin 'InnoDB' init function returned error.
120926  8:00:53 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
120926  8:00:53 [ERROR] Unknown/unsupported storage engine: InnoDB
120926  8:00:53 [ERROR] Aborting

120926  8:00:53 [Note] /usr/libexec/mysqld: Shutdown complete

120926 08:00:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

Às vezes eu posso reiniciar MySQL comandando service mysqld restart, mas às vezes o comando falhar com esta saída: mysqld dead but subsys locked. Nesses casos, a única coisa em que consegui recuperar a situação é reiniciar o servidor, após o qual o MySQL pode ser reiniciado. Nesses casos, a saída fica assim:

120926 11:43:48 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120926 11:43:48 [Note] Plugin 'FEDERATED' is disabled.
120926 11:43:48 InnoDB: The InnoDB memory heap is disabled
120926 11:43:48 InnoDB: Mutexes and rw_locks use GCC atomic builtins
120926 11:43:48 InnoDB: Compressed tables use zlib 1.2.3
120926 11:43:48 InnoDB: Using Linux native AIO
120926 11:43:48 InnoDB: Initializing buffer pool, size = 256.0M
120926 11:43:48 InnoDB: Completed initialization of buffer pool
120926 11:43:48 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
120926 11:43:48  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
120926 11:43:51  InnoDB: Waiting for the background threads to start
120926 11:43:52 InnoDB: 1.1.8 started; log sequence number 466807107
120926 11:43:52 [Note] Event Scheduler: Loaded 0 events
120926 11:43:52 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.25'  socket: '/var/lib/mysql/mysql.sock'  port: 0  MySQL Community Server (GPL)

Aqui está o que o comando free -mproduz atualmente:

# free -m
             total       used       free     shared    buffers     cached
Mem:          1024        869        154          0         70        153
-/+ buffers/cache:        644        379
Swap:            0          0          0

Normalmente, a coluna "livre" tem entre 50 e 100 MB.

A saída do comando ulimit -a:

# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 8192
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 8192
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Não alterei nenhum arquivo de configuração ou código do Moodle, exceto o /var/www/html/moodle/config.phpque se parece com isso (linhas de comentário excluídas para economizar espaço):

<?php
unset($CFG);  // Ignore this line
global $CFG;  // This is necessary here for PHPUnit execution
$CFG = new stdClass();
$CFG->dbtype    = 'mysqli';           // 'pgsql', 'mysqli', 'mssql', 'sqlsrv' or 'oci'
$CFG->dblibrary = 'native';           // 'native' only at the moment
$CFG->dbhost    = 'localhost';        // eg 'localhost' or 'db.isp.com' or IP
$CFG->dbname    = 'moodle';           // database name, eg moodle
$CFG->dbuser    = 'moodleuser';       // your database username
$CFG->dbpass    = '[REDACTED]';       // your database password
$CFG->prefix    = 'moodle_';          // prefix to use for all table names
$CFG->dboptions = array(
    'dbpersist' => false,       // should persistent database connections be
                                //  used? set to 'false' for the most stable
                                //  setting, 'true' can improve performance
                                //  sometimes
    'dbsocket'  => true,        // should connection via UNIX socket be used?
                                //  if you set it to 'true' or custom path
                                //  here set dbhost to 'localhost',
                                //  (please note mysql is always using socket
                                //  if dbhost is 'localhost' - if you need
                                //  local port connection use '127.0.0.1')
    'dbport'    => '',          // the TCP port number to use when connecting
                                //  to the server. keep empty string for the
                                //  default port
);
$CFG->passwordsaltmain = '[REDACTED]';
$CFG->wwwroot   = 'http://[REDACTED]';
$CFG->dataroot  = '/var/moodledata';
$CFG->directorypermissions = 02777;
$CFG->admin = 'admin';
date_default_timezone_set('Europe/Helsinki');
$CFG->disableupdatenotifications = true;
require_once(dirname(__FILE__) . '/lib/setup.php'); // Do not edit

(No entanto, eu instalei dois plugins do Moodle, o módulo Attendance e o bloco , mas não vejo como eles poderiam estar envolvidos com esse problema.)

Mesmo depois que eu atualizei /etc/my.cnfpara seu estado atual há uma semana, o MySQL travou algumas vezes com os sintomas apresentados acima. Sendo iniciante na administração de bancos de dados, e depois de pesquisar bastante sobre esse problema, não sei o que fazer a seguir. Alguma sugestão? Devo postar mais dados de configuração?

Adição na edição:

O conteúdo do arquivo /var/log/messages.1é:

Sep 23 04:02:18 [machine name] syslogd 1.4.1: restart.
Sep 26 08:00:51 [machine name] kernel: mysqld invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Sep 26 08:00:51 [machine name] kernel:
Sep 26 08:00:51 [machine name] kernel: Call Trace:
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802c1bd5>] out_of_memory+0x8b/0x203
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8020fa49>] __alloc_pages+0x27f/0x308
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802139c9>] __do_page_cache_readahead+0xc8/0x1af
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8021423a>] filemap_nopage+0x14c/0x360
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80208e9d>] __handle_mm_fault+0x444/0x144f
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80263929>] _spin_lock_irqsave+0x9/0x14
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8023f468>] lock_timer_base+0x1b/0x3c
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff80266d94>] do_page_fault+0xf72/0x131b
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802e5f4f>] sys_io_getevents+0x311/0x359
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff802e4e56>] timeout_func+0x0/0x10
Sep 26 08:00:51 [machine name] kernel:  [<ffffffff8025f82b>] error_exit+0x0/0x6e
Sep 26 08:00:51 [machine name] kernel:
Sep 26 08:00:51 [machine name] kernel: Mem-info:
Sep 26 08:00:51 [machine name] kernel: DMA per-cpu:
Sep 26 08:00:51 [machine name] kernel: cpu 0 hot: high 0, batch 1 used:0
Sep 26 08:00:51 [machine name] kernel: cpu 0 cold: high 0, batch 1 used:0
Sep 26 08:00:51 [machine name] kernel: DMA32 per-cpu:
Sep 26 08:00:51 [machine name] kernel: cpu 0 hot: high 186, batch 31 used:117
Sep 26 08:00:51 [machine name] kernel: cpu 0 cold: high 62, batch 15 used:53
Sep 26 08:00:51 [machine name] kernel: Normal per-cpu: empty
Sep 26 08:00:51 [machine name] kernel: HighMem per-cpu: empty
Sep 26 08:00:51 [machine name] kernel: Free pages:        7256kB (0kB HighMem)
Sep 26 08:00:51 [machine name] kernel: Active:241649 inactive:0 dirty:0 writeback:0 unstable:0 free:1814 slab:4104 mapped-file:1153 mapped-anon:240592 pagetables:3298
Sep 26 08:00:51 [machine name] kernel: DMA free:3268kB min:32kB low:40kB high:48kB active:0kB inactive:0kB present:9068kB pages_scanned:0 all_unreclaimable? yes
Sep 26 08:00:51 [machine name] kernel: lowmem_reserve[]: 0 994 994 994
Sep 26 08:00:51 [machine name] kernel: DMA32 free:3988kB min:4016kB low:5020kB high:6024kB active:966596kB inactive:0kB present:1018080kB pages_scanned:6327262 all_unreclaimable? yes
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
Sep 26 08:00:52 [machine name] kernel: lowmem_reserve[]: 0 0 0 0
Sep 26 08:00:52 [machine name] kernel: DMA: 1*4kB 2*8kB 1*16kB 1*32kB 2*64kB 2*128kB 1*256kB 1*512kB 2*1024kB 0*2048kB 0*4096kB = 3268kB
Sep 26 08:00:52 [machine name] kernel: DMA32: 17*4kB 2*8kB 2*16kB 1*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3988kB
Sep 26 08:00:52 [machine name] kernel: Normal: empty
Sep 26 08:00:52 [machine name] kernel: HighMem: empty
Sep 26 08:00:52 [machine name] kernel: 1214 pagecache pages
Sep 26 08:00:52 [machine name] kernel: Swap cache: add 0, delete 0, find 0/0, race 0+0
Sep 26 08:00:52 [machine name] kernel: Free swap  = 0kB
Sep 26 08:00:52 [machine name] kernel: Total swap = 0kB
Sep 26 08:00:52 [machine name] kernel: Free swap:            0kB
Sep 26 08:00:52 [machine name] kernel: 262144 pages of RAM
Sep 26 08:00:52 [machine name] kernel: 8320 reserved pages
Sep 26 08:00:52 [machine name] kernel: 22510 pages shared
Sep 26 08:00:52 [machine name] kernel: 0 pages swap cached
Sep 26 08:00:52 [machine name] kernel: Out of memory: Killed process 1371, UID 27, (mysqld).

e, em seguida, linhas relacionadas à reinicialização às 11:42.

Adição na edição nº 2:

Tentei comentar a resposta de Michael, mas vii o limite de caracteres dos comentários, por isso estou respondendo aqui.

Obrigado pela resposta, Michael. Acabei de editar minha pergunta para incluir o conteúdo do log do sistema da máquina no momento do acidente. (O CentOS parece chamar o log do sistema /var/log/messages.)

Sim, os registros do MySQL e do sistema parecem quase idênticos aos da pergunta à qual você se vinculou. E agora que você mencionou, é meio óbvio que a mysql restartedmensagem significa que o MySQL já havia travado. O log do sistema indica que é o oom_killerque obteve o processo. Na sua resposta anterior, você escreve: "Primeiro palpite: os processos filho do apache ficam loucos". Parece-me que o Apache é o suspeito óbvio aqui também.

Anteriormente, encontrei o artigo Otimizando o MySQL e o Apache para baixo uso de memória, Parte 1 . Para configurar o Apache, o autor recomenda: "Primeiro, Apache. Minha primeira afirmação é, se você puder evitá-lo, tente. Lighttpd e thttpd são ambos muito bons sem servidores da Web de frescura, e você pode executar o lighttpd com PHP. Mesmo se você está executando um site de alto volume, você pode obter um desempenho sério transmitindo conteúdo estático (imagens e arquivos javascript, geralmente) para um servidor HTTPd leve e super-rápido, como o Lighttpd. "

Estou pensando em seguir o conselho do autor, e concordei com meu cliente que, no próximo fim de semana, substituirei o Apache pelo Lighttpd no servidor. Espero que isso resolva os problemas. O uso de dois servidores virtuais provavelmente não é possível.

Eu não pensava que o uso de dois servidores de código aberto estáveis ​​e maduros, como MySQL e Apache na mesma máquina, com uma quantidade razoável de memória, seria tão problemático.

Teemu Leisti
fonte

Respostas:

36

Por favor, reveja minha resposta a esta pergunta recente . Eu acredito que as circunstâncias são idênticas.

Não altere sua configuração do MySQL neste momento, pois o MySQL não é o problema - é apenas um sintoma do problema ... que parece que você possui um sistema com uma pequena quantidade de memória e espaço de troca zero.

Seu servidor não está travando "porque" a memória não pode ser alocada para o buffer pool. Seu servidor está travando ... e, em seguida, não é possível reiniciar subsequentemente devido à indisponibilidade de memória do sistema. Toda a memória configurada para o buffer pool do InnoDB é solicitada ao sistema na inicialização do mysql.

Quando você vê esta mensagem de log ...

120926 08:00:51 mysqld_safe Number of processes running now: 0

... seu servidor já morreu. Se ele não registrou nada antes disso, não registrará nada sobre o primeiro travamento. Os logs subseqüentes são após a tentativa automática de reiniciar.

Verifique seu syslog e você deve encontrar mensagens onde o kernel procurou processos para matar devido a uma condição extrema de falta de memória.

A etapa 1 provavelmente seria adicionar algum espaço de troca e / ou alocar RAM, se possível.

Se isso não for possível, você pode considerar diminuir o tamanho do innodb-buffer-pool em sua configuração. (Eu nunca pensei que me ouviria dizer isso). Contanto que seu banco de dados seja pequeno e seu tráfego seja leve, talvez você não precise de um buffer pool tão grande ... e como a memória do InnoDB Buffer Pool está alocada na inicialização, seja necessária ou não, isso liberaria algumas das suas memória do sistema para o que mais a exigir. (A recomendação de 75% a 80% da RAM total para dimensionar o buffer pool só é verdadeira se o servidor inteiro for dedicado ao MySQL.)

A etapa 2 será revisar o modelo de bifurcação do Apache e o que você pode precisar fazer de maneira diferente na configuração para impedir que ela sobrecarregue o servidor. É bem provável que o crescimento descontrolado dos requisitos de quantidade ou memória dos processos filhos do Apache esteja iniciando uma cascata de eventos, resultando no kernel matando o MySQL para tentar evitar uma falha completa de todo o servidor.

Dependendo da flexibilidade que você tem, você pode até considerar duas máquinas virtuais separadas para Apache e MySQL.

Michael - sqlbot
fonte