IO:WALWrite - Amazon Relational Database Service
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

IO:WALWrite

Versões compatíveis do mecanismo

Essas informações de eventos de espera são compatíveis com todas as versões do RDS para PostgreSQL 10 e posteriores.

Contexto

A atividade no banco de dados que está gerando dados de log de gravação antecipada preenche primeiro os buffers do WAL e depois grava no disco, de forma assíncrona. O evento de espera IO:WALWrite é gerado quando a sessão SQL aguarda a conclusão da gravação dos dados do WAL no disco para que ela possa liberar a chamada COMMIT da transação.

Possíveis causas do maior número de esperas

Se esse evento de espera ocorrer com frequência, você deve revisar sua workload, o tipo de atualização que ela executa e sua frequência. Especificamente, procure os tipos de atividade a seguir.

Atividade intensa de DML

A alteração de dados nas tabelas do banco de dados não acontece instantaneamente. Uma inserção em uma tabela pode precisar aguardar uma inserção ou uma atualização para a mesma tabela de outro cliente. As instruções da linguagem de manipulação de dados (DML) para alterar valores de dados (INSERT, UPDATE, DELETE, COMMIT, ROLLBACK TRANSACTION) podem ocasionar contenções que fazem com que o arquivo de registro de gravação antecipada aguarde a liberação dos buffers. Essa situação é capturada nas métricas a seguir do Insights de Performance do Amazon RDS, que indicam atividade intensa de DML.

  • tup_inserted

  • tup_updated

  • tup_deleted

  • xact_rollback

  • xact_commit

Para ter mais informações sobre essas métricas, consulte Contadores do Performance Insights para o Amazon RDS para PostgreSQL.

Atividade frequente no ponto de verificação

Os pontos de verificação frequentes contribuem para um tamanho maior do WAL. No RDS para PostgreSQL, as gravações de página inteira estão sempre “ativadas”. As gravações de página inteira ajudam a proteger contra a perda de dados. No entanto, quando a verificação ocorre com muita frequência, o sistema pode sofrer problemas gerais de performance. Isso é especialmente verdadeiro em sistemas com intensa atividade de DML. Em alguns casos, você pode encontrar mensagens de erro em seu postgresql.log afirmando que “os pontos de verificação estão ocorrendo com muita frequência”.

Recomendamos que, ao ajustar os pontos de verificação, você equilibre cuidadosamente a performance com o tempo esperado de recuperação no caso de um desligamento anormal.

Ações

Recomendamos as ações a seguir para reduzir os números desse evento de espera.

Reduza o número de confirmações

Para reduzir o número de confirmações, você pode combinar instruções em blocos de transações. Utilize o Insights de Performance do Amazon RDS para examinar o tipo de consulta que está sendo executada. Você também pode transferir grandes operações de manutenção para o horário de pico. Por exemplo, crie índices ou use operações pg_repack fora do horário de produção.

Monitorar os pontos de verificação

Há dois parâmetros que você pode monitorar para ver com que frequência sua instância de banco de dados do RDS para PostgreSQL está gravando no arquivo WAL para pontos de verificação.

  • log_checkpoints: por padrão, esse parâmetro está ativado. Isso faz com que uma mensagem seja enviada ao log do PostgreSQL para cada ponto de verificação. Essas mensagens de log incluem o número de buffers gravados, o tempo gasto para gravá-los e o número de arquivos WAL adicionados, removidos ou reciclados para determinado ponto de verificação.

    Para obter mais informações sobre esse parâmetro, consulte Error Reporting and Logging (Relatórios de erros e registro em log) na documentação do PostgreSQL.

  • checkpoint_warning: esse parâmetro define um valor limite (em segundos) para a frequência do ponto de verificação acima da qual um aviso é gerado. Por padrão, esse parâmetro não é definido no RDS para PostgreSQL. Você pode definir o valor desse parâmetro para receber um aviso quando as alterações do banco de dados em sua instância de banco de dados do RDS para PostgreSQL forem gravadas a uma taxa para a qual os arquivos WAL não estão dimensionados para serem manipulados. Por exemplo, digamos que você definiu esse parâmetro como 30. Se sua instância do RDS para PostgreSQL precisar gravar alterações com maior frequência do que a cada 30 segundos, o aviso de que “pontos de verificação estão ocorrendo com muita frequência” será enviado ao log do PostgreSQL. Isso pode indicar que seu valor max_wal_size deve ser aumentado.

    Para obter mais informações, consulte Write Ahead Log (Log de gravação antecipada) na documentação do PostgreSQL.

Aumentar a escala de E/S verticalmente

Esse tipo de evento de espera de entrada/saída (IO) pode ser corrigido escalando as operações de entrada e saída por segundo (IOPs) para fornecer uma E/S mais rápida. Escalar a E/S é preferível a escalar a CPU, porque escalar a CPU pode ocasionar ainda mais contenção de E/S, pois a CPU aumentada pode lidar com mais trabalho e, assim, piorar ainda mais o gargalo de E/S. Em geral, recomendamos que você considere ajustar sua workload antes de realizar operações de escalabilidade.

Volume de log dedicado (DLV)

Use um volume de log dedicado (DLV) para uma instância de banco de dados que usa o armazenamento de IOPS provisionadas (PIOPS) utilizando o console do Amazon RDS, AWS CLI a ou a API do Amazon RDS. Um DLV move os logs de transações do banco de dados do PostgreSQL para um volume de armazenamento separado do volume que contém as tabelas do banco de dados. Para ter mais informações, consulte Volume de log dedicado (DLV).