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 Amazon RDS, 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 informações sobre todos os eventos de espera do MariaDB e do MySQL, consulte Tabelas de resumo de eventos de espera
na documentação do MySQL. -
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. -
Para obter mais informações sobre todos os eventos de espera do Oracle, consulte Descriptions of Wait Events
(Descrições de ventos de espera) na documentação do Oracle. -
Para obter informações sobre todos os eventos de espera do SQL Server, consulte Tipos de esperas
na documentação do SQL Server.
nota
No Oracle, às vezes, os processos em segundo plano funcionam sem uma instrução SQL associada. Nesses casos, o Performance Insights relata o tipo de processo em segundo plano concatenado com dois-pontos e a classe de espera associada a esse processo em segundo plano. Os tipos de processos em segundo plano incluem LGWR, ARC0, PMON e assim por diante.
Por exemplo, quando o arquivador está realizando E/S, o relatório do Performance Insights é semelhante a ARC1:System I/O. Às vezes, o tipo de processo em segundo plano também está ausente, e o Performance Insights só informa a classe de espera, por exemplo, :System
I/O.
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.
Planos
Um plano de execução, também chamado simplesmente de plano, é uma sequência de etapas que acessam dados. Por exemplo, um plano para unir tabelas t1 e t2 pode percorrer todas as linhas em t1 e comparar cada linha com uma linha em t2. Em um banco de dados relacional, um otimizador é um código interno que determina o plano mais eficiente para uma consulta SQL.
Em relação a instâncias de banco de dados, o Insights de Performance coleta planos de execução automaticamente. Para diagnosticar problemas de performance do SQL, examine os planos capturados para consultas de SQL com uso elevado de recursos. Os planos mostram como o banco de dados analisou e executou consultas.
Para saber como analisar a carga de banco de dados, consulte:
Captura de planos
A cada cinco minutos, o Insights de Performance identifica as consultas com uso mais intenso de recursos e captura os planos. Assim, você não precisa coletar e gerenciar manualmente um grande número de planos. Em vez disso, você pode usar o SQL principal para focar nos planos para as consultas mais problemáticas.
nota
O Performance Insights não captura planos para consultas cujo texto exceda o limite máximo de texto de consulta coletável. Para ter mais informações, consulte Acessar mais texto SQL no painel do Performance Insights..
O período de retenção para planos de execução é o mesmo dos seus dados do Performance Insights. A configuração de retenção no nível gratuito é Default (7 days) (Padrão (7 dias)). Para reter seus dados de performance por mais tempo, especifique entre 1 e 24 meses. Para obter mais informações sobre os períodos de retenção, consulte Preços e retenção de dados para o Performance Insights.
Consultas de resumo
O SQL principal mostra as consultas de resumo por padrão. Uma consulta de resumo não tem um plano, mas todas as consultas que usam valores literais têm planos. Por exemplo, uma consulta de resumo pode incluir o texto WHERE `email`=?. O resumo pode conter duas consultas, uma com o texto WHERE email=user1@example.com e outro com WHERE
email=user2@example.com. Cada uma dessas consultas literais pode incluir vários planos.
Ao selecionar uma consulta de resumo, o console mostra todos os planos para declarações secundárias do resumo selecionado. Assim, você não precisa examinar todas as instruções filho para encontrar o plano. Você pode ver planos que não estão na lista exibida das 10 principais instruções filho. O console mostra planos para todas as consultas filho para as quais os planos foram coletados, independentemente de as consultas estarem entre as dez principais.
