Eu tenho uma rotina de backup que replica o banco de dados de produção em nosso servidor intermediário. Ele funciona sem problemas, mas o banco de dados de preparo fica insuportavelmente lento após a restauração de um dos instantâneos. Lento ao ponto em que o meu servidor web apenas expira e 502.
Eu verifiquei o que poderia estar causando isso e o isolei em duas grandes tabelas. Temos uma determinada tabela de sessões com vários campos grandes de TEXTO. Estamos armazenando alguns dados não estruturados e atualmente os mantemos em campos de texto. Depois de cortar essa tabela (excluindo muitas das linhas), o ambiente de preparação acelera e começa a agir normalmente de novo.
Eu passei pela rotina de pg_reindexing no banco de dados e tentei VACUUMing, mas isso não está fazendo muita diferença. Ainda é muito lento. Páginas que não precisam acessar as duas tabelas grandes são executadas normalmente; páginas que não são carregadas.
Em resumo, estou procurando ajuda para responder a duas perguntas.
Existe uma maneira melhor de fazer a duplicação do banco de dados desde a produção até o armazenamento temporário se o despejo do meu banco de dados for > 130 MB que não causará esse problema? Fiquei com a impressão de que 130 MB não é um banco de dados muito grande. Eu suspeito que está tudo na grande tabela de sessão com os campos TEXT que falei anteriormente.
Existe alguma maneira de otimizar esta tabela? Há algum ajuste que eu possa fazer após o pg_restoring? Eu tenho medo de ter que restaurar um desses backups em um dia chuvoso e isso afetará o desempenho do site inteiro.
Obrigado antecipadamente.
Quando você está aspirando, você está ANALISANDO?
Reindex não deve ajudar: quando você pg_restore todos esses índices estão sendo criados do zero de qualquer maneira.
OVACUUM por si só não faz nada: um banco de dados recém-restaurado não contém nenhuma tupla morta para se livrar.
Execute ANALYZE em todo o banco de dados após uma restauração, isso atualiza as estatísticas, permitindo que o otimizador de consulta gere planos de consulta eficientes.
Tags performance postgresql