Checkpoints é um conceito central no PostgreSQL. No entanto, muitas pessoas não sabem o que realmente são, nem entendem como ajustar os checkpoints alcançar a eficiência máxima. Esta postagem irá explicar os pontos de verificação e o ajuste de pontos de verificação e, com sorte, lançar alguma luz sobre esses aspectos internos vitais do banco de dados.
Como o PostgreSQL grava dados
Antes de falarmos sobre os pontos de verificação com mais detalhes, é importante entender como o PostgreSQL grava dados.
O mais importante é que devemos presumir que uma falha pode acontecer a qualquer momento. Por que isso é relevante? Bem, queremos garantir que seu banco de dados nunca seja corrompido. A consequência é que não podemos gravar dados diretamente nos arquivos de dados. Por que é que? Suponha que desejamos escrever “1234” no arquivo de dados. E se travássemos depois de “12”? O resultado seria uma linha quebrada em algum lugar da tabela. Talvez faltem entradas de índice e assim por diante – temos que evitar isso a todo custo.
Portanto, é necessária uma maneira mais sofisticada de gravar dados. Como funciona? A primeira coisa que o PostgreSQL faz é enviar dados para o WAL (= registro de gravação antecipada). O WAL é como uma fita sequencial contendo mudanças binárias. Se uma linha for adicionada, o WAL pode conter um registro indicando que uma linha em um arquivo de dados deve ser alterada, pode conter algumas instruções para alterar as entradas de índice, talvez um bloco adicional precise ser escrito e assim por diante. Ele simplesmente contém um fluxo de mudanças.
Assim que os dados forem enviados ao WAL, o PostgreSQL fará alterações na versão em cache de um bloco em buffers compartilhados. Observe que os dados ainda não estão nos arquivos de dados. Agora temos entradas do WAL, bem como alterações feitas nos buffers compartilhados. Se uma solicitação de leitura chegar, ela não chegará aos arquivos de dados de qualquer maneira – porque os dados são encontrados no cache.
Em algum ponto, essas páginas modificadas na memória são gravadas no disco pelo background writer. O importante aqui é que os dados podem ser gravados fora de ordem, o que não é problema. Lembre-se de que se um usuário deseja ler os dados, o PostgreSQL verificará os buffers compartilhados antes de solicitar o bloqueio ao sistema operacional. A ordem em que os blocos sujos são gravados não é, portanto, tão relevante. Até faz sentido gravar dados um pouco mais tarde, para aumentar as chances de enviar muitas alterações para o disco em uma única solicitação de I / O.
WAL
No entanto, não podemos gravar dados no WAL indefinidamente. Em algum momento, o espaço precisa ser reciclado. É exatamente para isso que serve um checkpoint.
O objetivo de um ponto de verificação é garantir que todos os buffers sujos criados até certo ponto sejam enviados para o disco para que o WAL até aquele ponto possa ser reciclado. A maneira como o PostgreSQL faz isso é lançando um processo de checkpointer que grava no disco as alterações que faltam. No entanto, esse processo não envia dados para o disco o mais rápido possível. O motivo é que queremos nivelar a curva de I / O para garantir tempos de resposta estáveis.
O parâmetro para controlar a propagação do ponto de verificação é …
| 12345 | test=# SHOW checkpoint_completion_target;checkpoint_completion_target------------------------------0.5(1 row) |
A ideia é que um checkpoint seja concluído na metade do caminho antes que o próximo checkpoint seja iniciado. Na vida real, um valor de 0,7-0,9 parece ser a melhor escolha para a maioria das cargas de trabalho, mas sinta-se à vontade para experimentar um pouco.
A próxima pergunta importante é: Quando um checkpoint realmente entra em ação? Existem alguns parâmetros para controlar esse comportamento:
| 12345 | test=# SHOW checkpoint_timeout;checkpoint_timeout--------------------5min(1 row) |
| 12345 | test=# SHOW max_wal_size;max_wal_size--------------1GB(1 row) |
Se a carga em seu sistema for baixa, o checkpoint acontecem após um certo período de tempo. O valor padrão é 5 minutos. No entanto, recomendamos aumentar esse valor para otimizar o desempenho de gravação.
NOTA: Sinta-se à vontade para alterar esses valores. Eles afetam o desempenho, mas NÃO colocam seus dados em risco de forma alguma. Além do desempenho, nenhum dado estará em risco.
max_wal_size é um pouco mais complicado: primeiro de tudo, este é um limite flexível – não um limite rígido. Portanto, esteja preparado. A quantidade de WAL pode exceder esse número. A ideia do parâmetro é informar ao PostgreSQL quanto WAL ele pode acumular e ajustar os pontos de verificação de acordo. A regra geral é: aumentar este valor levará a mais consumo de espaço, mas melhora o desempenho de gravação ao mesmo tempo.
Então, por que não definir max_wal_size como infinito? O primeiro motivo é óbvio: você precisará de muito espaço. No entanto, há mais – no caso de seu banco de dados travar, o PostgreSQL deve repetir todas as alterações desde o último checkpoint. Em outras palavras, após uma falha, seu banco de dados pode demorar mais para se recuperar – devido a quantidades absurdamente grandes de WAL acumuladas desde o último checkpoint. Por outro lado, o desempenho melhora se as distâncias dos pontos de verificação aumentam – no entanto, há um limite para o que pode ser feito e alcançado. Em algum ponto, adicionar mais armazenamento ao problema não muda mais nada.
O gravador de segundo plano está gravando alguns blocos sujos no disco. No entanto, em muitos casos, muito mais trabalho é feito pelo próprio processo de ponto de verificação. Portanto, faz sentido se concentrar mais em pontos de verificação do que em otimizar o redator de plano de fundo.
min_wal_size: O parâmetro misterioso
As pessoas (em sessões de treinamento ou clientes de suporte PostgreSQL 24 × 7) freqüentemente perguntam sobre o significado de min_wal_size e max_wal_size. Há muita confusão por aí em relação a esses dois parâmetros. Deixe-me tentar explicar o que está acontecendo aqui. Conforme declarado antes, o PostgreSQL ajusta as distâncias dos pontos de verificação por conta própria. Ele tenta manter o WAL abaixo de max_wal_size. No entanto, se seu sistema estiver ocioso, o PostgreSQL reduzirá gradualmente a quantidade de WAL novamente até min_wal_size. Este não é um processo rápido – acontece gradualmente, ao longo de um período de tempo prolongado.
Vamos supor um cenário simples para ilustrar a situação. Suponha que você tenha um sistema com grande carga de gravação durante a semana, mas ocioso no fim de semana. Sexta à tarde, o tamanho do WAL é, portanto, grande. No entanto, no fim de semana, o PostgreSQL reduzirá gradualmente o tamanho do WAL. Quando a carga for retomada na segunda-feira, os arquivos WAL ausentes serão recriados (o que pode ser um problema em termos de desempenho).
Portanto, pode ser uma boa idéia não definir min_wal_size muito baixo (em comparação com max_wal_size) para reduzir a necessidade de criar novos arquivos WAL quando a carga for reiniciada.
