25.2. Configuração do WAL

Existem diversos parâmetros de configuração relacionados com o WAL que afetam o desempenho do banco de dados. Esta seção explica como defini-los. Para obter detalhes gerais sobre como definir parâmetros de configuração para o servidor deve ser consultada a Seção 16.4 .

Os pontos de verificação (checkpoints) são pontos na seqüência de transações onde se garante que os arquivos de dados foram atualizados com todas as informações registradas antes deste ponto. No momento do ponto de verificação, todas as páginas de dados sujas (dirty) são descarregadas no disco, e é escrito um registro especial de ponto de verificação no arquivo de segmento do WAL. Como resultado, no caso de uma queda o procedimento de recuperação sabe a partir de qual ponto do WAL (chamado de registro de refazer (REDO)) deve começar a operação de refazer, uma vez que todas as mudanças feitas nos arquivos de dados anteriores a este ponto já se encontram gravadas em disco. Após ter sido feito o ponto de verificação, nenhum dos arquivos de segmento do WAL, escritos antes do registro de refazer, continua sendo necessário, podendo ser reciclados ou removidos (Quando está sendo feita cópia dos arquivos de segmento do WAL, os arquivos de segmento devem ser copiados antes de serem reciclados ou removidos).

O processo de escrita em segundo plano do servidor realiza, automaticamente, um ponto de verificação de tempo em tempo. Um ponto de verificação é realizado a cada checkpoint_segments do WAL, ou a cada checkpoint_timeout segundos, o que ocorrer primeiro. As definições padrão são 3 segmentos e 300 segundos, respectivamente. Também é possível obrigar a realização de um ponto de verificação utilizando o comando SQL CHECKPOINT.

Reduzir checkpoint_segments e/ou checkpoint_timeout faz os pontos de verificação serem feitos com maior freqüência, permitindo uma recuperação mais rápida após a queda (uma vez que haverá menos trabalho para ser refeito). Entretanto, deve haver um balanço entre isto e o aumento de custo causado pela descarga das páginas sujas com maior freqüência. Além disso, após cada ponto de verificação, para garantir a consistência das páginas de dados, a primeira modificação feita em uma página de dados ocasiona o registro de todo o conteúdo desta página. Por isso, um intervalo de ponto de verificação menor aumenta o volume de saída para o WAL, negando parcialmente o objetivo de utilizar um intervalo menor e, em qualquer caso, causando mais E/S em disco.

Os pontos de verificação são muito dispendiosos, primeiro porque requerem a escrita de todos os buffers sujos correntes, e depois porque resultam em um tráfego adicional subseqüente para o WAL, conforme visto acima. Portanto, é aconselhável definir os parâmetros do ponto de verificação altos o suficiente para que não ocorram com muita freqüência. Como uma verificação de sanidade simples para os parâmetros de ponto de verificação, pode ser definido o parâmetro checkpoint_warning. Se os pontos de verificação ocorrerem antes de checkpoint_warning segundos, será gerada uma mensagem para o log do servidor recomendando o aumento de checkpoint_segments. Uma aparição ocasional desta mensagem não é motivo de alarme, mas se aparecer com freqüência então os parâmetros de controle de ponto de verificação devem ser aumentados.

Há pelo menos um arquivo de segmento e, normalmente, não mais de 2 * checkpoint_segments + 1 arquivos de segmento do WAL. Normalmente cada arquivo de segmento possui o tamanho de 16 MB (embora este tamanho possa ser alterado na construção do servidor). Isto pode ser utilizado para estimar a necessidade de espaço do WAL. Normalmente, quando os arquivos de segmento do WAL antigos não são mais necessários, estes são reciclados (os nome são mudados para se tornarem os próximos segmentos da seqüência numerada). Se, por causa de um pico de pouca duração da taxa de saída para o WAL, existirem mais de 2 * checkpoint_segments + 1 arquivos de segmento, os arquivos de segmento desnecessários serão removidos em vez de reciclados até o sistema voltar a ficar abaixo deste limite.

Existem duas funções do WAL utilizadas com freqüência: LogInsert e LogFlush. A função LogInsert é utilizada para colocar um novo registro nos buffers do WAL na memória compartilhada. Se não houver espaço para o novo registro, LogInsert terá que escrever (mover para o cache do núcleo) uns poucos buffers do WAL cheios. Isto não é desejado, porque LogInsert é utilizada em todas as modificações de baixo nível do banco de dados (por exemplo, inserção de linha), quando um bloqueio exclusivo é mantido nas páginas de dados afetadas, portanto esta operação precisa ser tão rápida quanto for possível. O que é pior, escrever os buffers do WAL também pode obrigar a criação de um novo arquivo de segmento, que toma mais tempo ainda. Normalmente, os buffers do WAL devem ser escritos e descarregados pela chamada LogFlush que é feita, na maioria das vezes, na hora da efetivação da transação para garantir que os registros da transação sejam descarregados no armazenamento permanente. Nos sistemas com saída para o WAL alta, as chamadas à LogFlush podem não ocorrer com uma freqüência suficiente para evitar que LogInsert tenha que realizar escritas. Nestes sistemas, deve ser aumentado o número de buffers do WAL pela modificação do parâmetro wal_buffers. O número padrão de buffers do WAL é 8. O aumento deste valor aumenta de forma correspondente a utilização de memória compartilhada (Deve ser observado que no momento existe pouca evidência sugerindo que aumentar wal_buffers acima do padrão valha a pena).

O parâmetro commit_delay define a quantidade de microssegundos que o processo servidor vai aguardar após escrever um registro de efetivação no WAL com LogInsert, antes de realizar o LogFlush. Este retardo permite que outros processos servidor adicionem seus registros de efetivação ao WAL para que todos sejam descarregados em uma única sincronização do WAL. Não ocorre nenhum retardo quando fsync não está ativado, nem se menos de outras commit_siblings sessões estiverem com transações ativas no momento; isto evita o retardo quando é pouco provável que outras seções efetivem em breve. Deve ser observado que na maioria das plataformas a resolução de uma solicitação de retardo é de dez milissegundos, portanto qualquer definição de commit_delay diferente de zero e entre 1 e 10000 microssegundos produz o mesmo efeito. Ainda não está claro quais são os melhores valores para estes parâmetros; incentiva-se que sejam feitas experiências.

O parâmetro wal_sync_method determina como o PostgreSQL vai fazer a solicitação ao núcleo para forçar o envio das atualizações do WAL para o disco. Todas as opções devem ser idênticas em termos de confiabilidade, mas é bem específico da plataforma qual delas é a mais rápida. Deve ser observado que este parâmetro é irrelevante se fsync estiver desativado.

Ativar o parâmetro de configuração wal_debug (desde que o PostgreSQL tenha sido compilado com suporte ao mesmo) resulta em que cada chamada às funções LogInsert e LogFlush feita pelo WAL seja registrada no log do servidor. Esta opção poderá ser substituída por um mecanismo mais genérico no futuro.