Embora, em geral, as coisas tenham corrido bem, notei problemas depois com processos do Postgres enlouquecendo, usando 100% de um núcleo. Números variados de processos, no entanto. Tentei algumas coisas, desde uma reconstrução até reinicializações. Atualmente, estou tentando um rake db:validate_indexes, que já está rodando há algumas horas sem nenhum feedback. Não tenho certeza se já fiz isso antes e se deveria acontecer mais rápido.
Usar o fórum funciona bem basicamente, mas definitivamente ficou mais lento. Algumas tarefas de execução mais longa, como carregar perfis de usuários mais ativos, levam notavelmente mais tempo do que o normal.
Tenho quase certeza de que há alguns problemas com o banco de dados, mas estou tendo dificuldades para descobrir quais são.
Tenho que dizer que nosso banco de dados é bem grande - estamos com cerca de 150 GB após a restauração e após a criação de índices. Monitorando o processo de restauração, não vi nenhum erro e a criação de índices correu bem aos meus olhos.
Alguma ideia de como lidar com isso? São 3 processos do postgres no momento - eram 6 antes de uma reinicialização que fiz há algumas horas - já vi todos os 16 núcleos sendo usados após a restauração também.
EDIT: Acabei de notar agora que 3 processos do sidekiq estão ocupados com “indexando categorias para busca”. Pode ser tudo isso apenas a reconstrução do índice de busca? Se for, isso pode ser resolvido de outra forma? Quando fizermos a restauração do sistema em produção, isso será um grande problema se degradar o desempenho por várias horas ou até dias.
No momento, apenas uma tarefa sidekiq está em execução com "Jobs::BackfillBadge", mas ainda assim 7 processos postgres estão aparentemente bloqueando 100% da CPU constantemente. Estou realmente curioso para saber o que está acontecendo lá.
Não tenho certeza se está fazendo algo, mas já está assim há mais de 30 minutos.
Coloquei o fórum em modo somente leitura e reiniciei a VM para encerrar os 7 processos do Postgres que estavam “travados” lá antes. Logo após a reinicialização, 2 desses processos do postgres voltaram e não mudaram. Nada rodando no sidekiq no momento.
Você realmente não quer executar um VACUUM completo. Tudo o que você precisa para recuperar o desempenho é um VACUUM VERBOSE ANALYZE. Você não pode executar um FULL em um site em execução.
Aha! Um conselho sensato de um especialista! Então talvez eu estivesse certo que 8GB/25% não é suficiente, e embora 16GB seja mais de 40%, ainda pode ser uma boa sugestão porque . . . .
Pessoal. como dito, este é um servidor de teste - não há tráfego nele. Este servidor definitivamente não é bom o suficiente para uso em produção, mas esse não é o problema aqui. A questão é por que vemos processos do postgres travados assim (com 100% de uso de CPU) e desacelerando drasticamente as coisas. Estávamos executando o servidor de teste com capacidade menor até alguns dias atrás - ele só foi ampliado devido à falta de espaço em disco para uma restauração.
A máquina de produção está rodando com 128 GB de RAM com as mesmas configurações de Shared buffer sem nenhum problema - então não acho que haja um problema geral com essas configurações e o tamanho do Shared buffer - especialmente não em uma máquina de teste privada sem tráfego.
Mas de qualquer forma - vou refazer a restauração e ver se algo pode ter dado errado, pois aparentemente não há uma boa explicação para o comportamento.
O Postgres