Eu criei um script para simular a carga no nosso servidor de backup. E então consegui recriar o problema. Acabei tendo que adicionar a configuração "join_buffer_size" ao my.cnf e isso resolveu o problema.
temos um aplicativo da web (racktables) que nos dá tristeza em nossa caixa de produção. sempre que os usuários tentam executar uma pesquisa, ele apresenta o seguinte erro:
Pdo exception: PDOException
SQLSTATE[HY000]: General error: 5 Out of memory (Needed 2057328 bytes) (HY000)
Não consigo recriar o problema no nosso servidor de backup. Os servidores correspondem, exceto pelo fato de que na produção temos 16GB de RAM e nosso backup temos 8GB. É um ponto discutível, porém, porque ambos estão rodando em 32 bits e estão usando apenas 4GB de RAM. nós também configuramos uma partição swap ...
Veja o que recebo do comando "free -m" em produção:
prod:/etc# free -m
total used free shared buffers
Mem: 3294 1958 1335 0 118
-/+ buffers: 1839 1454
Swap: 3817 109 3707
prod:/etc#
Eu verifiquei se my.cnf em ambas as caixas corresponde. O banco de dados da produção foi replicado no servidor de backup ... então os dados também correspondem.
Acho que nossas opções são:
A) convert the o/s to 64 bit so we can use more RAM.
B) start tweaking some of the innodb settings in my.cnf.
Mas antes que eu tente A ou B, eu queria saber se há algo mais que eu deveria comparar entre os dois servidores ... vendo como o backup está funcionando muito bem. Deve haver uma diferença em algum lugar que não estamos representando.
Uma coisa que eu estou pensando em tentar é apenas reinicializar o servidor para ver se isso corrige isso. Em caso afirmativo, isso pode indicar problemas com vazamentos de memória. ?? Qualquer sugestão seria apreciada.
EDIT 1
Estes são os resultados da execução do comando ulimit (ambos os servidores têm os mesmos resultados)
prod:/etc# ulimit -a
-f: file size (blocks) unlimited
-t: cpu time (seconds) unlimited
-d: data seg size (kb) unlimited
-s: stack size (kb) 8192
-c: core file size (blocks) 0
-m: resident set size (kb) unlimited
-l: locked memory (kb) 64
-p: processes 26303
-n: file descriptors 1024
-v: address space (kb) unlimited
-w: locks unlimited
-e: scheduling priority 0
-r: real-time priority 0
Eu prevejo que o problema é causado por um sistema com a supercomissão de VM desativada.
Verifique o valor com sysctl vm.overcommit_memory
Veja o link
A propósito, para um servidor de banco de dados, não recomendo ativar novamente o overcommit. Você não quer estar usando o arquivo de troca.