io/aurora_respond_to_client - Amazon Aurora
Versões compatíveis do mecanismoContextoPossíveis causas do maior número de esperasAções

io/aurora_respond_to_client

O evento io/aurora_respond_to_client quando um thread está aguardando para retornar um conjunto de resultados a um cliente.

Versões compatíveis do mecanismo

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:

  • Aurora MySQL versão 2

Nas versões anteriores à 2.07.7, 2.09.3 e 2.10.2, esse evento de espera inclui incorretamente o tempo ocioso.

Contexto

O evento io/aurora_respond_to_client indica que um thread está aguardando para retornar um conjunto de resultados a um cliente.

O processamento da consulta está concluído, e os resultados estão sendo retornados ao cliente da aplicação. Porém, como não há largura de banda de rede suficiente no cluster de banco de dados, um thread está aguardando para retornar o conjunto de resultados.

Possíveis causas do maior número de esperas

Quando o evento io/aurora_respond_to_client aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:

Classe de instância de banco de dados insuficiente para a workload

A classe de instância de banco de dados utilizada pelo cluster de banco de dados não tem a largura de banda de rede necessária para processar a workload com eficiência.

Conjuntos de resultados grandes

Houve um aumento no tamanho do conjunto de resultados retornado porque a consulta retorna maiores números de linhas. O conjunto de resultados maior consome mais largura de banda de rede.

Maior carga no cliente

Pode haver pressão da CPU, pressão da memória ou saturação da rede no lado do cliente. Um aumento na carga do cliente atrasa o recebimento de dados do cluster de bancos de dados Aurora MySQL.

Maior latência de rede

Pode haver maior latência de rede entre o cluster de bancos de dados Aurora MySQL e o cliente. A latência de rede mais alta aumenta o tempo necessário para o cliente receber os dados.

Ações

Recomenda-se ações distintas, dependendo dos motivos do evento de espera.

Identificar as sessões e as consultas que estão causando os eventos

É possível utilizar o Performance Insights para mostrar consultas bloqueadas pelo evento de espera io/aurora_respond_to_client. Em geral, bancos de dados com carga de moderada a significativa apresentam eventos de espera. Os eventos de espera podem ser aceitáveis quando a performance é ideal. Se a performance não for ideal, examine onde o banco de dados está passando a maior parte do tempo. Observe os eventos de espera que contribuem para a carga mais alta e descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.

Para localizar consultas SQL que são responsáveis pela carga alta

  1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

  2. No painel de navegação, escolha Performance Insights.

  3. Escolha uma instância de banco de dados. O painel do Performance Insights é exibido para essa instância de banco de dados.

  4. No gráfico Database load (Carga de banco de dados), escolha Slice by wait (Segmentar por espera).

  5. Na parte inferior da página, escolha Top SQL (SQL principal).

    O gráfico mostra as consultas SQL que são responsáveis pela carga. Os que estão no topo da lista são os mais responsáveis. Para solucionar um gargalo, concentre-se nessas instruções.

Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a AWSPublicação no blog de banco de dados sobre como Analisar workloads do Amazon Aurora MySQL com o Performance Insights.

Escalar a classe da instância de banco de dados

Verifique se houve aumentos no valor das métricas do Amazon CloudWatch relacionadas à taxa de transferência da rede, como NetworkReceiveThroughput e NetworkTransmitThroughput. Se a largura de banda da rede da classe da instância de banco de dados estiver sendo atingida, você poderá escalar a classe da instância de banco de dados utilizada pelo cluster de banco de dados modificando o cluster de banco de dados. Uma classe de instância de banco de dados com largura de banda de rede maior retorna dados aos clientes de maneira mais eficiente.

Para obter informações sobre o monitoramento de métricas do Amazon CloudWatch, consulte Visualizar métricas no console do Amazon RDS. Para obter informações sobre classes de instância de banco de dados, consulte Classes de instância de banco de dados Aurora. Para obter informações sobre como modificar um cluster de banco de dados, consulte Modificar um cluster de bancos de dados Amazon Aurora.

Verificar se há resultados inesperados na workload

Verifique a workload no cluster de banco de dados e certifique-se de que ela não esteja gerando resultados inesperados. Por exemplo, pode haver consultas retornando um número maior de linhas que o esperado. Nesse caso, é possível utilizar métricas de contadores do Performance Insights, como Innodb_rows_read. Para obter mais informações, consulte Métricas de contadores do Performance Insights.

Distribuir a workload com instâncias de leitor

É possível distribuir workloads somente leitura com réplicas do Aurora. É possível escalar horizontalmente adicionando mais réplicas do Aurora. Isso pode resultar em um aumento nos limites de controle de utilização para a largura de banda da rede. Para obter mais informações, consulte Clusters de banco de dados do Amazon Aurora.

Usar o modificador SQL_BUFFER_RESULT

Você pode adicionar o modificador SQL_BUFFER_RESULT a instruções SELECT para forçar o resultado em uma tabela temporária antes que eles sejam retornados ao cliente. Esse modificador pode ajudar com problemas de performance quando bloqueios do InnoDB não estão sendo liberados porque as consultas estão no estado de espera io/aurora_respond_to_client. Para obter mais informações, consulte o tópico sobre a Instrução SELECT, na documentação do MySQL.