Início / dba / Perguntas / 44657
Accepted
zaadeh
Asked: 2013-06-17 23:40:36 +0800 CST

Quanto tempo levará uma operação de vácuo/autovácuo?

  • 772

Eu gerencio um grande banco de dados (algumas centenas de shows) contendo tabelas com várias funções, algumas delas com milhões de registros. Algumas tabelas recebem apenas um grande número de inserções e exclusões, outras poucas inserções e grande número de atualizações.

O banco de dados é executado no PostgreSQL 8.4 em um sistema Debian 6.0 amd64 com 16 gigabytes de RAM.

A questão às vezes é o processo de autovacuum em uma mesa, leva muito tempo (dias) para ser concluído. Eu quero ser capaz de dizer aproximadamente quanto tempo um comando de vácuo específico levará, para poder decidir se o cancela ou não. Além disso, se houvesse um indicador de progresso para operações de vácuo postgres, seria muito útil.

Editar:

Não estou procurando uma solução à prova de balas. Apenas uma dica grosseira sobre o número de tuplas mortas ou bytes de E/S necessários é suficiente para decidir. É realmente irritante não ter ideia de quando VACUUMterminará, seja o que for.

Eu vi que pg_catalog.pg_stat_all_tablestem uma coluna para o número de tuplas mortas. Portanto, é possível ter uma estimativa, mesmo que isso signifique que alguém tenha que ir ANALYZEà mesa antes. Por outro lado, autovacuum_vacuum_thresholde as autovacuum_vacuum_scale_factorconfigurações por si só provam que o próprio postgres sabe algo sobre a quantidade de mudança nas tabelas e provavelmente a coloca nas mãos do DBA também.

Não tenho certeza de qual consulta executar, porque quando executo VACUUM VERBOSE, vejo que não apenas as tabelas, mas os índices nelas também estão sendo processados.

postgresql vacuum

4 respostas

  1. Best Answer

    No meu PostgreSQL (8.3) eu uso este truque:

    1. Eu recebo o tamanho do disco da tabela usando pg_total_relation_size()- isso inclui índices e tamanho TOAST, que é o que VACUUMprocessa. Isso me dá a idéia de quantos bytes VACUUMtem que ler.
    2. Eu corro VACUUMna mesa.
    3. Eu encontro o piddo VACUUMprocesso (em pg_catalog.pg_stat_activity).
    4. No shell do Linux eu corro while true; do cat /proc/123/io | grep read_bytes; sleep 60; done(onde 123está o pid) - isso me mostra os bytes lidos pelo processo do disco até agora.

    Isso me dá uma ideia aproximada de quantos bytes são processados ​​(lidos) a cada minuto pelo arquivo VACUUM. Presumo que VACUUMdeva ler toda a tabela (incluindo índices e TOAST), cujo tamanho do disco eu conheço da etapa 1.

    Presumo que a tabela seja grande o suficiente para que a maioria de suas páginas devam ser lidas do disco (elas não estão presentes na memória compartilhada do Postgres), então o read_bytescampo é bom o suficiente para ser usado como um contador de progresso.

    Toda vez que eu fazia isso, o total de bytes lidos pelo processo não era mais do que 5% do tamanho total da relação, então acho que essa abordagem pode ser boa o suficiente para você.

    • 49

  2. Achei este post e este post úteis, mas, como outros mencionaram, pode ser difícil calcular o progresso geral do vácuo, pois o processo envolve algumas operações separadas.

    Eu uso esta consulta para monitorar o progresso da verificação da tabela do vácuo, que parece ser a maior parte do trabalho:

    SELECT heap_blks_scanned/cast(heap_blks_total as numeric)*100 as heap_blks_percent, progress.*, activity.query
FROM pg_stat_progress_vacuum AS progress
INNER JOIN pg_stat_activity AS activity ON activity.pid = progress.pid;

    No entanto, isso não incluirá a verificação de índice, que acontece depois, e pode levar o mesmo tempo, se não mais, se você tiver muitos índices. Infelizmente, não consigo encontrar nenhuma maneira de monitorar a varredura/aspiração do índice.

    • 12

  3. Isso é muito difícil de determinar. Você pode ajustar o autovacuuming para ser mais agressivo ou mais suave. Mas quando definido como suave e está atrasado e a carga de E/S básica é muito alta, pode acontecer que ela nunca atinja um estado de vácuo adequado - então você vê o processo executando e executando e executando. Além disso, as edições posteriores do PostreSQL têm recursos de autovacuum muito aprimorados, isso por si só pode ser suficiente para mudar para um deles (de preferência 9.2 como o mais recente).

    A barra de progresso parece uma boa ideia, mas imagino que não seja tão fácil de implementar de forma significativa. Como você tem carga constante em suas tabelas, é bem possível que o progresso esteja aparentemente indo para trás (quero dizer que a contagem / porcentagem de linhas mortas aumenta em vez de diminuir) - então, qual conclusão você tira?

    • 10

  4. Em nossa produção uma das maiores tabelas tinha este log:

    pages: 0 removed, 1801722 remain
tuples: 238912 removed, 42582083 remain, 1396 are dead but not yet removable
buffer usage: 9477565 hits, 3834218 misses, 2220101 dirtied
avg read rate: 2.976 MB/s, avg write rate: 1.723 MB/s
system usage: CPU 68.47s/177.49u sec elapsed 10065.08 sec

    Este é de longe o pior consumo de recursos, todas as outras tabelas levaram menos de 2 s.

    Para ver esses tipos de logs, você deve executar isto:

    alter system set log_autovacuum_min_duration TO 5;

    (por 5 ms), recarregue o arquivo de configuração.

    • 5

relate perguntas