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

Resolução

Com uma instância ociosa do Amazon Relational Database Service (Amazon RDS) for PostgreSQL, você pode notar um pico na métrica Write Latency (Latência de gravação) do Amazon CloudWatch a cada cinco minutos. Esse pico tem correlação com um pico na métrica Write Total (Total de gravação) do Enhanced Monitoring para aproximadamente 64 MB após a atualização para o PostgreSQL versão 11 ou posterior. O valor do parâmetro wal_segment_size passa a ser 64 MB após a atualização. Esses aumentos podem não ser perceptíveis com a versão 10 ou anterior porque o valor de wal_segment_size é de 16 MB. Para obter mais informações, consulte a atualização de 7 de setembro de 2018 no Amazon RDS - Histórico de documentos.

A configuração archive_timeout no RDS for PostgreSQL está definida como 5 minutos. Essa configuração significa que o processo de arquivamento copia os segmentos Write-Ahead Logging (WAL) a 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 nos gráficos do CloudWatch. No entanto, você pode não ver 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 para simular um sistema ocupado em uma instância do RDS for PostgreSQL com um volume do Amazon Elastic Block Store (Amazon EBS) de 20 GB:

#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.

Mas suponha que você tenha os seguintes casos de uso:

• Você tem uma solicitação de E/S, que leva 10 milissegundos para ser concluída, e outras nove solicitações de E/S, cada uma levando 1 milissegundo para ser concluída. 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 leva 10 milissegundos para ser concluída e não tem outras solicitações 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 leva 10 milissegundos para ser concluída. No entanto, quando você calcula a latência média, a solicitação lenta se destaca no segundo caso de uso em que você tem menos solicitações de E/S em execução 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 a partir somente nessa solicitação. Em um sistema ocupado com várias solicitações de E/S, a maioria com tamanhos de bloco 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 RDS for PostgreSQL ocioso. Se a instância do banco de dados executar uma workload grande, você pode não ver esses picos.

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

Execute o seguinte comando em crontab para criar 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: certifique-se de substituir big_file.txt no comando pelo nome do arquivo.

Além disso, execute o seguinte comando em crontab para criar 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: certifique-se de substituir small_file.txt no comando pelo nome do arquivo.

Você pode notar que a segunda instância do EC2 mostra picos de latência de gravador mais altos no CloudWatch do que a primeira instância do EC2.

Informações relacionadas

Práticas recomendadas para trabalhar com o PostgreSQL