A VACUUM ANALYZE regular ainda é recomendada no item 9.1?


38

Estou usando o PostgreSQL 9.1 no Ubuntu. O agendamento VACUUM ANALYZEainda é recomendado ou o vácuo automático é suficiente para atender a todas as necessidades?

Se a resposta for "depende", então:

  • Eu tenho um banco de dados largish (tamanho de despejo compactado de 30 GiB, diretório de dados de 200 GiB)
  • Eu faço ETL no banco de dados, importando perto de 3 milhões de linhas por semana
  • As tabelas com as alterações mais frequentes são todas herdadas de uma tabela mestre, sem dados na tabela mestre (os dados são particionados por semana)
  • Crio rollups por hora e, a partir daí, relatórios diários, semanais e mensais

Estou perguntando porque o agendado VACUUM ANALYZEestá afetando meus relatórios. Ele é executado por mais de 5 horas e tive que eliminá-lo duas vezes esta semana, porque estava afetando as importações regulares de bancos de dados. check_postgresnão relata inchaço significativo no banco de dados, então isso não é realmente um problema.

A partir dos documentos, o autovacuum deve também cuidar da identificação da transação. A pergunta permanece: eu ainda preciso de um VACUUM ANALYZE?


Bem, eu diria 'não', mas a elaboração desta resposta (definindo os parâmetros de vácuo automático, por exemplo) precisaria de algumas experiências em um banco de dados de réplica.
Dez

Respostas:


32

VACUUM é necessário apenas em linhas atualizadas ou excluídas em tabelas não temporárias. Obviamente, você está fazendo muitas INSERTs, mas não é óbvio pela descrição que você também está fazendo muitas UPDATEs ou DELETEs.

Essas operações podem ser rastreadas com a pg_stat_all_tablesvisualização, especificamente as colunas n_tup_upde n_tup_del. Além disso, ainda mais ao ponto, há uma n_dead_tupcoluna que diz, por tabela, quantas linhas precisam ser aspiradas. (consulte Monitorando estatísticas no documento para obter funções e visualizações relacionadas à coleta de estatísticas).

Uma estratégia possível no seu caso seria suprimir o VACUUM agendado, mantendo um olho nessa visão e verificando em quais tabelas as tabelas n_dead_tupestão subindo significativamente. Em seguida, aplique o VACUUM agressivo apenas nessas tabelas. Isso será uma vitória se houver tabelas grandes cujas linhas nunca serão excluídas nem atualizadas e o VACUUM agressivo é realmente necessário apenas em tabelas menores.

Mas continue executando o ANALYZE para que o otimizador sempre tenha novas estatísticas.


4
O Autovacuum também cuida do ANALYZE. Ainda é uma boa idéia executar um ANALYZE manual entre um UPDATE / INSERT / DELETE em massa e imediatamente após grandes consultas. 1 para o bom conselho, no entanto.
Erwin Brandstetter

Obrigado pelo ponteiro para n_dead_tup e amigos. Eu tenho tabelas cumulativas nas quais frequentemente destruo (a cada hora) e recrio milhares de linhas. Vou verificar os valores e agendar adequadamente. A resposta é sempre "monitor, pensar, agir" de qualquer maneira :)
François Beausoleil

25

Não vejo nada na sua pergunta que autovacuumnão resolvesse. Depende em grande parte do padrão de suas atividades de escrita . Você menciona 3 milhões de novas linhas por semana, mas INSERT(ou COPY) normalmente não cria inchaço na tabela e no índice. ( autovacuumapenas é necessário cuidar das estatísticas da coluna , do mapa de visibilidade e de alguns trabalhos menores). UPDATEe DELETEsão a causa dominante do inchaço da tabela e do índice, especialmente ao direcionar linhas aleatórias. Não vejo nada disso na sua pergunta.

autovacuumpercorreu um longo caminho e está fazendo um ótimo trabalho no Postgres 9.1 ou posterior. Eu daria uma olhada nas autovacuumconfigurações . Se a aspiração tender a interferir na sua carga de trabalho, consulte também "Atraso no vácuo com base em custos" . A aspiração manual deve ser uma exceção rara.

Se você tiver muitos UPDATEs aleatórios , convém configurá-lo FILLFACTORpara algo menor que 100, para permitir atualizações HOT imediatamente e reduzir a necessidade VACUUM. Mais sobre atualizações HOT:

Observe também que as tabelas temporárias precisam do manual VACUUM& ANALYZE. Cito o manual emCREATE TABLE :

O daemon de 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.


6

Embora eu concorde que o melhor é usar os recursos automáticos, em vez de executá-lo em todo o banco de dados, na maioria dos casos, é necessário um ajuste de tabela.

Eu não concordo totalmente com a escolha de design do postgres para unir o vácuo e a análise. Vi várias instâncias em que bancos de dados fazem muitas inserções / atualizações, mas pequenas exclusões nunca são realizadas e começam a ter um desempenho ruim.

A solução é ir para as tabelas que são muito usadas e estão sujeitas a consultas grandes e definir as configurações de análise automática para essas tabelas para algo onde elas estão sendo analisadas uma vez ou a cada dois dias.

Você pode acessar as configurações por tabela no gui na guia auto aspirador e verá as configurações de análise que podem ser definidas independentemente do vácuo.

As configurações acabam na tabela de relações e podem ser vistas com a consulta

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

e um valor de amostra de uma análise agressiva pode ser

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Para ver quando a última vez que suas tabelas foram analisadas automaticamente

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;

2
Caso contrário ANALYZE, como o PostgreSQL saberá que as estatísticas mudaram? E como você pode determinar que é isso ANALYZEque leva muito tempo? Ao mesmo tempo, embora não esteja claro qual GUI mencionada acima, você está certo nas configurações específicas por tabela que podem ser úteis.
Dezso
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.