# io/aurora\_respond\_to\_client
<a name="ams-waits.respond-to-client"></a>

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

**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.respond-to-client.context.supported)
+ [Contexto](#ams-waits.respond-to-client.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.respond-to-client.causes)
+ [Ações](#ams-waits.respond-to-client.actions)

## Versões compatíveis do mecanismo
<a name="ams-waits.respond-to-client.context.supported"></a>

Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 2

## Contexto
<a name="ams-waits.respond-to-client.context"></a>

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
<a name="ams-waits.respond-to-client.causes"></a>

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
<a name="ams-waits.respond-to-client.actions"></a>

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

**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.respond-to-client.actions.identify)
+ [Escalar a classe da instância de banco de dados](#ams-waits.respond-to-client.actions.scale-db-instance-class)
+ [Verificar se há resultados inesperados na workload](#ams-waits.respond-to-client.actions.workload)
+ [Distribuir a workload com instâncias de leitor](#ams-waits.respond-to-client.actions.balance)
+ [Usar o modificador SQL\_BUFFER\_RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)

### Identificar as sessões e as consultas que estão causando os eventos
<a name="ams-waits.respond-to-client.actions.identify"></a>

É 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 Console de gerenciamento da AWS e abra o console do Amazon RDS em [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).

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

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

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

1. 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](https://aws.amazon.com/blogs/database/analyze-amazon-aurora-mysql-workloads-with-performance-insights/).

### Escalar a classe da instância de banco de dados
<a name="ams-waits.respond-to-client.actions.scale-db-instance-class"></a>

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](USER_Monitoring.md). Para obter informações sobre classes de instância de banco de dados, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md). Para ter informações sobre como modificar um cluster de banco de dados, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).

### Verificar se há resultados inesperados na workload
<a name="ams-waits.respond-to-client.actions.workload"></a>

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](USER_PerfInsights_Counters.md).

### Distribuir a workload com instâncias de leitor
<a name="ams-waits.respond-to-client.actions.balance"></a>

É 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](Aurora.Overview.md).

### Usar o modificador SQL\_BUFFER\_RESULT
<a name="ams-waits.respond-to-client.actions.sql-buffer-result"></a>

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](https://dev.mysql.com/doc/refman/5.7/en/select.html), na documentação do MySQL.