Início / dba / Perguntas / 35327
Accepted
kissgyorgy
Asked: 2013-02-24 09:16:51 +0800 CST

Devo VACUUM manualmente meu banco de dados PostgreSQL se o autovacuum estiver ativado?

  • 772

Eu uso um software que faz um grande banco de dados PostgreSQL (há uma tabela com um milhão de linhas) e os desenvolvedores dizem que eu deveria 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, eu tenho isso:
insira a descrição da imagem aqui

postgresql maintenance

4 respostas

  1. Best Answer

    Concordo com o ETL que não há uma resposta curta. O tamanho não é a única coisa que importa - rodamos bancos de dados PostgreSQL OLTP bastante grandes (com algumas tabelas > 100.000.000 linhas) sob carga pesada e atualmente dependemos apenas do autovacuum.

    No entanto, duas coisas me parecem importantes:

    • Parece haver um consenso de que o autovacuum nunca deve ser desligado, a menos que você tenha uma carga de trabalho muito bem definida em seu banco de dados e saiba exatamente o que está fazendo. Mas, naturalmente, você pode fazer mais VACUUMe/ou ANALYZEcorridas.

    • 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 autovacuum consultando pg_stat_user_tablese pg_class. Eu postei essa consulta em outro tópico, 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 os limites de análise automática. No entanto, a análise automática entra em ação muito antes do autovacuum por padrão e é muito mais barato. Então, basicamente, se o seu banco de dados puder acompanhar o autovacuum, provavelmente também ficará bem com o autoanalyze. As últimas datas de análise automática também podem ser consultadas em pg_stat_user_tables.

    Algumas partes da documentação (mais excelente) do PostgreSQL, que achei úteis:

    • 15

  2. O Autovacuum deve cobrir muito bem, a menos que você tenha configurado algo errado. Outras respostas já cobrem isso.

    Existe um caso claramente definido para manual VACUUM (e mais importante: manual ANALYZE) embora: tabelas temporárias , elas não são consideradas pelo demônio do autovacuum. Cito o manual CREATE TABLEaqui :

    O daemon de autovacuum não pode acessar e, portanto, não pode limpar ou analisar tabelas temporárias. Por esse motivo, as operações apropriadas de vácuo e análise devem ser executadas por meio de comandos SQL de sessão. Por exemplo, se uma tabela temporária for usada em consultas complexas, é aconselhável executá ANALYZE-la depois que ela for preenchida.

    • 7

  3. Não há uma resposta curta para isso, pois depende de muitos fatores. O sistema está lento? O auto-vácuo está realmente tocando esta 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.

    • 4

  4. 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 autovacuum e ajustá-las às suas necessidades

    Para ver suas configurações atuais, execute esta consulta:

    SELECT *
FROM pg_settings 
WHERE name LIKE '%vacuum%'

    A maioria dos campos é autoexplicativa, mas aqui está a documentação sobre eles: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html

    Eu diria que seu objetivo deve ser configurar o autovacuum para limpar o lixo de forma consistente, mas não execute o autovacuum constantemente

    As configurações mais importantes são:

    • autovacuum_vacuum_scale_factor - determina a porcentagem de tuplas que podem estar mortas antes que uma limpeza seja acionada. Valor padrão = 0,2
    • autovacuum_vacuum_threshold - número mínimo de tuplas mortas antes que a limpeza seja acionada. Valor padrão = 50

    O limite ajuda a evitar 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 você tiver uma mesa que ocupa 100 GB, acumulará 20 GB de lixo, antes que o autovacuum seja acionado. Assim, 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 atualizadas com frequência e 50 tuplas não é muito. Aumentar isso para 1000 não deve levar a nenhum problema, mas é claro que você deve considerar seu próprio caso

    Você também pode ajustar o autovacuum e ter configurações diferentes para algumas de suas mesas

    ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);

    Se você configurar scale_factor e thresholds, deve ficar bem. Você também pode aumentar autovacuum_vacuum_cost_limit, que por padrão é igual a vacuum_cost_limit, que é definido como 200. Esta é uma característica muito importante do vácuo, que não permite que ele consuma todos os recursos e permite que seu aplicativo opere com dados mesmo durante o processo de vácuo , mas o valor padrão é muito baixo. Aumentar para 1000 não deve levar a atrasos significativos, mas permitirá que o processo de vácuo termine muito mais rápido

    Claro, você também pode executar o vácuo manualmente. Em um caso mais simples, você pode ter um cron job simples, que fará uma limpeza completa todas as noites, quando seu banco de dados não for acessado com frequência

    Espero que ajude!

    • 1

relate perguntas