# CPU Ocorre quando um thread está ativo na CPU ou está aguardando a CPU. **Topics** + [Versões compatíveis do mecanismo](#apg-waits.cpu.context.supported) + [Contexto](#apg-waits.cpu.context) + [Possíveis causas do maior número de esperas](#apg-waits.cpu.causes) + [Ações](#apg-waits.cpu.actions) ## Versões compatíveis do mecanismo As informações sobre eventos de espera são relevantes para o Aurora PostgreSQL versão 9.6 e versões superiores. ## Contexto A *unidade de processamento central (CPU)* é o componente de um computador que executa instruções. Por exemplo, instruções de CPU realizam operações aritméticas e trocam dados na memória. Se uma consulta aumentar o número de instruções que ela executa por meio do mecanismo de banco de dados, o tempo gasto na execução dessa consulta aumentará. *Programação da CPU* refere-se a alocar tempo de CPU a um processo. A programação é orquestrada pelo kernel do sistema operacional. **Topics** + [Como saber quando essa espera ocorre](#apg-waits.cpu.when-it-occurs) + [Métrica DBLoadCPU](#apg-waits.cpu.context.dbloadcpu) + [Métricas os.cpuUtilization](#apg-waits.cpu.context.osmetrics) + [Provável causa da programação da CPU](#apg-waits.cpu.context.scheduling) ### Como saber quando essa espera ocorre Esse evento de espera `CPU` indica que um processo de backend está ativo na CPU ou aguardando a CPU. É possível determinar que isso está ocorrendo quando uma consulta mostra as seguintes informações: + A coluna `pg_stat_activity.state` tem o valor `active`. + As colunas `wait_event_type` e `wait_event` em `pg_stat_activity` são ambas `null`. Para ver os processos de backend que estão utilizando ou aguardando CPU, execute a seguinte consulta. ``` SELECT * FROM pg_stat_activity WHERE state = 'active' AND wait_event_type IS NULL AND wait_event IS NULL; ``` ### Métrica DBLoadCPU A métrica do Performance Insights para CPU é `DBLoadCPU`. O valor de `DBLoadCPU` pode diferir do valor da métrica `CPUUtilization` do Amazon CloudWatch. A última métrica é coletada do HyperVisor para uma instância de banco de dados. ### Métricas os.cpuUtilization 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`. ### Provável causa da programação da CPU Do ponto de vista do sistema operacional, a CPU está ativa quando não executa o thread ocioso. A CPU está ativa enquanto faz um cálculo, mas também está ativa quando aguarda E/S de memória. Esse tipo de E/S domina uma workload típica de banco de dados. É provável que os processos aguardem para serem programados em uma CPU quando as seguintes condições forem atendidas: + A métrica `CPUUtilization` do CloudWatch está próxima dos 100%. + A carga média é maior que o número de vCPUs, indicando uma carga pesada. Você pode encontrar a métrica `loadAverageMinute` na seção de métricas do sistema operacional do Performance Insights. ## Possíveis causas do maior número de esperas Quando o evento de espera de CPU ocorre mais que o normal, possivelmente indicando um problema de performance, as causas típicas incluem: **Topics** + [Possíveis causas de picos súbitos](#apg-waits.cpu.causes.spikes) + [Possíveis causas de alta frequência a longo prazo](#apg-waits.cpu.causes.long-term) + [Casos excepcionais](#apg-waits.cpu.causes.corner-cases) ### Possíveis causas de picos súbitos As causas mais prováveis de picos súbitos são as seguintes: + Sua aplicação abriu muitas conexões simultâneas com o banco de dados. Esse cenário é conhecido como “tempestade de conexões”. + A workload da sua aplicação foi alterada de qualquer uma das seguintes maneiras: + Novas consultas + Um aumento no tamanho do conjunto de dados + Manutenção ou criação de índices + Novas funções + Novos operadores + Um aumento na execução de consultas paralelas + Seus planos de execução de consultas foram modificados. Em certos casos, uma alteração pode causar um aumento nos buffers. Por exemplo, a consulta agora está utilizando uma varredura sequencial quando utilizava anteriormente um índice. Nesse caso, ela precisa de mais CPU para atingir o mesmo objetivo. ### Possíveis causas de alta frequência a longo prazo As causas mais prováveis de eventos que se repetem por um longo período são: + Muitos processos de backend estão em execução simultaneamente na CPU. Esses processos podem ser operadores paralelos. + Consultas estão sendo executadas com performance abaixo do ideal porque precisam de um grande número de buffers. ### Casos excepcionais Se nenhuma das causas prováveis revelarem ser causas reais, as seguintes situações podem estar ocorrendo: + A CPU está alternando processos para dentro e para fora. + A alternância de contexto da CPU aumentou. + O código do Aurora PostgreSQL não inclui eventos de espera. ## 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. **Topics** + [Investigar se o banco de dados está causando o aumento da CPU](#apg-waits.cpu.actions.db-CPU) + [Determinar se o número de conexões aumentou](#apg-waits.cpu.actions.connections) + [Responder a alterações de workload](#apg-waits.cpu.actions.workload) ### Investigar se o banco de dados está causando o aumento da CPU Examine a métrica `os.cpuUtilization.nice.avg` no Performance Insights. Se esse valor for muito menor que o uso da CPU, processos que não são do banco de dados são os principais colaboradores para a CPU. ### Determinar se o número de conexões aumentou Examine a métrica `DatabaseConnections` no Amazon CloudWatch. Sua ação depende se o número aumentou ou diminuiu durante o período de maior número de eventos de espera de CPU. #### As conexões aumentaram Se o número de conexões aumentou, compare o número de processos de backend que consumem CPU com o número de vCPUs. Os cenários a seguir são possíveis: + O número de processos de backend que consomem CPU é menor que o número de vCPUs. Nesse caso, o número de conexões não é um problema. Porém, você ainda pode tentar reduzir a utilização da CPU. + O número de processos de backend que consomem CPU é maior que o número de vCPUs. Nesse caso, considere as opções a seguir: + Diminua o número de processos de backend conectados ao banco de dados. Por exemplo, implemente uma solução de agrupamento de conexões, como o RDS Proxy. Para saber mais, consulte [Amazon RDS Proxypara Aurora](rds-proxy.md). + Atualize o tamanho da sua instância para obter um número maior de vCPUs. + Se aplicável, redirecione algumas workloads somente leitura para nós de leitor. #### As conexões não aumentaram Examine as métricas `blks_hit` no Performance Insights. Procure uma correlação entre um aumento em `blks_hit` e o uso da CPU. Os cenários a seguir são possíveis: + O uso da CPU e `blks_hit` estão correlacionados. Nesse caso, encontre as principais instruções SQL vinculadas ao uso da CPU e procure modificações no plano. Você pode usar uma das seguintes técnicas: + Explicar os planos manualmente e compare-os com o plano de execução esperado. + Procurar um aumento nos acertos de bloco por segundo e nos acertos de blocos locais por segundo. Na seção **Top SQL** (SQL principal) do painel do Performance Insights, escolha **Preferences** (Preferências). + O uso da CPU e `blks_hit` não estão correlacionados. Nesse caso, determine se alguma das seguintes situações ocorre: + A aplicação está se conectando e se desconectando rapidamente ao/do banco de dados. Diagnostique esse comportamento ativando `log_connections` e `log_disconnections` e analisando os logs do PostgreSQL. Considere utilizar o analisador de logs `pgbadger`. Para obter mais informações, consulte [https://github.com/darold/pgbadger](https://github.com/darold/pgbadger). + O sistema operacional está sobrecarregado. Nesse caso, o Performance Insights mostra que processos de backend estão consumindo CPU por mais tempo que o normal. Procure evidências nas métricas `os.cpuUtilization` do Performance Insights ou na métrica `CPUUtilization` do CloudWatch. Se o sistema operacional estiver sobrecarregado, consulte as métricas de monitoramento avançado para aprofundar o diagnóstico. Especificamente, observe a lista de processos e a porcentagem de CPU consumida por cada um. + As principais instruções SQL estão consumindo muita CPU. Examine instruções que estão vinculadas ao uso da CPU para verificar se elas podem utilizar menos CPU. Execute um comando `EXPLAIN` e concentre-se nos nós do plano que têm o maior impacto. Considere utilizar um visualizador de plano de execução do PostgreSQL. Para experimentar essa ferramenta, consulte [http://explain.dalibo.com/](http://explain.dalibo.com/). ### Responder a alterações de workload Se a sua workload mudou, procure os seguintes tipos de alterações: Novas consultas Verifique se novas consultas são esperadas. Em caso positivo, verifique se os planos de execução dessas consultas e o número de execuções por segundo são os esperados. Um aumento no tamanho do conjunto de dados Determine se o particionamento, caso ainda não esteja implementado, pode ajudar. Essa estratégia é capaz de reduzir o número de páginas que uma consulta precisa recuperar. Manutenção ou criação de índices Verifique se a programação de manutenção é a esperada. Uma prática recomendada é agendar atividades de manutenção fora das atividades de pico. Novas funções Confirme se essas funções são executadas conforme o esperado durante o teste. Especificamente, confira se o número de execuções por segundo é o esperado. Novos operadores Verifique se eles funcionam conforme o esperado durante os testes. Um aumento na execução de consultas paralelas Determine se alguma das situações a seguir ocorreu: + As relações ou os índices envolvidos cresceram de repente a ponto de diferirem significativamente de `min_parallel_table_scan_size` ou `min_parallel_index_scan_size`. + Alterações recentes foram feitas em `parallel_setup_cost` ou `parallel_tuple_cost`. + Alterações recentes foram feitas em `max_parallel_workers` ou `max_parallel_workers_per_gather`.