Persistir dados estatísticos do stats_temp_directory do Postgres sob demanda

Question

Estamos investigando a carga de E / S em uma de nossas VMs e as possibilidades de otimizá-la e mostramos que a maior parte da carga é gerada pelo coletor de estatísticas do PostgreSQL. Salta entre 3,5 e 6,5 MB / s. Eu já encontrei algumas fontes interessantes em este tópico e eles sugeriram usar o tmpfs para armazenar a maioria das estatísticas na memória, o que faz sentido para mim e a VM concreta tem RAM suficiente livre para suportar tal cenário.

A fonte 1 diz o seguinte:

After restart, the PostgreSQL will copy the files to the new location (and back when it's stopped).

Isso em combinação com o temp no nome da configuração de stats_temp_directory soa como se os dados persistissem em outro lugar.

Então, o que acontece com os dados temporários em caso de desligamento impuro do processo do Postgres? É completamente perdido se o processo foi executado durante a última semana sem nenhum problema? Ou o Postgres regularmente mantém os dados fora do diretório temp durante o tempo de execução? Pode simplesmente usar os dados temporários disponíveis na reinicialização após o desligamento não limpo?

Estou perguntando porque atualmente os dados gravados são persistidos no sistema de arquivos local e as operações para gravar os dados parecem ser atômicas, mas se mudarmos para o tmpfs, os dados de estatísticas por algumas semanas podem ser perdidos se todo o servidor desce por algum motivo.

Existe alguma maneira de fazer o Postgres persistir regularmente em dados fora do tmpfs, como uma vez a cada hora?

Ou eu precisaria usar algum sistema de arquivos overlay / stacked / whatever, montando o persistente como menor, o tmpfs como superior e encontrando alguma maneira de sincronizar manualmente de vez em quando?

Obrigado!

    

Answer 1

Não há nenhuma ferramenta embutida no PostgreSQL para persistir as estatísticas do coletor periodicamente. Eles são considerados substituíveis. Tenha em mente que há uma diferença entre as estatísticas da tabela coletadas pelo analisador e as estatísticas coletadas pelo coletor de estatísticas . O último é o que acontece no stats_temp_directory.

Portanto, sua resposta aqui dependerá do motivo pelo qual você deseja persistir no caso de uma falha. Existem duas razões:

1. Você não quer que o Autovacuum perca tabelas porque perdeu a contagem de atualizações;
2. Você está usando as contagens de atualização da tabela como parte de seu monitoramento em algum lugar.

Eu diria que a primeira razão é provavelmente irrelevante a menos que você tenha alguma razão pela qual o PostgreSQL esteja sendo desligado inesperadamente todos os dias, e nesse caso você deve consertar isso. Além disso, você pode consertar as coisas apenas executando um VACUUM de banco de dados depois de reiniciar o Postgres.

Pela segunda razão, apenas acumular contadores não é útil em si mesmo. Quer dizer, se uma tabela tem 100.000 exclusões durante a sua vida, isso significa que ela tinha 1.000 por dia durante 100 dias, ou isso significa que alguém apagou metade da mesa ontem? Você não sabe Então, se você se preocupa com essas contagens, deve tirar uma foto instantânea de suas estatísticas todos os dias ou todas as horas para que você tenha tempo e conte. Você pode olhar para esta tentativa de reviver o pgStatsPack , uma ferramenta que fez exatamente isso.