Início / dba / Perguntas / 334592
Accepted
Bart Jonk
Asked: 2024-01-05 22:11:00 +0800 CST

Valor sensato para autovacuum_cost_delay

  • 772

Estou executando um data warehouse em uma instância do AWS RDS PostgreSQL. A maior parte do trabalho pesado é feita durante o lote noturno e muitas vezes usamos uma estratégia de reconstrução TRUNCATE, também para tabelas grandes (100 milhões de linhas).

Isso parece causar problemas com o autovacuum, entre 2 e 4 do lote noturno, 7 em cada 10 das instruções TOP SQL são instruções VACUUM ANALYZE para tabelas grandes: insira a descrição da imagem aqui e elas estão abraçando meu sistema RDS e reduzindo o equilíbrio de bytes para 0, após o qual a máquina desacelera enormemente: insira a descrição da imagem aqui
insira a descrição da imagem aqui

Obviamente seria mais sensato adiar a ANÁLISE DE VÁCUO para um período posterior, quando a máquina estiver quase ociosa.

Depois de ler alguma documentação, posso pensar em duas estratégias para fazer isso:

  1. desligue o Autovacuum para essas tabelas grandes e agende um processo que execute o Vacuum mais tarde
  2. defina o autovacuum_cost_delaypara um valor sensato. já que isso adiaria o processamento do Vácuo em geral (ou talvez o definiria com um valor razoável apenas para essas tabelas).

No entanto, qual é um valor sensato neste caso? Eu li que o padrão é 2 milissegundos. Quanto maior é o valor sensato de 200ms? 10 segundos? 1 minuto? 60 minutos?

Estou procurando um valor sensato para começar a testar ou outro conselho que possa me ajudar.

Nota. a máquina tem 2cpu, 16GB m6g.large e estas são as configurações atuais para os parâmetros relacionados ao autovauccum:

insira a descrição da imagem aqui

Informações extras @jjanes sim, mal atinge o equilíbrio de bytes 0, no entanto, este é um equilíbrio cuidadoso que realmente consegui alcançar. Eu regularmente encontrava a situação em que demorava muito para me recuperar de uma situação que, na verdade, caía para 0. Exemplo insira a descrição da imagem aqui

Minha máquina então começa a acumular latência de leitura/gravação e DiskQueueDepth também

O carregamento em massa à noite preocupa muitas mesas (atualmente ~900), que são todas carregadas/transformadas através de jobs entre 23h e 6h30, sendo o horário de maior movimento entre 2h e 4h. Muitas mesas são pequenas, apenas algumas são bastante grandes. insira a descrição da imagem aqui

@jjanes & @frank-heikens, qual versão posterior faz diferença? aqui estão duas capturas de tela da situação antes e depois da migração de 14 para 15: Antes: Depois insira a descrição da imagem aqui : insira a descrição da imagem aqui

Atualização Implementada sugestão de @Laurence Albe. Observações:

Equilíbrio de bytes muito melhor: insira a descrição da imagem aqui

O banco de dados carrega muito mais uniformemente: insira a descrição da imagem aqui

postgresql

2 respostas

  1. Best Answer

    Você deve desabilitar autovacuum_vacuum_insert_thresholdpara as tabelas em questão:

    ALTER TABLE xyz SET (
   autovacuum_vacuum_insert_threshold = -1,
   toast.autovacuum_vacuum_insert_threshold = -1
);

    Então, o carregamento de dados não acionará o vácuo automático. Certifique-se de acionar um explícito VACUUMna tabela após a conclusão do carregamento e antes de começar a consultar a tabela.

    • 2

  2. O gráfico TOP SQL não significa muito. Todas as declarações de vácuo estão próximas do topo apenas devido a Timeout:VacuumDelay (assumindo que o esquema de cores é o mesmo entre os dois painéis). Isso não mostra que o vácuo está apresentando problemas, nem que os está causando. Tudo o que isso mostra é que o vácuo está tentando evitar causar problemas, com nível de sucesso desconhecido. (Um gráfico SQL superior deve excluir esse tipo de horário de sua classificação.)

    O vácuo certamente pode usar muito IO, mas simplesmente não temos nenhuma evidência aqui de que seja isso que está causando o problema. É perfeitamente plausível que seja o próprio carregamento em massa que esteja esgotando seu IO. Você diz que o equilíbrio de IO só chega a zero por um breve momento porque você faz um ato de equilíbrio cuidadoso, mas sem saber qual é esse ato, é difícil usá-lo para atribuir uma causa.

    Você pode querer definir o autovacuum_cost_delay para que o autovacuum por si só não possa esgotar o saldo de IO mais rápido do que sua taxa de recarga. Mas não sabemos qual é essa taxa de recarga, você nos informou o tipo de máquina, mas não o tipo de IO. Mas e se esse nível for muito baixo? Você não pode simplesmente desejar eliminar a necessidade de uma aspiração eficaz; talvez seja necessário comprar mais capacidade de IO.

    Se você preencher as tabelas com COPY FREEZE em vez de INSERT, isso poderá tornar o uso mais eficiente do IO.

    • 0

relate perguntas