Uso um software que cria um grande banco de dados PostgreSQL (há uma tabela com um milhão de linhas) e os desenvolvedores dizem que devo VACUUMe ANALYZEperiodicamente. Mas o padrão do banco de dados PostgreSQL está autovacuumativado.
Devo aspirar / analisar? Quais são os benefícios? Qual é a diferença entre vácuo automático e manual
Por exemplo, no Pgadmin3, tenho o seguinte:
Respostas:
Eu concordo com o ETL que não há resposta curta. O tamanho não é a única coisa que importa - executamos bancos de dados PostgreSQL OLTP bastante grandes (com algumas tabelas> 100.000.000 de linhas) sob carga pesada e atualmente contamos apenas com o vácuo automático.
No entanto, duas coisas parecem importantes para mim:
Parece haver um consenso de que o vácuo automático nunca deve ser desligado, a menos que você tenha uma carga de trabalho muito bem definida no banco de dados e saiba exatamente o que está fazendo. Mas, naturalmente, você poderia fazer execuções adicionais VACUUMe / ou ANALYZE.
Antes de considerar VACUUMexecuções adicionais , eu verificaria como o autovacuum se mantém. Você pode verificar se alguma tabela está além do limite de vácuo automático consultando pg_stat_user_tablese pg_class. Publiquei essa consulta em outro segmento, que pode ser interessante: Autovacuum agressivo no PostgreSQL .
Infelizmente, não é tão fácil (ou seja, não é possível no momento) fazer uma verificação semelhante para analisar automaticamente os limites. No entanto, a análise automática é iniciada muito antes do vácuo automático por padrão e é muito mais barato. Portanto, basicamente, se o seu banco de dados puder acompanhar o vácuo automático, provavelmente será bom também analisar automaticamente. As últimas datas de análise automática também podem ser consultadas pg_stat_user_tables.
Algumas partes da (mais excelente) documentação do PostgreSQL, que achei úteis:
O vácuo automático deve muito bem cobri-lo, a menos que você tenha configurado algo errado . Outras respostas já cobrem isso.
Há um caso claramente definido para manual VACUUM (e mais importante: manualANALYZE ): tabelas temporárias , elas não são consideradas pelo demônio do autovacuum. Cito o manual CREATE TABLEaqui :
O daemon autovacuum não pode acessar e, portanto, não pode aspirar ou analisar tabelas temporárias. Por esse motivo, as operações de vácuo e análise apropriadas devem ser executadas por meio de comandos SQL da sessão. Por exemplo, se uma tabela temporária for usada em consultas complexas, é aconselhável executar
ANALYZEa tabela temporária depois de preenchida.
Não há uma resposta curta para isso, pois depende de muitos fatores. O sistema está lento? O aspirador automático está realmente tocando nesta mesa? etc.
Aqui estão alguns bons links sobre este assunto:
Tomar uma decisão clara requer uma compreensão do próprio banco de dados e mais detalhes sobre o que está acontecendo.
Não acho que você precise aspirar manualmente, a menos que comece a ver a degradação do desempenho. No entanto, eu recomendo fortemente revisar suas configurações de vácuo e vácuo automático e ajustá-lo às suas necessidades
Para ver suas configurações atuais, execute esta consulta:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'A maioria dos campos é auto-explicativa, mas aqui está a documentação: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
Eu diria que seu objetivo deve ser configurar o vácuo automático para limpar o lixo de forma consistente, mas não execute o vácuo automático constantemente
As configurações mais importantes são:
O limiar ajuda a impedir que o processo de limpeza seja acionado com muita frequência para tabelas pequenas.
As configurações padrão funcionam bem, a menos que você tenha tabelas muito grandes. Simplificando, se houver uma tabela com 100 GB, você acumulará 20 GB de lixo antes que o vácuo automático seja acionado. Portanto, eu geralmente recomendo definir o fator de escala baixo. Quão baixo você deve determinar por si mesmo. Eu uso 0,05 no meu projeto atual
Os limites também podem ser aumentados. Muitos aplicativos têm algumas tabelas, que são frequentemente atualizadas e 50 tuplas não são muito. Aumentar para 1000 não deve levar a nenhum problema, mas é claro, você deve considerar seu próprio caso
Você também pode ajustar o vácuo automático e ter configurações diferentes para algumas de suas tabelas
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);Se você configurar o fator de escala e os limites, deverá ficar bem. Você também pode aumentar autovacuum_vacuum_cost_limit, que por padrão é igual avacuum_cost_limit , definido como 200. Esse é um recurso muito importante do vácuo, que não permite consumir todos os recursos e permite que seu aplicativo opere com dados mesmo durante o processo de aspiração. , mas o valor padrão é muito baixo. Aumentar para 1000 não deve levar a atrasos significativos, mas permitirá que o processo a vácuo termine muito mais rápido
Obviamente, você também pode executar o vácuo manualmente. No caso mais simples, você pode ter uma tarefa cron simples, que fará uma limpeza completa todas as noites, quando seu banco de dados não for acessado com frequência
Espero que ajude!