Carga de banco de dados
Carga do banco do dados mede o nível de atividade de sessão no banco de dados. DBLoad é a métrica principal no Insights de Performance, e o Insights de Performance coleta a carga do banco de dados a cada segundo.
Sessões ativas
Uma sessão de base de dados relacional representa o diálogo de uma aplicação com um banco de dados relacional. Uma sessão ativa é uma conexão que enviou trabalho para o mecanismo de banco de dados e está aguardando uma resposta.
Uma sessão fica ativa quando está em execução na CPU ou aguardando a disponibilidade de um recurso para que ela possa continuar. Por exemplo, uma sessão ativa pode esperar que uma página (ou um bloco) seja lida na memória e, depois, consumir CPU enquanto faz a leitura dos dados na página.
Média de sessões ativas
A média de sessões ativas (AAS) é a unidade da métrica DBLoad no Performance Insights. Ele mede quantas sessões estão ativas simultaneamente no banco de dados.
A cada segundo, o Insights de Performance faz uma amostra do número de sessões executando simultaneamente uma consulta. Para cada sessão ativa, o Insights de Performance coleta os seguintes dados:
-
Declaração do SQL
-
Estado da sessão (em execução na CPU ou em espera)
-
Host
-
Usuário executando o SQL
O Insights de Performance calcula a AAS dividindo o número total de sessões pelo número total de amostras por um período específico. Por exemplo, a tabela a seguir mostra cinco amostras consecutivas de uma consulta em execução em intervalos de um segundo.
| Amostra | Número de sessões que executam a consulta | AAS | Cálculo |
|---|---|---|---|
| 1 | 2 | 2 | 2 sessões no total/1 amostra |
| 2 | 0 | 1 | 2 sessões no total/2 amostras |
| 3 | 4 | 2 | 6 sessões no total/3 amostras |
| 4 | 0 | 1.5 | 6 sessões no total/4 amostras |
| 5 | 4 | 2 | 10 sessões no total/5 amostras |
No exemplo anterior, a carga do banco de dados para o intervalo de tempo foi de 2 AAS. Essa medida significa que, em média, duas sessões estavam ativas em determinado momento durante o intervalo em que as cinco amostras foram obtidas.
Média de execuções ativas
A média de execuções ativas (AAE) por segundo está relacionada ao AAS. Para calcular os AAE, o Performance Insights divide o tempo total de execução de uma consulta pelo intervalo de tempo. A tabela a seguir mostra o cálculo de AAE para a mesma consulta na tabela anterior.
| Tempo decorrido (s) | Tempo de execução total (s) | AAE | Cálculo |
|---|---|---|---|
| 60 | 120 | 2 | 120 segundos de execução/60 segundos decorridos |
| 120 | 120 | 1 | 120 segundos de execução/120 segundos decorridos |
| 180 | 380 | 2.11 | 380 segundos de execução/180 segundos decorridos |
| 240 | 380 | 1,58 | 380 segundos de execução/240 segundos decorridos |
| 300 | 600 | 2 | 600 segundos de execução/300 segundos decorridos |
Na maioria dos casos, o AAS e o AAE de uma consulta são aproximadamente os mesmos. No entanto, como as entradas para os cálculos são diferentes fontes de dados, os cálculos geralmente variam ligeiramente.
Dimensões
A métrica db.load é diferente das outras métricas da série temporal, pois você pode fragmentá-la em subcomponentes chamados de dimensões. Você pode pensar em dimensões como “pedaços” de categorias para as diferentes características da métrica DBLoad.
Quando você está diagnosticando problemas de performance, as seguintes dimensões geralmente são as mais úteis:
Para obter uma lista completa de dimensões dos mecanismos Aurora, consulte Carga de banco de dados separada por dimensões.
Eventos de espera
Um evento de espera faz com que uma instrução SQL aguarde que um evento específico aconteça antes que ele possa continuar a execução. Eventos de espera são uma dimensão, ou categoria, importante para a carga do banco de dados, pois indicam onde o trabalho está impedido.
Todas as sessões ativas estão em um estado de espera ou de execução na CPU. Por exemplo, sessões consomem CPU quando procuram um buffer na memória, realizam um cálculo ou executam um código processual. Quando as sessões não estão consumindo CPU, elas podem estar aguardando a liberação de um buffer de memória, a leitura de um arquivo de dados ou a gravação em um log. Quanto mais tempo uma sessão aguardar recursos, menos tempo ela será executada na CPU.
Ao ajustar um banco de dados, muitas vezes você tenta descobrir os recursos que as sessões estão aguardando. Por exemplo, dois ou três eventos de espera podem representar 90% da carga do banco de dados. Essa medida significa que, em média, as sessões ativas estão passando a maior parte do tempo aguardando um pequeno número de recursos. Se você conseguir descobrir a causa dessas esperas, poderá tentar uma solução.
Os eventos de espera variam de acordo com o mecanismo de banco de dados:
-
Para obter uma lista dos eventos de espera comuns do Aurora MySQL, consulte Eventos de espera do Aurora MySQL. Para aprender a ajustar utilizando esses eventos de espera, consulte Ajustar o Aurora MySQL.
-
Para obter informações sobre todos os eventos de espera do MySQL, consulte Tabelas de resumo de eventos de espera
na documentação do MySQL. -
Para obter uma lista de eventos de espera comuns do Aurora PostgreSQL, consulte Eventos de espera do Amazon Aurora PostgreSQL. Para aprender a ajustar utilizando esses eventos de espera, consulte Ajustar com eventos de espera do Aurora PostgreSQL.
-
Para obter informações sobre todos os eventos de espera do PostgreSQL, consulte The Statistics Collector > Wait Event tables
(Coletor de estatísticas > Tabelas de eventos de espera) na documentação do PostgreSQL.
SQL principal
Enquanto eventos de espera mostram gargalos, o gráfico Top SQL (SQL principal) mostra quais consultas estão contribuindo mais para a carga do banco de dados. Por exemplo, muitas consultas podem estar em execução no banco de dados, mas uma única consulta pode consumir 99% da carga do banco de dados. Nesse caso, a carga alta pode indicar um problema com a consulta.
Por padrão, o console do Performance Insights exibe as consultas de SQL principal que estão contribuindo para a carga do banco de dados. O console também mostra estatísticas relevantes para cada instrução. Para diagnosticar problemas de performance para uma instrução específica, você pode examinar seu plano de execução.
