# 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\_kill](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).