Por que vejo picos de latência de gravação a cada cinco minutos depois de fazer uma atualização da minha instância do Amazon RDS para PostgreSQL para a versão 11 ou superior?

Resolução

Com uma instância ociosa do Amazon RDS para PostgreSQL, você pode notar um pico na métrica Latência de gravação do Amazon CloudWatch a cada cinco minutos. Isso se correlaciona com um pico na métrica Total de gravação do Enhanced Monitoring para aproximadamente 64 MB após a atualização para a versão 11 ou posterior do PostgreSQL. O valor do parâmetro wal_segment_size se torna 64 MB após a atualização. Esses picos podem não ser perceptíveis na versão 10 ou anterior porque o valor de wal_segment_size é 16 MB. Para obter mais informações, consulte a atualização de 7 de setembro de 2018 em Amazon RDS - Histórico de documentação.

A configuração archive_timeout no Amazon RDS para PostgreSQL está definida como 5 minutos. Com essa configuração, o processo de arquivamento copia os segmentos de Write-Ahead Logging (WAL) para serem arquivados no Amazon Simple Storage Service (Amazon S3) a cada cinco minutos. Em um sistema ocioso, esse processo de cópia geralmente é a única operação de E/S e, portanto, essa operação pode ser visivelmente dominante em gráficos do CloudWatch. No entanto, talvez você não veja esse padrão em um sistema ocupado. Por exemplo, suponha que você execute a seguinte workload por 30 minutos em uma instância db.t3.small. Esse exemplo simula um sistema ocupado em uma instância do RDS para PostgreSQL com um volume de 20 GB do Amazon Elastic Block Store (Amazon EBS):

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

Com essa workload, você não vê picos na métrica de Latência de gravação do CloudWatch.

Porém, suponha que você tenha os seguintes casos de uso:

• Você tem uma solicitação de E/S que demora 10 milissegundos para ser concluída e outras nove solicitações de E/S que demoram 1 milissegundo cada para serem concluídas. A latência média dessas solicitações é calculada da seguinte forma:
  Latência média = (10 + (9 * 1)) / 10 = 1,9 milissegundos
• Você tem uma solicitação de E/S que demora 10 milissegundos para ser concluída e não tem nenhuma outra solicitação de E/S. A latência média nesse caso é calculada da seguinte forma:
  Latência média = 10 / 1 = 10 milissegundos

Ambos os casos de uso incluem a mesma solicitação de E/S que demora 10 milissegundos para ser concluída. No entanto, quando você calcula a latência média, a solicitação lenta se destaca. Isso ocorre porque o segundo caso de uso tem menos solicitações de E/S que são executadas junto com a solicitação lenta. Se um sistema ocioso tiver uma solicitação de E/S lenta devido ao alto tamanho do bloco, a latência será calculada somente a partir dessa solicitação. Em um sistema ocupado com várias solicitações de E/S, a maioria com blocos menores, a latência média é calculada a partir de todas essas solicitações.

Nesses casos, você pode ver um pico de Latência de gravação a cada cinco minutos em um sistema Amazon RDS para PostgreSQL ocioso. Se a sua instância de banco de dados executar uma workload ocupada, talvez você não veja esses picos.

Exemplo: suponha que você tenha duas instâncias t2.small do Amazon Elastic Compute Cloud (Amazon EC2), cada uma com oito volumes gp2.

Execute o comando a seguir no crontab. O comando cria um arquivo de 64 MB com um tamanho de bloco de 64 MB a cada cinco minutos na primeira instância do Amazon EC2:

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

Observação: substitua big_file.txt no comando pelo nome do seu arquivo.

Além disso, execute o seguinte comando no crontab. O comando cria 100 arquivos, cada um com um tamanho de bloco de 8 KB a cada minuto na segunda instância do Amazon EC2:

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

Observação: substitua small_file.txt no comando pelo nome do seu arquivo.

Você pode notar que a segunda instância do EC2 mostra maiores picos de Latência de gravação no CloudWatch do que a primeira instância do EC2.

Informações relacionadas

Práticas recomendadas para trabalhar com o PostgreSQL