Como soluciono problemas de picos de latência de gravação em minha instância de banco de dados do Amazon RDS?

Breve descrição

A métrica WriteLatency do Amazon CloudWatch define a média de tempo gasto por operação de E/S de disco. De preferência, a latência de gravação não deve ser superior a milissegundos de um dígito.

O pico na latência de gravação para sua instância de banco de dados pode ser causado quando você:

• Cria um backup do Amazon RDS de sua instância de banco de dados mono-AZ
• Converte uma instância do RDS mono-AZ em uma instância multi-AZ
• Restaura de um snapshot de banco de dados
• Executa uma restauração em um ponto anterior no tempo para sua instância de banco de dados
• Cria uma nova réplica de leitura

O pico também resultar de IOPS ou de gargalo de throughput causado pelo peso da workload no banco de dados.

Resolução

Solucionar problemas de pico de latência

1.    Para solucionar as causas de uma alta latência de leitura ou gravação em sua instância de banco de dados, verifique estas métricas do CloudWatch:

• ReadLatency e WriteLatency
• ReadIOPS e WriteIOPS
• ReadThroughput e WriteThroughput
• DiskQueueDepth
• BurstBalance (para armazenamento gp2)

Suponha que você observe um ou mais dos seguintes fatores:

• Os valores de latência são altos.
• Os valores de throughput e IOPS atingiram os limites máximos.
• O valor de DiskQueueDepth é alto.
• O valor de BurstBalance é baixo (para gp2).

Isso significa que sua instância do RDS está sob uma workload pesada e precisa de mais recursos. Para obter mais informações, consulte Como soluciono problemas de latência de volumes do Amazon EBS causados por uma limitação de IOPS na minha instância do Amazon RDS?

Para solucionar problemas que causam um gargalo de IOPS ou de throughput, faça o seguinte:

Para uma instância do RDS com SSD de uso geral (gp2), verifique a classe da instância de banco de dados e o tamanho do armazenamento.

Para uma instância do RDS com IOPS provisionadas (io1), verifique a classe da instância de banco de dados e as IOPS provisionadas definidas.

Para obter mais informações, consulte Classes de instância de banco de dados e instâncias otimizadas para Amazon EBS.

2.    Se as métricas do CloudWatch não indicarem controle de utilização de recursos, verifique as E/S de leitura e E/S de gravação usando o Enhanced Monitoring.

As métricas do CloudWatch são registradas em um intervalo de 60 segundos. Portanto, talvez nem todo pico ou queda seja registrado. No entanto, é possível configurar o detalhamento do Enhanced Monitoring por até um segundo para capturar dados. Qualquer pico na utilização de recursos dentro de um intervalo de 60 segundos pode ser capturado pelo Enhanced Monitoring. Para obter mais informações, consulte How can I identify if my EBS volume is micro-bursting and how can I prevent this from happening? (Como identificar se meu volume do EBS está microexpandindo e como evitar que isso aconteça?)

3.    Se todas as verificações anteriores não indicarem a causa do problema, verifique as métricas do CloudWatch NetworkReceiveThroughput e NetworkTransmitThroughput para garantir que não haja problemas com a rede.

Atenuar o impacto do carregamento lento

Quando você restaura uma instância de banco de dados do RDS com base em um snapshot, a instância de banco de dados continua carregando dados em segundo plano. Esse processo é conhecido como carregamento lento.

O carregamento lento pode ocorrer em todos os cenários que exigem restauração de um snapshot, como restauração em um ponto anterior no tempo, conversão de instância mono-AZ em instância multi-AZ e criação de uma nova réplica de leitura. Se você tentar acessar dados que ainda não foram carregados, a instância de banco de dados baixará imediatamente os dados solicitados do Amazon Simple Storage Service (Amazon S3). Em seguida, a instância continuará carregando o restante dos dados em segundo plano. Para obter mais informações, consulte Snapshots do Amazon EBS. Para ajudar a atenuar os efeitos do carregamento lento em tabelas que precisam ser acessadas rapidamente, execute as operações que envolvem varreduras da tabela inteira, como SELECT *. Isso permite que o RDS baixe todos os dados da tabela de backup do Amazon S3.

Siga as práticas recomendadas

Lembre-se das práticas recomendadas e soluções alternativas a seguir ao tratar alta latência de gravação em sua instância de banco de dados:

• Verifique se tem recursos suficientes alocados ao banco de dados para executar consultas. Com o RDS, a quantidade de recursos alocados depende do tipo de instância.
• Se as métricas do CloudWatch e as do Enhanced Monitoring não indicarem controle de utilização de recursos, use o Performance Insights para monitorar a workload do banco de dados. Com o Performance Insights, é possível identificar as consultas SQL subjacentes em execução em seu banco de dados quando você está enfrentando latência com a aplicação. Use essas informações para avaliar a carga em seu banco de dados e determinar outras ações. Para obter mais informações, consulte Monitoring DB load with Performance Insights on Amazon RDS (Monitorar a carga do banco de dados com o Performance Insights no Amazon RDS).
• Evite a microexpansão alterando o tamanho ou o tipo do volume do Amazon EBS conforme seu caso de uso.
• Para otimizar a performance do banco de dados, verifique se suas consultas estão ajustadas corretamente.
• Ao converter sua instância de banco de dados mono-AZ em uma instância multi-AZ, considere fazer isso fora do horário comercial.
• Para reduzir o impacto do carregamento lento após uma conversão multi-AZ, considere fazer o seguinte:

• Execute um failover manual logo após a conversão para uma instância multi-AZ.
• Execute um despejo completo ou apenas as consultas necessárias para carregar todos os dados das tabelas. Esse processo pode ajudar a carregar os dados e forçar todos os blocos a serem enviados do S3 ao novo host. Para instâncias do Amazon RDS para PostgreSQL, é possível executar o comando pg_prewarm.

• Você pode configurar alarmes do Amazon CloudWatch nas principais métricas do RDS que são úteis para determinar o motivo dos picos de latência de gravação nas instâncias do RDS. Exemplos dessas métricas incluem: ReadIOPS, WriteIOPS, ReadThroughput, WriteThroughput, DiskQueueDepth, ReadLatency e WriteLatency. Você pode usar esses alarmes para garantir que não haja controle de utilização da instância.

---

Informações relacionadas

Práticas recomendadas do Amazon RDS

Understanding Burst vs. Baseline Performance with Amazon RDS and GP2 (Como entender a diferença entre performance intermitente e de referência com o Amazon RDS e o GP2)

Modifying a DB instance to be a Multi-AZ DB instance deployment (Modificar uma instância de banco de dados para ser uma implantação de instância de banco de dados Multi-AZ)

Tutorial: Restore an Amazon RDS DB instance from a DB snapshot (Tutorial: restaurar uma instância de banco de dados do Amazon RDS de um snapshot do banco de dados)