Estamos com um problema em que nossas caixas Linux (Ubuntu 10.04 LTS, rodando no EC2 com tamanho quádruplo, 68 GB de RAM e 8 núcleos virtuais com 3,25 GHz cada) congela a cada poucos segundos. Digitar em uma sessão ssh irá congelar, e executar strace em um dos processos do Postgresql que estão sendo executados geralmente mostra:
02:37:41.567990 semop(7831581, {{3, -1, 0}}, 1
por alguns segundos antes de continuar (sempre fica preso naquele semop).
O OProfile mostra que a maior parte do tempo é gasto no kernel (60%) versus 37% no Postgresql.
O resultado dessas paradas (que começaram repentinamente um dia atrás) é que a carga na caixa passou de 0,7 para 10+ e faz com que toda a nossa pilha fique lenta.
Alguma idéia de como rastrear o que está acontecendo? O iostat não mostra os discos sendo particularmente lentos ou sobrecarregados, e o top mostra o cpu% spike do usuário de 8% a cerca de 40% sempre que esses backups acontecem.
Eu suspeito que seu sistema está ficando sem sinais. Verifique ipcs -l para as configurações atuais. Aqui está algumas informações sobre ajustes de semáforos para o postgresql . Em particular, eu tentaria aumentar o número máximo de semáforos em todo o sistema (SEMMNS) e o número máximo de semáforos por conjunto (SEMMSL). Você pode usar sysctl -p para modificar essas configurações.
Veja esta questão Linux com 256GB de memória / 48 núcleos - A máquina começa a debulhar / engasgar com toneladas de memória sobrando e ver se o link sobre o mysql e trocar a insanidade com a memória grande ajuda.
Como você já localizou a maior parte do tempo gasto no kernel, sugerimos ativar CONFIG_LATENCYTOP e executar, bem, latencytop para ver mais. Pode ser feito com oprofile também, mas latencytop é muito mais conveniente.
Levando em consideração "68GB de RAM", suspeito que esteja relacionado à ineficiência da VM. Você tentou reiniciar o Postgresql ou reinicializar?
Tivemos um problema semelhante (diferentes em que as pausas foram separadas por minutos) quando implantamos nossos servidores Oracle em servidores com memória de 96 Gb pela primeira vez. Nós acabamos rastreando até o processo do kernel encarregado de identificar a memória que poderia ser paginada. Definir o processo para verificar pedaços menores com mais frequência cuidou do problema.
Verifique sua entropia disponível quando isso está acontecendo:
cat / proc / sys / kernel / aleatório / entropy_avail
O Ubuntu parece ter um mau hábito de exigir números aleatórios reais do sistema quando não é necessário, o que pode causar situações como essa. Tente fazer o gerador de números aleatórios funcionar, isso faz com que os problemas desapareçam, se você tiver.
Finalmente, rastreamos a configuração do PostgreSQL: "work_mem", que configura a quantidade de memória RAM que cada processo do Postgres recebe para fazer seus tipos. Estávamos transbordando do padrão (minúsculo), o que fez o sistema atingir o disco, que é o beijo da morte no EC2 (e o súbito aumento na atividade do disco foi congelar o kernel em rápidas explosões de iowait).