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

CPU

Ocorre quando um thread está ativo na CPU ou está aguardando a CPU.

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.

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:

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.

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 Usar o Amazon RDS Proxy para o Aurora.

    • 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 mais informações, consulte 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/.

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.