# Ajustar o Aurora MySQL com eventos de espera
A tabela a seguir resume os eventos de espera do Aurora MySQL que costuma indicar problemas de performance. Os eventos de espera a seguir representam um subconjunto da lista em [Eventos de espera do Aurora MySQL](AuroraMySQL.Reference.Waitevents.md).
| Eventos de espera | Descrição |
| --- | --- |
| [cpu](ams-waits.cpu.md) | Ocorre quando um thread está ativo na CPU ou está aguardando a CPU. |
| [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md) | Ocorre quando uma sessão está gravando dados persistentes no armazenamento do Aurora. |
| [io/aurora\$1respond\$1to\$1client](ams-waits.respond-to-client.md) | Ocorre quando um thread está aguardando para retornar um conjunto de resultados a um cliente. |
| [io/redo\$1log\$1flush](ams-waits.io-redologflush.md) | Ocorre quando uma sessão está gravando dados persistentes no armazenamento do Aurora. |
| [io/socket/sql/client\$1connection](ams-waits.client-connection.md) | Ocorre quando um segmento está em processo de manipulação de uma nova conexão. |
| [io/table/sql/handler](ams-waits.waitio.md) | Ocorre quando o trabalho foi delegado a um mecanismo de armazenamento. |
| [synch/cond/innodb/row\$1lock\$1wait](ams-waits.row-lock-wait.md) | Ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. |
| [synch/cond/innodb/row\$1lock\$1wait\$1cond](ams-waits.row-lock-wait-cond.md) | Ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. |
| [synch/cond/sql/MDL\$1context::COND\$1wait\$1status](ams-waits.cond-wait-status.md) | Ocorre quando há threads aguardando em um bloqueio de metadados de tabela. |
| [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md) | Ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. |
| [synch/mutex/innodb/buf\$1pool\$1mutex](ams-waits.bufpoolmutex.md) | Ocorre quando um thread adquire um bloqueio no grupo de buffers do InnoDB para acessar uma página na memória. |
| [synch/mutex/innodb/fil\$1system\$1mutex](ams-waits.innodb-fil-system-mutex.md) | Ocorre quando uma sessão está aguardando para acessar o cache de memória do espaço de tabelas. |
| [synch/mutex/innodb/trx\$1sys\$1mutex](ams-waits.trxsysmutex.md) | Ocorre quando há alta atividade de banco de dados com muitas transações. |
| [synch/sxlock/innodb/hash\$1table\$1locks](ams-waits.sx-lock-hash-table-locks.md) | Ocorre quando as páginas não encontradas no grupo de buffer devem ser lidas de um arquivo. |
| [synch/mutex/innodb/temp\$1pool\$1manager\$1mutex](ams-waits.io-temppoolmanager.md) | Esse evento ocorre quando uma sessão está aguardando para adquirir um mutex para o grupo de espaços para tabela temporários de sessão. |
# cpu
O evento de espera `cpu` ocorre quando um thread está ativo na CPU ou está aguardando a CPU.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.cpu.context.supported)
+ [Contexto](#ams-waits.cpu.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.cpu.causes)
+ [Ações](#ams-waits.cpu.actions)
## 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ões 2 e 3
## Contexto
Para cada vCPU, uma conexão pode executar o trabalho nessa CPU. Em algumas situações, o número de conexões ativas que estão prontas para execução é superior ao número de vCPUs. Esse desequilíbrio faz com que conexões aguardem recursos da CPU. Se o número de conexões ativas permanecer consistentemente superior ao número de vCPUs, sua instância enfrentará disputa de CPU. A disputa faz com que o evento de espera `cpu` ocorra.
**nota**
A métrica do Performance Insights para CPU é `DBLoadCPU`. O valor de `DBLoadCPU` pode diferir do valor da métrica `CPUUtilization` do CloudWatch. A última métrica é coletada do HyperVisor para uma instância de banco de dados.
As métricas do Performance Insights para o sistema operacional fornecem informações detalhadas sobre a utilização da CPU. Por exemplo, é possível exibir as seguintes métricas:
+ `os.cpuUtilization.nice.avg`
+ `os.cpuUtilization.total.avg`
+ `os.cpuUtilization.wait.avg`
+ `os.cpuUtilization.idle.avg`
O Performance Insights relata o uso da CPU pelo mecanismo de banco de dados como `os.cpuUtilization.nice.avg`.
## Possíveis causas do maior número de esperas
Quando esse evento ocorre mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
+ Consultas analíticas
+ Transações altamente simultâneas
+ Transações de longa execução
+ Um aumento súbito no número de conexões, conhecido como *tempestade de logins*
+ Um aumento na alternância de contexto
## Ações
Se o evento de espera `cpu` domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Responda a esse evento somente quando a performance diminuir.
Dependendo do motivo para o aumento na utilização da CPU, considere as seguintes estratégias:
+ Aumente a capacidade de CPU do host. Em geral, essa abordagem apenas fornece alívio temporário.
+ Identifique as principais consultas para uma possível otimização.
+ Redirecione uma parte da workload somente leitura para nós de leitor, se aplicável.
**Topics**
+ [Identifique as sessões ou consultas que estão causando o problema](#ams-waits.cpu.actions.az-vpc-subnet)
+ [Analisar e otimizar a workload alta da CPU](#ams-waits.cpu.actions.db-instance-class)
### Identifique as sessões ou consultas que estão causando o problema
Para encontrar as sessões e consultas, consulte a tabela **Top SQL** (SQL principal) no Performance Insights em busca das instruções SQL que apresentam a maior carga de CPU. Para obter mais informações, consulte [Análise de métricas usando o painel do Performance Insights](USER_PerfInsights.UsingDashboard.md).
Em geral, uma ou duas instruções SQL consomem a maioria dos ciclos de CPU. Concentre seus esforços nessas instruções. Suponha que a sua instância de banco de dados tenha 2 vCPUs com carga de banco de dados de 3,1 sessões ativas médias (AAS), todas no estado da CPU. Nesse caso, a instância está vinculada à CPU. Considere as estratégias a seguir:
+ Faça upgrade para uma classe de instância maior com mais vCPUs.
+ Ajuste as consultas para ter uma carga de CPU mais baixa.
Neste exemplo, as principais consultas SQL têm uma carga de banco de dados de 1,5 AAS, todas no estado da CPU. Outra instrução SQL tem uma carga de 0,1 no estado da CPU. Neste exemplo, se você interromper a instrução SQL de menor carga, não reduzirá significativamente a carga do banco de dados. Porém, se você otimizar as duas consultas de alta carga de forma que elas sejam duas vezes mais eficientes, eliminará o gargalo da CPU. Se você reduzir a carga da CPU de 1,5 AAS em 50%, a AAS para cada instrução diminuirá para 0,75. A carga total do banco de dados gasta na CPU agora é de 1,6 AAS. Esse valor está abaixo da linha máxima de vCPU de 2,0.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog 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/). Consulte também o artigo do AWS Support sobre [Como solucionar problemas e resolver a alta utilização da CPU em instâncias do Amazon RDS for MySQL](https://aws.amazon.com/premiumsupport/knowledge-center/rds-instance-high-cpu/).
### Analisar e otimizar a workload alta da CPU
Depois de identificar uma ou mais consultas que aumentam o uso da CPU, é possível otimizá-las ou encerrar a conexão. O exemplo a seguir mostra como encerrar uma conexão.
```
CALL mysql.rds_kill(processID);
```
Para obter mais informações, consulte [mysql.rds\$1kill](mysql-stored-proc-ending.md#mysql_rds_kill).
Se você encerrar uma sessão, essa ação poderá disparar uma longa reversão.
#### Siga as diretrizes para otimizar consultas
Para otimizar consultas, considere estas diretrizes:
+ Execute a instrução `EXPLAIN`.
Esse comando mostra as etapas individuais envolvidas na execução de uma consulta. Para obter mais informações, consulte o tópico sobre como [Otimizar operações de bloqueio](https://dev.mysql.com/doc/refman/5.7/en/using-explain.html), na documentação do MySQL.
+ Execute a instrução `SHOW PROFILE`.
Use essa instrução para rever detalhes de perfil que podem indicar o uso de recursos para instruções executadas durante a sessão atual. Para obter mais informações, consulte o tópico sobre a [Instrução SHOW PROFILE](https://dev.mysql.com/doc/refman/5.7/en/show-profile.html), na documentação do MySQL.
+ Execute a instrução `ANALYZE TABLE`.
Use essa instrução para atualizar as estatísticas de índices das tabelas acessadas pela consulta com alto consumo de CPU. Analisando a instrução, você pode ajudar o otimizador a escolher um plano de execução apropriado. Para obter mais informações, consulte o tópico sobre a [Instrução ANALYZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/analyze-table.html), na documentação do MySQL.
#### Siga as diretrizes para melhorar o uso da CPU
Para melhorar o uso da CPU em uma instância de banco de dados, siga estas diretrizes:
+ Verifique se todas as consultas estão utilizando índices adequados.
+ Descubra se é possível utilizar consultas paralelas do Aurora. Você pode usar essa técnica para reduzir o uso da CPU no nó principal, empurrando para baixo o processamento de funções, a filtragem de linhas e a projeção de colunas para a cláusula `WHERE`.
+ Descubra se o número de execuções de SQL por segundo corresponde aos limites esperados.
+ Descubra se a manutenção do índice ou a criação de novos índices ocupam os ciclos de CPU necessários para a sua workload de produção. Programe atividades de manutenção fora dos horários de pico de atividades.
+ Descubra se é possível utilizar particionamentos para ajudar a reduzir o conjunto de dados da consulta. Para obter mais informações, leia a postagem de blog sobre [Como planejar e otimizar o Amazon Aurora com compatibilidade com o MySQL para workloads consolidadas](https://aws.amazon.com/blogs/database/planning-and-optimizing-amazon-aurora-with-mysql-compatibility-for-consolidated-workloads/).
#### Verifique se há tempestades de conexões
Se a métrica `DBLoadCPU` não for muito alta, mas a métrica `CPUUtilization` for muito alta, a causa da alta utilização da CPU é externa ao mecanismo de banco de dados. Um exemplo clássico é uma tempestade de conexões.
Verifique se as seguintes condições são válidas:
+ Há um aumento simultâneo na métrica `CPUUtilization` do Performance Insights e na métrica `DatabaseConnections` do Amazon CloudWatch.
+ O número de threads na CPU é maior que o número de vCPUs.
Se as condições anteriores forem verdadeiras, diminua o número de conexões de banco de dados. Por exemplo, é possível utilizar um grupo de conexões, como o RDS Proxy. Para conhecer as práticas recomendadas de gerenciamento e escalabilidade eficientes de conexões, consulte o whitepaper [Amazon Aurora MySQL DBA Handbook for Connection Management](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
# io/aurora\$1redo\$1log\$1flush
O evento `io/aurora_redo_log_flush` ocorre quando uma sessão está gravando dados persistentes no armazenamento do Amazon Aurora.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.io-auredologflush.context.supported)
+ [Contexto](#ams-waits.io-auredologflush.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.io-auredologflush.causes)
+ [Ações](#ams-waits.io-auredologflush.actions)
## 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
## Contexto
O evento `io/aurora_redo_log_flush` refere-se a uma operação de entrada/saída (E/S) no Aurora MySQL.
**nota**
No Aurora MySQL versão 3, esse evento de espera é denominado [io/redo\$1log\$1flush](ams-waits.io-redologflush.md).
## Possíveis causas do maior número de esperas
Para persistência de dados, as confirmações exigem uma gravação durável no armazenamento estável. Se o banco de dados estiver fazendo muitas confirmações, significa que há um evento de espera na operação de E/S de gravação, o evento de espera `io/aurora_redo_log_flush`.
Nos exemplos a seguir, 50.000 registros são inseridos em um cluster de banco de dados Aurora MySQL com a classe de instância de banco de dados db.r5.xlarge:
+ No primeiro exemplo, cada sessão insere 10.000 registros, linha por linha. Por padrão, se um comando de linguagem de manipulação de dados (DML) não estiver em uma transação, o Aurora MySQL utilizará confirmações implícitas. A confirmação automática está habilitada. Isso significa que há uma confirmação para cada inserção de linha. O Performance Insights mostra que as conexões passam a maior parte do tempo esperando pelo evento de espera `io/aurora_redo_log_flush`.
![\[Exemplo no Performance Insights do evento de espera\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example1.png)
Isso é causado pelas instruções de inserção simples utilizadas.
![\[Instruções de inserção em Top SQL (SQL principal)\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_top_SQL1.png)
Os 50.000 registros demoram 3,5 minutos para serem inseridos.
+ No segundo exemplo, as inserções são feitas em 1.000 lotes, ou seja, cada conexão realiza 10 confirmações em vez de 10.000. O Performance Insights mostra que as conexões não passam a maior parte do tempo no evento de espera `io/aurora_redo_log_flush`.
![\[Exemplo no Performance Insights do evento de espera com menos impacto\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/images/auredologflush_PI_example2.png)
Os 50.000 registros demoram 4 segundos para serem inseridos.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Identificar as sessões e consultas problemáticas](#ams-waits.io-auredologflush.actions.identify-queries)
+ [Agrupar suas operações de gravação](#ams-waits.io-auredologflush.actions.action0)
+ [Desativar a confirmação automática](#ams-waits.io-auredologflush.actions.action1)
+ [Utilizar transações](#ams-waits.io-auredologflush.action2)
+ [Utilizar lotes](#ams-waits.io-auredologflush.action3)
### Identificar as sessões e consultas problemáticas
Se a sua instância de banco de dados estiver enfrentando um gargalo, a primeira tarefa é encontrar as sessões e consultas responsáveis. Leia esta útil postagem no blog de banco dados da AWS 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/).
**Para identificar sessões e consultas que estão causam um gargalo**
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 a instância de banco de dados.
1. Em **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).
As consultas na parte superior da lista estão causando a maior carga no banco de dados.
### Agrupar suas operações de gravação
Os exemplos a seguir acionam o evento de espera `io/aurora_redo_log_flush`. (A confirmação automática está habilitada.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Para reduzir o tempo gasto esperando no evento de espera `io/aurora_redo_log_flush`, agrupe suas operações de gravação logicamente em uma única confirmação para reduzir chamadas persistentes ao armazenamento.
### Desativar a confirmação automática
Desative a confirmação automática antes de fazer grandes alterações que não estejam em uma transação, conforme mostrado no exemplo a seguir.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utilizar transações
É possível utilizar transações, conforme mostrado no exemplo a seguir.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizar lotes
Você pode fazer alterações em lotes, conforme mostrado no exemplo a seguir. No entanto, o uso de lotes muito grandes pode causar problemas de performance, especialmente em réplicas de leitura ou ao fazer uma recuperação em um ponto anterior no tempo (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
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
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 2
## 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.
**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\$1BUFFER\$1RESULT](#ams-waits.respond-to-client.actions.sql-buffer-result)
### 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 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
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
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
É 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\$1BUFFER\$1RESULT
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.
# io/redo\$1log\$1flush
O evento `io/redo_log_flush` ocorre quando uma sessão está gravando dados persistentes no armazenamento do Amazon Aurora.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.io-redologflush.context.supported)
+ [Contexto](#ams-waits.io-redologflush.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.io-redologflush.causes)
+ [Ações](#ams-waits.io-redologflush.actions)
## 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 3
## Contexto
O evento `io/redo_log_flush` refere-se a uma operação de entrada/saída (E/S) no Aurora MySQL.
**nota**
No Aurora MySQL versão 2, esse evento de espera é denominado [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Possíveis causas do maior número de esperas
Para persistência de dados, as confirmações exigem uma gravação durável no armazenamento estável. Se o banco de dados estiver fazendo muitas confirmações, significa que há um evento de espera na operação de E/S de gravação, o evento de espera `io/redo_log_flush`.
Para ver exemplos do comportamento desse evento de espera, consulte [io/aurora\$1redo\$1log\$1flush](ams-waits.io-auredologflush.md).
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Identificar as sessões e consultas problemáticas](#ams-waits.io-redologflush.actions.identify-queries)
+ [Agrupar suas operações de gravação](#ams-waits.io-redologflush.actions.action0)
+ [Desativar a confirmação automática](#ams-waits.io-redologflush.actions.action1)
+ [Utilizar transações](#ams-waits.io-redologflush.action2)
+ [Utilizar lotes](#ams-waits.io-redologflush.action3)
### Identificar as sessões e consultas problemáticas
Se a sua instância de banco de dados estiver enfrentando um gargalo, a primeira tarefa é encontrar as sessões e consultas responsáveis. Leia esta útil postagem no blog de banco dados da AWS 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/).
**Para identificar sessões e consultas que estão causam um gargalo**
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 a instância de banco de dados.
1. Em **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).
As consultas na parte superior da lista estão causando a maior carga no banco de dados.
### Agrupar suas operações de gravação
Os exemplos a seguir acionam o evento de espera `io/redo_log_flush`. (A confirmação automática está habilitada.)
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE id=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
```
Para reduzir o tempo gasto esperando no evento de espera `io/redo_log_flush`, agrupe suas operações de gravação logicamente em uma única confirmação para reduzir chamadas persistentes ao armazenamento.
### Desativar a confirmação automática
Desative a confirmação automática antes de fazer grandes alterações que não estejam em uma transação, conforme mostrado no exemplo a seguir.
```
SET SESSION AUTOCOMMIT=OFF;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
....
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1=xx;
-- Other DML statements here
COMMIT;
SET SESSION AUTOCOMMIT=ON;
```
### Utilizar transações
É possível utilizar transações, conforme mostrado no exemplo a seguir.
```
BEGIN
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
....
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES ('xxxx','xxxxx');
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
....
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1=xx;
-- Other DML statements here
END
```
### Utilizar lotes
Você pode fazer alterações em lotes, conforme mostrado no exemplo a seguir. No entanto, o uso de lotes muito grandes pode causar problemas de performance, especialmente em réplicas de leitura ou ao fazer uma recuperação em um ponto anterior no tempo (PITR).
```
INSERT INTO `sampleDB`.`sampleTable` (sampleCol2, sampleCol3) VALUES
('xxxx','xxxxx'),('xxxx','xxxxx'),...,('xxxx','xxxxx'),('xxxx','xxxxx');
UPDATE `sampleDB`.`sampleTable` SET sampleCol3='xxxxx' WHERE sampleCol1 BETWEEN xx AND xxx;
DELETE FROM `sampleDB`.`sampleTable` WHERE sampleCol1
O evento `io/socket/sql/client_connection` ocorre quando um segmento está em processo de manipulação de uma nova conexão.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.client-connection.context.supported)
+ [Contexto](#ams-waits.client-connection.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.client-connection.causes)
+ [Ações](#ams-waits.client-connection.actions)
## 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ões 2 e 3
## Contexto
O evento `io/socket/sql/client_connection` indica que o mysqld está ocupado criando threads para lidar com novas conexões de cliente recebidas. Nesse cenário, o processamento do atendimento a novas solicitações de conexão de clientes diminui enquanto as conexões aguardam a atribuição do thread. Para obter mais informações, consulte [Servidor MySQL (mysqld)](AuroraMySQL.Managing.Tuning.concepts.md#AuroraMySQL.Managing.Tuning.concepts.processes.mysqld).
## Possíveis causas do maior número de esperas
Quando esse evento aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
+ Há um aumento repentino nas novas conexões de usuário da aplicação para a sua instância do Amazon RDS.
+ Sua instância de banco de dados não consegue processar novas conexões porque a rede, a CPU ou a memória está sendo limitada.
## Ações
Se `io/socket/sql/client_connection` domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Em um banco de dados não ocioso, um evento de espera está sempre na parte superior. Reaja apenas quando a performance piorar. Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Identificar as sessões e consultas problemáticas](#ams-waits.client-connection.actions.identify-queries)
+ [Siga as práticas recomendadas para o gerenciamento de conexões](#ams-waits.client-connection.actions.manage-connections)
+ [Aumentar a escala da sua instância na vertical se os recursos estiverem sendo limitados](#ams-waits.client-connection.upgrade)
+ [Conferir os principais hosts e usuários](#ams-waits.client-connection.top-hosts)
+ [Consultar as tabelas performance\$1schema](#ams-waits.client-connection.perf-schema)
+ [Verificar os estados de threads das suas consultas](#ams-waits.client-connection.thread-states)
+ [Auditar suas solicitações e consultas](#ams-waits.client-connection.auditing)
+ [Agrupar suas conexões de banco de dados](#ams-waits.client-connection.pooling)
### Identificar as sessões e consultas problemáticas
Se a sua instância de banco de dados estiver enfrentando um gargalo, a primeira tarefa é encontrar as sessões e consultas responsáveis. Leia esta útil postagem de blog 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/).
**Para identificar sessões e consultas que estão causam um gargalo**
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 a instância de banco de dados.
1. Em **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).
As consultas na parte superior da lista estão causando a maior carga no banco de dados.
### Siga as práticas recomendadas para o gerenciamento de conexões
Para gerenciar suas conexões, considere as seguintes estratégias:
+ Use o agrupamento de conexões.
É possível aumentar gradualmente o número de conexões conforme necessário. Para obter mais informações, consulte o whitepaper [Amazon Aurora MySQL Database Administrator’s Handbook](https://d1.awsstatic.com/whitepapers/RDS/amazon-aurora-mysql-database-administrator-handbook.pdf).
+ Use um nó de leitor para redistribuir o tráfego somente leitura.
Para obter mais informações, consulte [Réplicas do Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) e [Conexões de endpoints do Amazon Aurora](Aurora.Overview.Endpoints.md).
### Aumentar a escala da sua instância na vertical se os recursos estiverem sendo limitados
Procure exemplos de controle de utilização nos seguintes recursos:
+ CPU
Verifique suas métricas do Amazon CloudWatch com relação ao alto uso da CPU.
+ Rede
Verifique se há um aumento no valor das métricas `network receive throughput` e `network transmit throughput` do CloudWatch. Se sua instância tiver atingido o limite de largura de banda da rede da classe de instância, considere aumentar a escala vertical da sua instância do RDS para um tipo de classe de instância superior. Para obter mais informações, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
+ Memória liberável
Verifique se há uma queda na métrica do CloudWatch `FreeableMemory`. Além disso, considere habilitar o Monitoramento aprimorado. Para obter mais informações, consulte [Monitorar métricas do SO com o monitoramento avançado](USER_Monitoring.OS.md).
### Conferir os principais hosts e usuários
Use o Performance Insights para verificar os principais hosts e usuários. Para obter mais informações, consulte [Análise de métricas usando o painel do Performance Insights](USER_PerfInsights.UsingDashboard.md).
### Consultar as tabelas performance\$1schema
Para obter uma contagem precisa das conexões atuais e totais, consulte as tabelas `performance_schema`. Com essa técnica, você identifica o usuário ou host de origem responsável por criar um alto número de conexões. Por exemplo, consulte as tabelas `performance_schema` da seguinte maneira.
```
SELECT * FROM performance_schema.accounts;
SELECT * FROM performance_schema.users;
SELECT * FROM performance_schema.hosts;
```
### Verificar os estados de threads das suas consultas
Se o problema de performance for contínuo, verifique os estados de thread das suas consultas. No cliente `mysql`, emita o comando a seguir.
```
show processlist;
```
### Auditar suas solicitações e consultas
Para verificar a natureza das solicitações e consultas de contas de usuários, use o recurso de Auditoria avançada do Aurora MySQL. Para aprender a habilitar a auditoria, consulte [Como utilizar a auditoria avançada em um cluster de banco de dados do Amazon Aurora MySQL](AuroraMySQL.Auditing.md).
### Agrupar suas conexões de banco de dados
Considere utilizar o Amazon RDS Proxy para o gerenciamento das conexões. Com o RDS Proxy, você pode permitir que suas aplicações agrupem e compartilhem conexões de banco de dados para melhorar sua capacidade de escala. O proxy do RDS torna as aplicações mais resilientes a falhas de banco de dados conectando-se automaticamente a uma instância de banco de dados em espera e preservando as conexões de aplicações. Para obter mais informações, consulte [Amazon RDS Proxypara Aurora](rds-proxy.md).
# io/table/sql/handler
O evento `io/table/sql/handler` ocorre quando o trabalho foi delegado a um mecanismo de armazenamento.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.waitio.context.supported)
+ [Contexto](#ams-waits.waitio.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.waitio.causes)
+ [Ações](#ams-waits.waitio.actions)
## 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ões 2 e 3
## Contexto
O evento `io/table` indica uma espera pelo acesso a uma tabela. Esse evento ocorre não importa se os dados estão armazenados em cache no grupo de buffer ou acessados no disco. O evento `io/table/sql/handler` indica um aumento na atividade da workload.
Um *manipulador* é uma rotina especializada em um determinado tipo de dados ou focada em certas tarefas especiais. Por exemplo, um manipulador de eventos recebe e digere eventos e sinais provenientes do sistema operacional ou de uma interface de usuário. Um manipulador de memória realiza tarefas relacionadas a memória. Um manipulador de entrada de arquivo é uma função que recebe a entrada de arquivos e realiza tarefas especiais nos dados de acordo com o contexto.
Visualizações como `performance_schema.events_waits_current` muitas vezes indicam `io/table/sql/handler` quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real não é `io/table/sql/handler`, o Performance Insights relata o evento de espera aninhado. Quando o Performance Insights relata `io/table/sql/handler`, isso representa o processamento de InnoDB da solicitação de E/S e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre [Eventos "átomo" e "molécula" no Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html), no *Manual de referência do MySQL*.
O evento `io/table/sql/handler` costuma aparecer nos principais eventos de espera com esperas de E/S, como `io/aurora_redo_log_flush`.
## Possíveis causas do maior número de esperas
No Performance Insights, picos repentinos no evento `io/table/sql/handler` indicam aumento na atividade da workload. O aumento da atividade significa E/S elevada.
O Performance Insights filtra os IDs de eventos de aninhamento e não informa uma espera `io/table/sql/handler` quando o evento aninhado subjacente é uma espera de bloqueio. Por exemplo, se o evento da causa raiz for [synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex](ams-waits.waitsynch.md), o Performance Insights exibirá essa espera nos principais eventos de espera, e não em `io/table/sql/handler`.
Em visualizações como `performance_schema.events_waits_current`, esperas por `io/table/sql/handler` geralmente aparecem quando a espera real é um evento de espera aninhado, como um bloqueio. Quando a espera real é diferente de `io/table/sql/handler`, o Performance Insights procura a espera aninhada e relata a espera real em vez de `io/table/sql/handler`. Quando o Performance Insights relata `io/table/sql/handler`, a espera real é `io/table/sql/handler`, e não um evento de espera aninhado oculto. Para saber mais, consulte o tópico sobre [Eventos "átomo" e "molécula" no Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/performance-schema-atom-molecule-events.html), no *Manual de referência do MySQL 5.7*.
## Ações
Se esse evento de espera domina a atividade do banco de dados, isso não indica necessariamente um problema de performance. Um evento de espera está sempre na parte superior quando o banco de dados está ativo. Você precisará reagir somente quando a performance piorar.
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.waitio.actions.identify)
+ [Verifique se existe uma correlação com as métricas de contadores do Performance Insights](#ams-waits.waitio.actions.filters)
+ [Verificar se existem outros eventos de espera correlacionados](#ams-waits.waitio.actions.maintenance)
### Identificar as sessões e as consultas que estão causando os eventos
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 Publicação no blog 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/).
### Verifique se existe uma correlação com as métricas de contadores do Performance Insights
Verifique as métricas do contador do Performance Insights, como `Innodb_rows_changed`. Se as métricas de contadores estiverem correlacionadas com `io/table/sql/handler`, siga estas etapas:
1. No Performance Insights, procure as instruções SQL que representam o evento de espera principal `io/table/sql/handler`. Se possível, otimize essa instrução de forma que ela retorne menos linhas.
1. Recupere as principais tabelas das visualizações `schema_table_statistics` e `x$schema_table_statistics`. Essas visualizações mostram o tempo gasto por tabela. Para ter mais informações, consulte [As visualizações schema\$1table\$1statistics e x\$1schema\$1table\$1statistics](https://dev.mysql.com/doc/refman/5.7/en/sys-schema-table-statistics.html), no *Manual de referência do MySQL*.
Por padrão, as linhas são classificadas por tempo de espera total em ordem decrescente. Tabelas com mais disputa aparecem primeiro. A saída indica se o tempo é gasto em buscas, inserções, leituras, gravações, atualizações ou exclusões.
```
mysql> select * from sys.schema_table_statistics limit 1\G
*************************** 1. row ***************************
table_schema: read_only_db
table_name: sbtest41
total_latency: 54.11 m
rows_fetched: 6001557
fetch_latency: 39.14 m
rows_inserted: 14833
insert_latency: 5.78 m
rows_updated: 30470
update_latency: 5.39 m
rows_deleted: 14833
delete_latency: 3.81 m
io_read_requests: NULL
io_read: NULL
io_read_latency: NULL
io_write_requests: NULL
io_write: NULL
io_write_latency: NULL
io_misc_requests: NULL
io_misc_latency: NULL
1 row in set (0.11 sec)
```
### Verificar se existem outros eventos de espera correlacionados
Se `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` forem juntos os principais colaboradores para a anomalia de carga de banco de dados, verifique se a variável `innodb_adaptive_hash_index` está habilitada. Se estiver, considere aumentar o valor do parâmetro `innodb_adaptive_hash_index_parts`.
Se o Adaptive Hash Index estiver desabilitado, considere habilitá-lo. Para saber mais sobre o Adaptive Hash Index do MySQL, consulte os seguintes recursos:
+ O artigo [Is Adaptive Hash Index in InnoDB right for my workload?](https://www.percona.com/blog/2016/04/12/is-adaptive-hash-index-in-innodb-right-for-my-workload), no site da Percona
+ [Adaptive Hash Index](https://dev.mysql.com/doc/refman/5.7/en/innodb-adaptive-hash.html), no *Manual de referência do MySQL*
+ O artigo [Contention in MySQL InnoDB: Useful Info From the Semaphores Section](https://www.percona.com/blog/2019/12/20/contention-in-mysql-innodb-useful-info-from-the-semaphores-section/), no site da Percona
**nota**
O Adaptive Hash Index não é compatível com instâncias de banco de dados de leitor do Aurora.
Em alguns casos, a performance pode ser ruim em uma instância de leitor quando `synch/sxlock/innodb/btr_search_latch` e `io/table/sql/handler` são dominantes. Em caso afirmativo, considere redirecionar a workload temporariamente à instância de banco de dados de gravador e habilitar o Adaptive Hash Index.
# synch/cond/innodb/row\$1lock\$1wait
O evento `synch/cond/innodb/row_lock_wait` ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. Para obter mais informações, consulte o tópico sobre [InnoDB locking](https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html) na documentação do MySQL.
## 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 3
## Possíveis causas do maior número de esperas
Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas simultaneamente.
## Ações
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Localizar e responder às instruções SQL responsáveis por esse evento de espera](#ams-waits.row-lock-wait.actions.id)
+ [Localizar e responder à sessão de bloqueio](#ams-waits.row-lock-wait.actions.blocker)
### Localizar e responder às instruções SQL responsáveis por esse evento de espera
Utilize o Performance Insights para identificar as instruções SQL responsáveis por esse evento de espera. Considere as estratégias a seguir:
+ Se bloqueios de linha forem um problema persistente, considere reescrever a aplicação para utilizar o bloqueio otimista.
+ Utilize instruções de várias linhas.
+ Disperse a workload por objetos de banco de dados diferentes. É possível fazer isso por meio de particionamento.
+ Verifique o valor do parâmetro `innodb_lock_wait_timeout`. Ele controla quanto tempo as transações aguardam antes de gerarem um erro de tempo limite.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog 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/).
### Localizar e responder à sessão de bloqueio
Determine se a sessão de bloqueio está ociosa ou ativa. Além disso, descubra se a sessão é proveniente de uma aplicação ou de um usuário ativo.
Para identificar a sessão que está mantendo o bloqueio, é possível executar `SHOW ENGINE INNODB STATUS`. O exemplo a seguir mostra uma saída.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 1688153, ACTIVE 82 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 4244, OS thread handle 70369524330224, query id 4020834 172.31.14.179 reinvent executing
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 24 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 4 n bits 72 index GEN_CLUST_INDEX of table test.t1 trx id 1688153 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Outra alternativa é utilizar a consulta a seguir para extrair detalhes sobre os bloqueios atuais.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_engine_transaction_id waiting_transaction,
ilw.blocking_engine_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_engine_transaction_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state end blocker_state,
concat(il.object_schema,'.', il.object_name) as locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM performance_schema.data_lock_waits ilw
JOIN performance_schema.data_locks il
ON ilw.blocking_engine_lock_id = il.engine_lock_id
AND ilw.blocking_engine_transaction_id = il.engine_transaction_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_engine_transaction_id = it.trx_id join information_schema.processlist p
ON it.trx_mysql_thread_id = p.id join information_schema.innodb_trx it1
ON ilw.requesting_engine_transaction_id = it1.trx_id join information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 4244
waiting_user: reinvent
waiting_host: 123.456.789.012:18158
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 1688153
blocking_lock: 70369562074216:11:4:2:70369549808672
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 1688142
blocker_state: User sleep
locked_table: test.t1
blocker_thread: 4243
blocker_user: reinvent
blocker_host: 123.456.789.012:18156
1 row in set (0.00 sec)
```
Ao identificar a sessão, suas opções incluem:
+ Entre em contato com o proprietário da aplicação ou o usuário.
+ Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md).
Para obter mais informações sobre como identificar transações de bloqueio, consulte [Uso de informações de transações e bloqueios do InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-information-schema-examples.html), na documentação do MySQL.
# synch/cond/innodb/row\$1lock\$1wait\$1cond
O evento `synch/cond/innodb/row_lock_wait_cond` ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. Para obter mais informações, consulte o tópico sobre [InnoDB locking](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html) na documentação do MySQL.
## 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
## Possíveis causas do maior número de esperas
Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas simultaneamente.
## Ações
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Localizar e responder às instruções SQL responsáveis por esse evento de espera](#ams-waits.row-lock-wait-cond.actions.id)
+ [Localizar e responder à sessão de bloqueio](#ams-waits.row-lock-wait-cond.actions.blocker)
### Localizar e responder às instruções SQL responsáveis por esse evento de espera
Utilize o Performance Insights para identificar as instruções SQL responsáveis por esse evento de espera. Considere as estratégias a seguir:
+ Se bloqueios de linha forem um problema persistente, considere reescrever a aplicação para utilizar o bloqueio otimista.
+ Utilize instruções de várias linhas.
+ Disperse a workload por objetos de banco de dados diferentes. É possível fazer isso por meio de particionamento.
+ Verifique o valor do parâmetro `innodb_lock_wait_timeout`. Ele controla quanto tempo as transações aguardam antes de gerarem um erro de tempo limite.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog 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/).
### Localizar e responder à sessão de bloqueio
Determine se a sessão de bloqueio está ociosa ou ativa. Além disso, descubra se a sessão é proveniente de uma aplicação ou de um usuário ativo.
Para identificar a sessão que está mantendo o bloqueio, é possível executar `SHOW ENGINE INNODB STATUS`. O exemplo a seguir mostra uma saída.
```
mysql> SHOW ENGINE INNODB STATUS;
---TRANSACTION 2771110, ACTIVE 112 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 24, OS thread handle 70369573642160, query id 13271336 172.31.14.179 reinvent Sending data
select id1 from test.t1 where id1=1 for update
------- TRX HAS BEEN WAITING 43 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 11 page no 3 n bits 0 index GEN_CLUST_INDEX of table test.t1 trx id 2771110 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
```
Outra alternativa é utilizar a consulta a seguir para extrair detalhes sobre os bloqueios atuais.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Ao identificar a sessão, suas opções incluem:
+ Entre em contato com o proprietário da aplicação ou o usuário.
+ Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md).
Para obter mais informações sobre como identificar transações de bloqueio, consulte [Uso de informações de transações e bloqueios do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html), na documentação do MySQL.
# synch/cond/sql/MDL\$1context::COND\$1wait\$1status
O evento `synch/cond/sql/MDL_context::COND_wait_status` ocorre quando há threads aguardando em um bloqueio de metadados de tabela.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.cond-wait-status.context.supported)
+ [Contexto](#ams-waits.cond-wait-status.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.cond-wait-status.causes)
+ [Ações](#ams-waits.cond-wait-status.actions)
## 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ões 2 e 3
## Contexto
O evento `synch/cond/sql/MDL_context::COND_wait_status` indica que há threads aguardando um bloqueio de metadados de tabela. Em alguns casos, uma sessão mantém um bloqueio de metadados em uma tabela, e outra sessão tenta obter o mesmo bloqueio na mesma tabela. Nesse caso, a segunda sessão aguarda no evento de espera `synch/cond/sql/MDL_context::COND_wait_status`.
O MySQL utiliza o bloqueio de metadados para gerenciar o acesso simultâneo a objetos de banco de dados e garantir a consistência dos dados. O bloqueio de metadados é aplicável a tabelas, esquemas, eventos agendados, espaços de tabelas e bloqueios de usuários adquiridos com a função `get_lock` e programas armazenados. Programas armazenados incluem procedimentos, funções e acionadores. Para ter mais informações, consulte o tópico sobre [Bloqueio de metadados](https://dev.mysql.com/doc/refman/5.7/en/metadata-locking.html), na documentação do MySQL.
A lista de processos do MySQL mostra esta sessão no estado `waiting for metadata lock`. No Performance Insights, se `Performance_schema` estiver habilitado, o evento `synch/cond/sql/MDL_context::COND_wait_status` será exibido.
O tempo limite padrão para uma consulta aguardando um bloqueio de metadados baseia-se no valor do parâmetro `lock_wait_timeout`, cujo padrão é 31.536.000 segundos (365 dias).
Para obter mais detalhes sobre os diferentes bloqueios do InnoDB e os tipos de bloqueios que podem causar conflitos, consulte o tópico sobre [Bloqueio do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html), na documentação do MySQL.
## Possíveis causas do maior número de esperas
Quando o evento `synch/cond/sql/MDL_context::COND_wait_status` aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Transações de longa execução**
Uma ou mais transações estão modificando muitos dados e mantendo bloqueios nas tabelas por muito tempo.
**Transações ociosas**
Uma ou mais transações permanecem abertas por muito tempo, sem serem confirmadas ou revertidas.
**Instruções DDL em tabelas grandes**
Uma ou mais instruções de definição de dados (DDL), como comandos `ALTER TABLE`, foram executadas em tabelas muito grandes.
**Bloqueios de tabela explícitos**
Existem bloqueios explícitos em tabelas que não estão sendo liberados em tempo hábil. Por exemplo, uma aplicação pode executar instruções `LOCK TABLE` incorretamente.
## Ações
Convém tomar medidas diferentes, dependendo das causas do evento de espera e da versão do cluster de banco de dados Aurora MySQL.
**Topics**
+ [Identificar as sessões e as consultas que estão causando os eventos](#ams-waits.cond-wait-status.actions.identify)
+ [Verifique se há eventos anteriores](#ams-waits.cond-wait-status.actions.past-events)
+ [Executar consultas no Aurora MySQL versão 2](#ams-waits.cond-wait-status.actions.run-queries-aurora-mysql-57)
+ [Responder à sessão de bloqueio](#ams-waits.cond-wait-status.actions.blocker)
### 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 `synch/cond/sql/MDL_context::COND_wait_status`. Porém, para identificar a sessão de bloqueio, consulte tabelas de metadados de `performance_schema` e `information_schema` no cluster de banco de dados.
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 dessa instância de banco de dados é exibido.
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/).
### Verifique se há eventos anteriores
É possível obter insights sobre esse evento de espera para conferir se há ocorrências passadas dele. Para isso, conclua as seguintes ações:
+ Verifique a linguagem de manipulação de dados (DML) e a taxa de transferência e latência de DDL para ver se houve alterações na workload.
É possível utilizar o Performance Insights para encontrar consultas aguardando esse evento na ocasião do problema. Também é possível visualizar o resumo das consultas executadas próximo à ocorrência do problema.
+ Se logs de auditoria ou logs gerais estiverem habilitados para o cluster de banco de dados, será possível verificar todas as consultas executadas nos objetos (schema.table) envolvidos na transação em espera. Você também pode verificar consultas com execução concluída antes da transação.
As informações disponíveis para solucionar problemas com eventos anteriores são limitadas. A realização dessas verificações não mostra qual objeto está aguardando informações. No entanto, é possível identificar tabelas com alta carga na ocasião do evento e o conjunto de linhas operadas com frequência que estão causando conflito na ocasião do problema. Em seguida, você pode utilizar essas informações para reproduzir o problema em um ambiente de teste e fornecer insights sobre a sua causa.
### Executar consultas no Aurora MySQL versão 2
No Aurora MySQL versão 2, é possível identificar a sessão bloqueada diretamente, consultando tabelas `performance_schema` ou visualizações de esquema `sys`. Um exemplo é capaz de ilustrar como consultar tabelas para identificar consultas e sessões de bloqueio.
Na saída da lista de processos a seguir, o ID da conexão `89` está aguardando um bloqueio de metadados e está executando um comando `TRUNCATE TABLE`. Em uma consulta nas tabelas `performance_schema` ou visualizações de esquema `sys`, a saída mostra que a sessão de bloqueio é `76`.
```
MySQL [(none)]> select @@version, @@aurora_version;
+-----------+------------------+
| @@version | @@aurora_version |
+-----------+------------------+
| 5.7.12 | 2.11.5 |
+-----------+------------------+
1 row in set (0.01 sec)
MySQL [(none)]> show processlist;
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
| 2 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 4 | rdsadmin | localhost | NULL | Sleep | 2 | NULL | NULL |
| 5 | rdsadmin | localhost | NULL | Sleep | 1 | NULL | NULL |
| 20 | rdsadmin | localhost | NULL | Sleep | 0 | NULL | NULL |
| 21 | rdsadmin | localhost | NULL | Sleep | 261 | NULL | NULL |
| 66 | auroramysql5712 | 172.31.21.51:52154 | sbtest123 | Sleep | 0 | NULL | NULL |
| 67 | auroramysql5712 | 172.31.21.51:52158 | sbtest123 | Sleep | 0 | NULL | NULL |
| 68 | auroramysql5712 | 172.31.21.51:52150 | sbtest123 | Sleep | 0 | NULL | NULL |
| 69 | auroramysql5712 | 172.31.21.51:52162 | sbtest123 | Sleep | 0 | NULL | NULL |
| 70 | auroramysql5712 | 172.31.21.51:52160 | sbtest123 | Sleep | 0 | NULL | NULL |
| 71 | auroramysql5712 | 172.31.21.51:52152 | sbtest123 | Sleep | 0 | NULL | NULL |
| 72 | auroramysql5712 | 172.31.21.51:52156 | sbtest123 | Sleep | 0 | NULL | NULL |
| 73 | auroramysql5712 | 172.31.21.51:52164 | sbtest123 | Sleep | 0 | NULL | NULL |
| 74 | auroramysql5712 | 172.31.21.51:52166 | sbtest123 | Sleep | 0 | NULL | NULL |
| 75 | auroramysql5712 | 172.31.21.51:52168 | sbtest123 | Sleep | 0 | NULL | NULL |
| 76 | auroramysql5712 | 172.31.21.51:52170 | NULL | Query | 0 | starting | show processlist |
| 88 | auroramysql5712 | 172.31.21.51:52194 | NULL | Query | 22 | User sleep | select sleep(10000) |
| 89 | auroramysql5712 | 172.31.21.51:52196 | NULL | Query | 5 | Waiting for table metadata lock | truncate table sbtest.sbtest1 |
+----+-----------------+--------------------+-----------+---------+------+---------------------------------+-------------------------------+
18 rows in set (0.00 sec)
```
Em seguida, uma consulta nas tabelas `performance_schema` ou visualizações de esquema `sys` mostra que a sessão de bloqueio é `76`.
```
MySQL [(none)]> select * from sys.schema_table_lock_waits;
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| object_schema | object_name | waiting_thread_id | waiting_pid | waiting_account | waiting_lock_type | waiting_lock_duration | waiting_query | waiting_query_secs | waiting_query_rows_affected | waiting_query_rows_examined | blocking_thread_id | blocking_pid | blocking_account | blocking_lock_type | blocking_lock_duration | sql_kill_blocking_query | sql_kill_blocking_connection |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
| sbtest | sbtest1 | 121 | 89 | auroramysql5712@192.0.2.0 | EXCLUSIVE | TRANSACTION | truncate table sbtest.sbtest1 | 10 | 0 | 0 | 108 | 76 | auroramysql5712@192.0.2.0 | SHARED_READ | TRANSACTION | KILL QUERY 76 | KILL 76 |
+---------------+-------------+-------------------+-------------+------------------------------+-------------------+-----------------------+-------------------------------+--------------------+-----------------------------+-----------------------------+--------------------+--------------+------------------------------+--------------------+------------------------+-------------------------+------------------------------+
1 row in set (0.00 sec)
```
### Responder à sessão de bloqueio
Ao identificar a sessão, suas opções incluem:
+ Entre em contato com o proprietário da aplicação ou o usuário.
+ Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md).
Para ter mais informações sobre como identificar transações de bloqueio, consulte o tópico sobre como [Utilizar informações de transações e bloqueios do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html), na documentação do MySQL.
# synch/mutex/innodb/aurora\$1lock\$1thread\$1slot\$1futex
O evento `synch/mutex/innodb/aurora_lock_thread_slot_futex` ocorre quando uma sessão bloqueou uma linha para uma atualização e outra linha tenta atualizar a mesma linha. Para ter mais informações, consulte o tópico sobre [Bloqueio InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-locking.html), na *Referência do MySQL*.
## 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
## Possíveis causas do maior número de esperas
Várias instruções de linguagem de manipulação de dados (DML) estão acessando as mesmas linhas simultaneamente.
## Ações
Recomendamos diferentes ações dependendo dos outros eventos de espera exibidos.
**Topics**
+ [Localizar e responder às instruções SQL responsáveis por esse evento de espera](#ams-waits.waitsynch.actions.id)
+ [Localizar e responder à sessão de bloqueio](#ams-waits.waitsynch.actions.blocker)
### Localizar e responder às instruções SQL responsáveis por esse evento de espera
Utilize o Performance Insights para identificar as instruções SQL responsáveis por esse evento de espera. Considere as estratégias a seguir:
+ Se bloqueios de linha forem um problema persistente, considere reescrever a aplicação para utilizar o bloqueio otimista.
+ Utilize instruções de várias linhas.
+ Disperse a workload por objetos de banco de dados diferentes. É possível fazer isso por meio de particionamento.
+ Verifique o valor do parâmetro `innodb_lock_wait_timeout`. Ele controla quanto tempo as transações aguardam antes de gerarem um erro de tempo limite.
Para obter uma visão geral útil da solução de problemas de uso do Performance Insights, consulte a Publicação no blog 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/).
### Localizar e responder à sessão de bloqueio
Determine se a sessão de bloqueio está ociosa ou ativa. Além disso, descubra se a sessão é proveniente de uma aplicação ou de um usuário ativo.
Para identificar a sessão que está mantendo o bloqueio, é possível executar `SHOW ENGINE INNODB STATUS`. O exemplo a seguir mostra uma saída.
```
mysql> SHOW ENGINE INNODB STATUS;
---------------------TRANSACTION 302631452, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 376, 1 row lock(s)
MySQL thread id 80109, OS thread handle 0x2ae915060700, query id 938819 10.0.4.12 reinvent updating
UPDATE sbtest1 SET k=k+1 WHERE id=503
------- TRX HAS BEEN WAITING 2 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 148 page no 11 n bits 30 index `PRIMARY` of table `sysbench2`.`sbtest1` trx id 302631452 lock_mode X locks rec but not gap waiting
Record lock, heap no 30 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
```
Outra alternativa é utilizar a consulta a seguir para extrair detalhes sobre os bloqueios atuais.
```
mysql> SELECT p1.id waiting_thread,
p1.user waiting_user,
p1.host waiting_host,
it1.trx_query waiting_query,
ilw.requesting_trx_id waiting_transaction,
ilw.blocking_lock_id blocking_lock,
il.lock_mode blocking_mode,
il.lock_type blocking_type,
ilw.blocking_trx_id blocking_transaction,
CASE it.trx_state
WHEN 'LOCK WAIT'
THEN it.trx_state
ELSE p.state
END blocker_state,
il.lock_table locked_table,
it.trx_mysql_thread_id blocker_thread,
p.user blocker_user,
p.host blocker_host
FROM information_schema.innodb_lock_waits ilw
JOIN information_schema.innodb_locks il
ON ilw.blocking_lock_id = il.lock_id
AND ilw.blocking_trx_id = il.lock_trx_id
JOIN information_schema.innodb_trx it
ON ilw.blocking_trx_id = it.trx_id
JOIN information_schema.processlist p
ON it.trx_mysql_thread_id = p.id
JOIN information_schema.innodb_trx it1
ON ilw.requesting_trx_id = it1.trx_id
JOIN information_schema.processlist p1
ON it1.trx_mysql_thread_id = p1.id\G
*************************** 1. row ***************************
waiting_thread: 3561959471
waiting_user: reinvent
waiting_host: 123.456.789.012:20485
waiting_query: select id1 from test.t1 where id1=1 for update
waiting_transaction: 312337314
blocking_lock: 312337287:261:3:2
blocking_mode: X
blocking_type: RECORD
blocking_transaction: 312337287
blocker_state: User sleep
locked_table: `test`.`t1`
blocker_thread: 3561223876
blocker_user: reinvent
blocker_host: 123.456.789.012:17746
1 row in set (0.04 sec)
```
Ao identificar a sessão, suas opções incluem:
+ Entre em contato com o proprietário da aplicação ou o usuário.
+ Se a sessão de bloqueio estiver ociosa, considere encerrá-la. Essa ação pode desencadear uma reversão longa. Para saber como encerrar uma sessão, consulte [Encerrar uma sessão ou consulta](mysql-stored-proc-ending.md).
Para ter mais informações sobre como identificar transações de bloqueio, consulte o tópico sobre como [Utilizar informações de transações e bloqueios do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-information-schema-examples.html), no *Manual de referência do MySQL*.
# synch/mutex/innodb/buf\$1pool\$1mutex
O evento `synch/mutex/innodb/buf_pool_mutex` ocorre quando um thread adquire um bloqueio no grupo de buffers do InnoDB para acessar uma página na memória.
**Topics**
+ [Versões de mecanismos relevantes](#ams-waits.bufpoolmutex.context.supported)
+ [Contexto](#ams-waits.bufpoolmutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.bufpoolmutex.causes)
+ [Ações](#ams-waits.bufpoolmutex.actions)
## Versões de mecanismos relevantes
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versão 2
## Contexto
O mutex `buf_pool` é um único mutex que protege as estruturas de dados de controle do grupo de buffer.
Para saber mais, consulte o tópico sobre como [Monitorar esperar de mutex do InnoDB utilizando o Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html), na documentação do MySQL.
## Possíveis causas do maior número de esperas
Este é um evento de espera específico para workload. Causas comuns do surgimento de `synch/mutex/innodb/buf_pool_mutex` entre os principais eventos de espera incluem:
+ O tamanho do grupo de buffer não é suficientemente grande para manter o conjunto de dados de trabalho.
+ A workload é mais específica para determinadas páginas de uma certa tabela no banco de dados, resultando na disputa no grupo de buffer.
## Ações
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.bufpoolmutex.actions.identify)
+ [Utilizar o Performance Insights](#ams-waits.bufpoolmutex.actions.action1)
+ [Criar réplicas do Aurora](#ams-waits.bufpoolmutex.actions.action2)
+ [Examinar o tamanho do grupo de buffer](#ams-waits.bufpoolmutex.actions.action3)
+ [Monitorar o histórico do status global](#ams-waits.bufpoolmutex.actions.action4)
### Identificar as sessões e as consultas que estão causando os eventos
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 visualizar o gráfico Top SQL (SQL principal) no Console de Gerenciamento da AWS**
1. 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. Abaixo do gráfico **Database load** (Carga de banco de dados), 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 Publicação no blog 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/).
### Utilizar o Performance Insights
Esse evento está relacionado à workload. Você pode utilizar o Performance Insights para fazer o seguinte:
+ Identificar quando eventos de espera são iniciados e se há alguma alteração na workload nesse tempo a partir dos logs da aplicação ou origens relacionadas.
+ Identificar as instruções SQL responsáveis por esse evento de espera. Examinar o plano de execução das consultas para garantir que elas sejam otimizadas e estejam utilizando índices apropriados.
Se as principais consultas responsáveis pelo evento de espera estiverem relacionadas ao mesmo objeto ou tabela de banco de dados, considere particionar esse objeto ou tabela.
### Criar réplicas do Aurora
É possível criar réplicas do Aurora para fornecer tráfego somente leitura. Também é possível pode utilizar o Aurora Auto Scaling para lidar com surtos no tráfego de leitura. Certifique-se de executar tarefas agendadas somente leitura e backups lógicos nas réplicas do Aurora.
Para ter mais informações, consulte [Amazon Aurora Auto Scaling com réplicas do Aurora](Aurora.Integrating.AutoScaling.md).
### Examinar o tamanho do grupo de buffer
Verifique se o tamanho do grupo de buffer é suficiente para a workload, observando a métrica `innodb_buffer_pool_wait_free`. Se o valor dessa métrica for alto e estiver aumentando continuamente, isso indica que o tamanho do grupo de buffer não é suficiente para lidar com a workload. Se `innodb_buffer_pool_size` tiver sido definido corretamente, o valor de `innodb_buffer_pool_wait_free` deverá ser pequeno. Para obter mais informações, consulte [Innodb\$1buffer\$1pool\$1wait\$1free](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Innodb_buffer_pool_wait_free), na documentação do MySQL.
Aumente o tamanho do grupo de buffer se a instância de banco de dados tiver memória suficiente para buffers de sessão e tarefas do sistema operacional. Se não tiver, altere a instância de banco de dados para uma classe de instância de banco de dados maior a fim de obter memória adicional que possa ser alocada ao grupo de buffer.
**nota**
O Aurora MySQL ajusta automaticamente o valor de `innodb_buffer_pool_instances` com base no valor de `innodb_buffer_pool_size` configurado.
### Monitorar o histórico do status global
Monitorando as taxas de alteração das variáveis de status, é possível detectar problemas de bloqueio ou memória na sua instância de banco de dados. Habilite o histórico de status global (GoSH) se ele ainda não estiver habilitado. Para obter mais informações sobre o GoSH, consulte o tópico sobre como [Gerenciar o histórico de status global](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.MySQL.CommonDBATasks.html#Appendix.MySQL.CommonDBATasks.GoSH).
Você também pode criar métricas personalizadas do Amazon CloudWatch para monitorar variáveis de status. Para obter mais informações, consulte o tópico sobre como [Publicar métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html).
# synch/mutex/innodb/fil\$1system\$1mutex
O evento `synch/mutex/innodb/fil_system_mutex` ocorre quando uma sessão está aguardando para acessar o cache de memória do espaço de tabelas.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.innodb-fil-system-mutex.context.supported)
+ [Contexto](#ams-waits.innodb-fil-system-mutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.innodb-fil-system-mutex.causes)
+ [Ações](#ams-waits.innodb-fil-system-mutex.actions)
## 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ões 2 e 3
## Contexto
O InnoDB utiliza espaços de tabela para gerenciar a área de armazenamento de tabelas e arquivos de log. O *cache de memória de espaços de tabela* é uma estrutura de memória global que mantém informações sobre espaços de tabela. O MySQL usa esperas `synch/mutex/innodb/fil_system_mutex` para controlar o acesso simultâneo ao cache de memória de espaços de tabela.
O evento `synch/mutex/innodb/fil_system_mutex` indica que atualmente há mais de uma operação que precisa recuperar e manipular informações no cache de memória de espaços de tabela para o mesmo espaço de tabela.
## Possíveis causas do maior número de esperas
Quando o evento `synch/mutex/innodb/fil_system_mutex` aparece mais que o normal, possivelmente indicando um problema de performance, isso geralmente ocorre quando todas as seguintes condições estão presentes:
+ Aumento nas operações simultâneas da linguagem de manipulação de dados (DML) que atualizam ou excluem dados na mesma tabela.
+ O espaço de tabela desta tabela é muito grande e tem muitas páginas de dados.
+ O fator para preenchimento dessas páginas de dados é baixo.
## Ações
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.innodb-fil-system-mutex.actions.identify)
+ [Reorganizar tabelas grandes no horário fora de pico](#ams-waits.innodb-fil-system-mutex.actions.reorganize)
### Identificar as sessões e as consultas que estão causando os eventos
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 Publicação no blog 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/).
Outra maneira de descobrir quais consultas estão causando muitas esperas `synch/mutex/innodb/fil_system_mutex` é verificar `performance_schema`, como no exemplo a seguir.
```
mysql> select * from performance_schema.events_waits_current where EVENT_NAME='wait/synch/mutex/innodb/fil_system_mutex'\G
*************************** 1. row ***************************
THREAD_ID: 19
EVENT_ID: 195057
END_EVENT_ID: 195057
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:6700
TIMER_START: 1010146190118400
TIMER_END: 1010146196524000
TIMER_WAIT: 6405600
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 2. row ***************************
THREAD_ID: 23
EVENT_ID: 5480
END_EVENT_ID: 5480
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:5906
TIMER_START: 995269979908800
TIMER_END: 995269980159200
TIMER_WAIT: 250400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
*************************** 3. row ***************************
THREAD_ID: 55
EVENT_ID: 23233794
END_EVENT_ID: NULL
EVENT_NAME: wait/synch/mutex/innodb/fil_system_mutex
SOURCE: fil0fil.cc:449
TIMER_START: 1010492125341600
TIMER_END: 1010494304900000
TIMER_WAIT: 2179558400
SPINS: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
INDEX_NAME: NULL
OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 47285552262176
NESTING_EVENT_ID: 23233786
NESTING_EVENT_TYPE: WAIT
OPERATION: lock
NUMBER_OF_BYTES: NULL
FLAGS: NULL
```
### Reorganizar tabelas grandes no horário fora de pico
Reorganize tabelas grandes que você identifica como a fonte de números elevados de eventos de espera `synch/mutex/innodb/fil_system_mutex` durante uma janela de manutenção fora do horário de produção. Isso garante que a limpeza do mapa de espaços de tabela internos não ocorra quando o acesso rápido à tabela for essencial. Para obter informações sobre como reorganizar tabelas, consulte a [Instrução OPTIMIZE TABLE](https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html), na *Referência do MySQL*.
# synch/mutex/innodb/trx\$1sys\$1mutex
O evento `synch/mutex/innodb/trx_sys_mutex` ocorre quando há alta atividade de banco de dados com muitas transações.
**Topics**
+ [Versões de mecanismos relevantes](#ams-waits.trxsysmutex.context.supported)
+ [Contexto](#ams-waits.trxsysmutex.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.trxsysmutex.causes)
+ [Ações](#ams-waits.trxsysmutex.actions)
## Versões de mecanismos relevantes
Essas informações de eventos de espera têm suporte nas seguintes versões do mecanismo:
+ Aurora MySQL versões 2 e 3
## Contexto
Internamente, o mecanismo de banco de dados InnoDB utiliza o nível de isolamento de leitura repetível com snapshots para fornecer consistência de leitura. Isso fornece uma visão pontual do banco de dados na ocasião em que o snapshot foi criado.
No InnoDB, todas as alterações são aplicadas ao banco de dados logo que chegam, independentemente de terem sido confirmadas ou não. Essa abordagem significa que, sem o controle de simultaneidade de várias versões (MVCC), todos os usuários conectados ao banco de dados visualizam todas as alterações e as linhas mais recentes. Portanto, o InnoDB requer uma maneira de acompanhar as alterações para saber o que deve ser revertido quando necessário.
Para fazer isso, o InnoDB utiliza um sistema de transações (`trx_sys`) para acompanhar snapshots. Esse sistema de transações faz o seguinte:
+ Acompanha o ID da transação para cada linha nos logs de operações desfazer.
+ Usa uma estrutura interna do InnoDB denominada `ReadView`, que ajuda a identificar quais IDs de transação estão visíveis para um snapshot.
## Possíveis causas do maior número de esperas
Qualquer operação de banco de dados que exija manuseio consistente e controlado (criação, leitura, atualização e exclusão) de IDs de transações gera uma chamada de `trx_sys` para o mutex.
Essas chamadas acontecem dentro de três funções:
+ `trx_sys_mutex_enter` – Cria o mutex.
+ `trx_sys_mutex_exit` – Libera o mutex.
+ `trx_sys_mutex_own` – Testa se existe uma propriedade para o mutex.
A instrumentação do Performance Schema do InnoDB rastreia todas as chamadas de mutex `trx_sys`. O acompanhamento inclui, mas não se limita a, o gerenciamento de `trx_sys` na inicialização ou encerramento do banco de dados, operações de reversão, limpezas de operações desfazer, acesso de leitura de linha e cargas de grupo de buffer. A alta atividade do banco de dados com um grande número de transações resulta no surgimento de `synch/mutex/innodb/trx_sys_mutex` entre os principais eventos de espera.
Para saber mais, consulte o tópico sobre como [Monitorar esperar de mutex do InnoDB utilizando o Performance Schema](https://dev.mysql.com/doc/refman/5.7/en/monitor-innodb-mutex-waits-performance-schema.html), na documentação do MySQL.
## Ações
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.trxsysmutex.actions.identify)
+ [Examinar outros eventos de espera](#ams-waits.trxsysmutex.actions.action1)
### Identificar as sessões e as consultas que estão causando os eventos
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. Descubra se é possível otimizar o banco de dados e a aplicação para reduzir esses eventos.
**Para visualizar o gráfico Top SQL (SQL principal) no Console de gerenciamento da AWS**
1. 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. Abaixo do gráfico **Database load** (Carga de banco de dados), 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 Publicação no blog 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/).
### Examinar outros eventos de espera
Examine os outros eventos de espera associados ao evento de espera `synch/mutex/innodb/trx_sys_mutex`. Isso pode fornecer mais informações sobre a natureza da workload. Um número elevado de transações pode reduzir a taxa de transferência, mas a workload também pode tornar isso necessário.
Para obter mais informações sobre como otimizar transações, consulte o tópico sobre como [Otimizar o gerenciamento de transações do InnoDB](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html), na documentação do MySQL.
# synch/sxlock/innodb/hash\$1table\$1locks
O evento `synch/sxlock/innodb/hash_table_locks` ocorre quando as páginas não encontradas no grupo de buffer devem ser lidas do armazenamento.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.sx-lock-hash-table-locks.context.supported)
+ [Contexto](#ams-waits.sx-lock-hash-table-locks.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.sx-lock-hash-table-locks.causes)
+ [Ações](#ams-waits.sx-lock-hash-table-locks.actions)
## Versões compatíveis do mecanismo
Essas informações de eventos de espera têm suporte nas seguintes versões:
+ Aurora MySQL versões 2 e 3
## Contexto
O evento `synch/sxlock/innodb/hash_table_locks` indica que uma workload está acessando com frequência dados que não estão armazenados no grupo de buffer. Esse evento de espera está associado a novas adições de página e remoções de dados antigos do grupo de buffer. Os dados armazenados no grupo de buffer antigos e os dados novos devem ser armazenados em cache, para que as páginas antigas sejam despejadas de forma a permitir o armazenamento em cache das novas páginas. O MySQL aplica um algoritmo menos utilizado recentemente (LRU) para expulsar páginas do grupo de buffers. A workload está tentando acessar dados que não foram carregados no grupo de buffer ou dados que foram despejados do grupo de buffer.
Esse evento de espera ocorre quando a workload deve acessar os dados em arquivos no disco ou quando os blocos são liberados ou adicionados à lista de LRUs do grupo de buffer. Essas operações esperam até obter um bloqueio excluído compartilhado (SX-lock). Esse SX-lock é utilizado para a sincronização na *tabela de hash*, uma tabela na memória projetada para melhorar a performance do acesso ao grupo de buffer.
Para obter mais informações, consulte o tópico sobre o [Grupo de buffer](https://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool.html), na documentação do MySQL.
## Possíveis causas do maior número de esperas
Quando o evento de espera `synch/sxlock/innodb/hash_table_locks` aparece mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem:
**Um grupo de buffers subdimensionado**
O tamanho do grupo de buffer é muito pequeno para manter na memória todas as páginas frequentemente acessadas.
**Workload pesada**
A workload está causando despejos frequentes e recarregamentos de páginas de dados no cache de buffer.
**Erros de leitura das páginas**
Ocorrem erros ao ler páginas no grupo de buffer, o que pode indicar corrupção dos dados.
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Aumentar o tamanho do grupo de buffer](#ams-waits.sx-lock-hash-table-locks.actions.increase-buffer-pool-size)
+ [Melhorar padrões de acesso a dados](#ams-waits.sx-lock-hash-table-locks.actions.improve-data-access-patterns)
+ [Reduzir ou evitar varreduras de tabelas inteiras](#ams-waits.sx-lock-hash-table-locks.actions.reduce-full-table-scans)
+ [Verificar se há páginas corrompidas nos logs de erros](#ams-waits.sx-lock-hash-table-locks.actions.check-error-logs)
### Aumentar o tamanho do grupo de buffer
Certifique-se de que o grupo de buffer esteja apropriadamente escalado para a workload. Para isso, é possível verificar a taxa de acertos do cache do grupo de buffer. Em geral, se o valor cair abaixo de 95%, considere aumentar o tamanho do grupo de buffer. Um grupo de buffer maior pode manter por mais tempo na memória as páginas acessadas com frequência. Para aumentar o tamanho do grupo de buffer, modifique o valor do parâmetro `innodb_buffer_pool_size`. O valor padrão desse parâmetro baseia-se no tamanho da classe da instância de banco de dados. Para obter mais informações, consulte [Práticas recomendadas para a configuração do banco de dados do Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/best-practices-for-amazon-aurora-mysql-database-configuration/).
### Melhorar padrões de acesso a dados
Confira as consultas afetadas por essa espera e seus planos de execução. Considere melhorar padrões de acesso a dados. Por exemplo, se você estiver utilizando [mysqli\$1result::fetch\$1array](https://www.php.net/manual/en/mysqli-result.fetch-array.php), poderá tentar aumentar o tamanho da busca das matrizes.
É possível utilizar o Performance Insights para mostrar consultas e sessões que possam estar causando o evento de espera `synch/sxlock/innodb/hash_table_locks`.
**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/).
### Reduzir ou evitar varreduras de tabelas inteiras
Monitore sua workload para ver se ela está executando varreduras de tabelas inteiras e, se estiver, reduza ou evite essas varreduras. Por exemplo, é possível monitorar variáveis de status como `Handler_read_rnd_next`. Para obter mais informações, consulte o tópico sobre [Variáveis de status do servidor](https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Handler_read_rnd_next), na documentação do MySQL.
### Verificar se há páginas corrompidas nos logs de erros
É possível consultar mysql-error.log em busca de mensagens relacionadas a corrupções que foram detectadas perto do momento do problema. As mensagens com as quais é possível trabalhar para solucionar o problema estão no log de erros. Talvez seja necessário recriar objetos que foram sinalizados como corrompidos.
# synch/mutex/innodb/temp\$1pool\$1manager\$1mutex
O evento de espera `synch/mutex/innodb/temp_pool_manager_mutex` ocorre quando uma sessão está aguardando para adquirir um mutex para gerenciar o grupo de espaços para tabela temporários de sessão.
**Topics**
+ [Versões compatíveis do mecanismo](#ams-waits.io-temppoolmanager.context.supported)
+ [Contexto](#ams-waits.io-temppoolmanager.context)
+ [Possíveis causas do maior número de esperas](#ams-waits.io-temppoolmanager.causes)
+ [Ações](#ams-waits.io-temppoolmanager.actions)
## 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 3
## Contexto
O Aurora MySQL versão 3.x e posterior usa `temp_pool_manager_mutex` para controlar várias sessões acessando o grupo temporário de espaços para tabela ao mesmo tempo. O Aurora MySQL gerencia o armazenamento por meio de um volume de cluster do Aurora para dados persistentes e armazenamento local para arquivos temporários. Um espaço para tabela temporário é necessário quando uma sessão cria uma tabela temporária no volume de cluster do Aurora.
Quando uma sessão solicita pela primeira vez um espaço para tabela temporário, o MySQL aloca espaços para tabela temporários da sessão do grupo compartilhado. Uma sessão pode conter até dois espaços para tabela temporários por vez para os seguintes tipos de tabela:
+ Tabelas temporárias criadas pelo usuário.
+ Tabelas temporárias internas geradas pelo otimizador
O mecanismo `TempTable` padrão usa o seguinte mecanismo de transbordamento para lidar com tabelas temporárias:
+ Armazena tabelas na RAM até o limite [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram).
+ Muda para arquivos mapeados na memória no armazenamento local quando a RAM está cheia.
+ Usa o volume do cluster compartilhado quando os arquivos mapeados na memória atingem o limite [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap).
Depois que as tabelas temporárias excedem os limites da RAM e do armazenamento local, o MySQL as gerencia usando o espaço para tabela em disco.
Quando uma sessão exige uma tabela temporária em disco, o MySQL:
+ Procura espaços para tabela `INACTIVE` disponíveis no grupo para reutilização.
+ Criará dez espaços para tabela se não existirem espaços `INACTIVE`.
Quando uma sessão é desconectada, o MySQL:
+ Trunca os espaços para tabela temporários da sessão.
+ Marca-os como INACTIVE no grupo para reutilização.
+ Mantém o tamanho atual do grupo até a reinicialização do servidor.
+ Volta ao tamanho padrão do grupo (dez espaços para tabela) após a reinicialização.
## Possíveis causas do maior número de esperas
Situações comuns que causam esse evento de espera:
+ Sessões simultâneas que criam tabelas temporárias internas no volume do cluster.
+ Sessões simultâneas que criam tabelas temporárias no volume do cluster.
+ Encerramento repentino de sessões que usam espaços para tabela ativos.
+ Expansão do grupo de espaços para tabela durante workloads com uso intenso de gravação.
+ Consultas simultâneas que acessam `INFORMATION_SCHEMA.`
## Ações
Recomenda-se ações distintas, dependendo dos motivos do evento de espera.
**Topics**
+ [Monitorar e otimizar o uso de tabelas temporárias](#ams-waits.io-temppoolmanager.actions.monitor)
+ [Analisar as consultas usando INFORMATION\$1SCHEMA](#ams-waits.io-temppoolmanager.actions.schema-queries)
+ [Aumentar o parâmetro innodb\$1sync\$1array\$1size](#ams-waits.io-temppoolmanager.actions.sync_array)
+ [Implementar um pool de conexões](#ams-waits.io-temppoolmanager.actions.connection_pooling)
### Monitorar e otimizar o uso de tabelas temporárias
Para monitorar e otimizar o uso de tabelas temporárias, use um destes métodos:
+ Confira o contador `Created_tmp_disk_tables` no Insights de Performance para monitorar a criação de tabelas temporárias em disco no cluster do Aurora.
+ Execute este comando em seu banco de dados para monitorar diretamente a criação de tabelas temporárias: `mysql> show status like '%created_tmp_disk%'`.
**nota**
O comportamento da tabela temporária difere entre os nós de leitura e gravação do Aurora MySQL. Para obter mais informações, consulte [Novo comportamento de tabela temporária no Aurora MySQL versão 3](ams3-temptable-behavior.md).
Depois de identificar as consultas que criam tabelas temporárias, siga estas etapas de otimização:
+ Use `EXPLAIN` para examinar os planos de execução de consultas e identificar onde e por que as tabelas temporárias estão sendo criadas.
+ Modifique as consultas para reduzir o uso de tabelas temporárias sempre que possível.
Se a otimização de consultas por si só não resolver os problemas de performance, pense em ajustar estes parâmetros de configuração:
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_ram): controla o uso máximo de RAM para tabelas temporárias.
+ [https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_temptable_max_mmap): define o limite para armazenamento de arquivos mapeados na memória.
+ [https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_tmp_table_size): aplica-se quando `aurora_tmptable_enable_per_table_limit` está habilitado (desabilitado por padrão).
**Importante**
Observe que determinadas condições de consulta sempre exigirão tabelas temporárias em disco, independentemente das configurações. Para acessar mais informações sobre o mecanismo de armazenamento `TempTable`, consulte [Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL](https://aws.amazon.com/blogs/database/use-the-temptable-storage-engine-on-amazon-rds-for-mysql-and-amazon-aurora-mysql/).
### Analisar as consultas usando INFORMATION\$1SCHEMA
Quando você consulta tabelas `INFORMATION_SCHEMA`, o MySQL cria tabelas temporárias do InnoDB no volume do cluster. Cada sessão precisa de um espaço para tabela temporário para essas tabelas, o que pode causar problemas de performance durante o alto acesso simultâneo.
Para melhorar a performance:
+ Use `PERFORMANCE_SCHEMA` em vez de `INFORMATION_SCHEMA` sempre que possível.
+ Se você precisar usar `INFORMATION_SCHEMA`, reduza a frequência com que você executa essas consultas.
### Aumentar o parâmetro innodb\$1sync\$1array\$1size
O parâmetro `innodb_sync_array_size` controla o tamanho da matriz de espera mutex/lock no MySQL. O valor padrão de `1` funciona para workloads gerais, mas aumentá-lo pode reduzir a contenção de threads durante a alta simultaneidade.
Quando sua workload mostra um número crescente de threads de espera:
+ Monitore o número de threads de espera em sua workload.
+ Defina `innodb_sync_array_size` igual ou superior à contagem de vCPUs da sua instância para dividir a estrutura de coordenação de threads e reduzir a contenção.
**nota**
Para determinar o número de vCPUs disponíveis em sua instância do RDS, consulte as especificações da vCPU em [Tipos de instância do Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Implementar um pool de conexões
O MySQL atribui um espaço para tabela dedicado a cada sessão que cria uma tabela temporária. Esse espaço para tabela permanece ativo até que a conexão com o banco de dados termine. Para gerenciar seus recursos com maior eficiência:
+ Implemente o agrupamento de conexões para limitar o número de espaços para tabelas temporários ativos.
+ Reutilize as conexões existentes em vez de criar outras para cada operação.