Contexto:
Executamos o Slony 2.0 com Postgres 8.4 em dois servidores CentOS 6 - um mestre e um escravo. Nosso banco de dados tem cerca de 30 GB de tamanho, o que não é incomum, mas temos algumas tabelas com mais de 5 GB cada.
Recentemente, precisávamos reconstruir nosso cluster Slony. Desliguei o Slony, restaurei instantâneos de banco de dados idênticos no master e no slave, configurei meu slony.conf e slon_tools.conf, iniciei os slons, executei slonik_init_cluster | slonik, então slonik_create_set 1 | slonik(só temos um conjunto de replicação) e finalmente slonik_subscribe_set 1 2 | slonik. Tudo parecia bem e pude observar o progresso da assinatura nos logs.
Em seguida, o servidor parou de responder. Reiniciei-o e vi "Pânico do Kernel - não sincronizando: sem memória e sem processos que podem ser eliminados" depois de ter matado tudo o que podia.
O que eu tentei:
Primeiro, eliminei o banco de dados completamente, executei novamente initdbe, em seguida, restaurei os instantâneos idênticos novamente. Mesmo kernel panic. Então estraguei tudo, desinstalei o Postgres e o Slony e os reinstalei. Eu verifiquei novamente todas as nossas configurações baseadas em memória em postgresql.conf, e elas estão todas nos níveis padrão/recomendado (isto shared_buffersé, em 1/4 da RAM etc etc). Executei um VACUUM ANALYZE FULLno banco de dados antes de inicializar o cluster Slony. Mesmo resultado todas as vezes: kernel panic, sem memória.
Não há chance de alterações de configuração aleatórias/manuais terem causado isso: todas as nossas configurações de Postgres e Slony são gerenciadas por Puppet e não são alteradas há meses.
Pergunta:
Por que isso está acontecendo?
Nosso banco de dados cresceu bastante linearmente nos últimos meses (no início do ano era cerca de 23 GB, agora é 30), e todas as outras vezes que tive que reinicializar o cluster Slony nesses mesmos servidores, funcionou multar.
O problema acabou não relacionado: em
/etc/sysctl.conf, oshmmaxvalor do sistema foi definido para uma quantidade maior que a RAM disponível.Defini-lo como 60% da RAM (recomendação do nosso consultor de banco de dados) resolveu o problema.
Por que esse problema não surgiu antes é um mistério para mim.