O que acontece no ponto de verificação do PostgreSQL?

Durante sua operação, o PostgreSQL registra as alterações nos arquivos de log de transações, mas não as transfere imediatamente para as tabelas reais do banco de dados. Normalmente, ele apenas mantém as alterações na memória e as retorna da memória quando são solicitadas, a menos que a RAM comece a ficar cheia e precise escrevê-las.

Isso significa que, se ele travar, as tabelas no disco não estarão atualizadas. Ele precisa reproduzir os logs de transação, aplicando as alterações nas tabelas em disco, antes de iniciar o backup. Isso pode demorar um pouco para um banco de dados grande e ocupado.

Por isso, e para que os logs de transações não continuem crescendo para sempre, o PostgreSQL faz periodicamente um checkpoint onde garante que o BD está limpo. Ele libera todas as alterações pendentes no disco e recicla os logs de transação que estavam sendo usados ​​para manter um registro de recuperação de falhas das alterações.

Essa descarga acontece em duas fases:

• Buffered write()s de sujeira shared_bufferspara as tabelas; e
• fsync()dos arquivos afetados para garantir que as alterações realmente atinjam o disco

Ambos podem aumentar a carga de E/S do disco. A contenção causada por essas gravações pode desacelerar as leituras e também pode desacelerar a liberação de segmentos WAL necessários para confirmar as transações.

Tem sido um desafio de longa data, mas está piorando à medida que vemos sistemas com mais e mais RAM para que possam armazenar mais dados em buffer e levar mais tempo para escrevê-los. Há uma discussão entre as comunidades Linux e PostgreSQL sobre como lidar com isso no momento, conforme discutido neste artigo do LWN.net . (LWN.net não será capaz de continuar escrevendo este tipo de grande trabalho se as pessoas não se inscreverem. Sou um assinante e compartilho este link porque é útil e informativo. Por favor, considere se inscrever se quiser ver mais deste tipo de coisa.)

A principal coisa que você pode fazer para reduzir o impacto dos pontos de verificação no momento é espalhar a atividade do ponto de verificação aumentando checkpoint_completion_targetpara que mais dados tenham sido gravados quando o ponto de verificação final chegar. No entanto, isso tem um custo - se você atualizar uma página (digamos) dez vezes, ela pode ser gravada no disco várias vezes antes do ponto de verificação com uma meta de conclusão alta, mesmo que tenha estritamente que ser gravada uma vez para segurança contra falhas. Um objetivo de conclusão mais alto cria padrões de I/O mais suaves, mas mais sobrecarga geral de I/O.

A outra coisa que você pode fazer para ajudar é dizer ao seu sistema operacional para começar imediatamente a gravar dados quando receber gravações em buffer. Isso é como o lado do kernel da configuração checkpoint_completion_targete tem uma compensação semelhante. Consulte a documentação do linux vm , em particular dirty_background_bytes, dirty_background_ratio, dirty_expire_centisecs.

A descarga dos buffers sujos do sistema de arquivos do sistema operacional causada por excesso dirty_bytesou dirty_ratio é uma operação de bloqueio de primeiro plano!

Os ajustes do kernel dirty_bytes, dirty_background_bytes, dirty_ratioe controlam dirty_background_ratioa dirty_centisecsliberação de buffers sujos do sistema de arquivos do sistema operacional para o disco. dirty_bytesé o limite em bytes, dirty_ratioé o limite como uma proporção da memória total. dirty_background_bytese dirty_background_ratiosão limites semelhantes, mas a liberação ocorre em segundo plano e não bloqueia outras operações de leitura/gravação até que seja concluída. dirty_centisecsé quantos centissegundos podem passar antes que uma descarga seja iniciada.

Recentemente, os padrões para esses ajustáveis ​​foram reduzidos no Linux, pois o tamanho da memória para máquinas modernas aumentou drasticamente. Mesmo proporções de 5 e 10% para dirty_background_ratioe dirty_ratioem uma máquina de 256 GB podem inundar um sistema de E/S.

Ajustar dirty_background_bytesou dirty_background_ratiocomeçar a liberar buffers sujos em segundo plano é complicado. Felizmente, você pode ajustar essas configurações sem precisar parar o PostgreSQL ou o host, repetindo novos valores para os arquivos apropriados:

$ sudo echo [int value of bytes] > /proc/sys/vm/dirty_background_bytes

por exemplo, para definir o número de bytes sujos para acionar uma descarga de fundo. Se você estiver usando uma placa RAID com bateria, capacitor ou memória flash (você quer manter seus dados em caso de falha, não é?) comece ajustando dirty_background_bytespara 1/2 do tamanho do buffer do cache de gravação e dirty_bytespara 3/4 desse tamanho. Monitore seu perfil de E/S com iostats e, se ainda estiver vendo problemas de latência, isso significa que a carga de gravação do banco de dados ainda está sobrecarregando as liberações do cache do buffer de arquivo. Reduza os valores até que a latência melhore ou considere atualizar seu subsistema de E/S. Placas FusionIO e SSDs são duas possibilidades para taxa de transferência de E/S extrema.

Boa sorte!