As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Conceitos-chave para ajuste do desempenho do banco de dados
DevOpsO Guru for RDS presume que você esteja familiarizado com alguns conceitos-chave de desempenho. Para saber mais sobre esses conceitos, consulte Visão geral do Performance Insights no Guia do usuário do Amazon Aurora ou Visão geral do Performance Insights no Guia do usuário do Amazon RDS.
Indicadores
Um indicador representa um conjunto de pontos de dados ordenados por tempo. Considere um indicador como variável a ser monitorado, e os pontos de dados representando os valores dessa variável ao longo do tempo. O Amazon RDS dispõe de indicadores em tempo real para o banco de dados e o sistema operacional (SO) no qual sua instância de banco de dados é executada. Você pode visualizar todos os indicadores e informações de processo do sistema das suas instâncias de banco de dados do Amazon RDS no console do Amazon RDS. DevOpsO Guru for RDS monitora e fornece informações sobre algumas dessas métricas. Para obter mais informações, consulte Como monitorar indicadores em um cluster do Amazon Aurora ou Como monitorar indicadores em uma instância do Amazon Relational Database Service.
Detecção de problemas
DevOpsO Guru for RDS emprega métricas de banco de dados e sistema operacional (SO) para detectar problemas críticos de desempenho do banco de dados, sejam eles iminentes ou contínuos. Há duas formas principais pelas quais o DevOps Guru for RDS funciona para a detecção de problemas:
Usando limites
Usando anomalias
Detectando problemas com limites
Os limites são os valores vinculantes em relação aos quais as métricas monitoradas são avaliadas. Você pode pensar em um limite como uma linha horizontal em um gráfico de indicador que separa o comportamento normal do comportamento potencialmente problemático. DevOpsO Guru for RDS monitora métricas específicas e cria limites analisando quais níveis são considerados potencialmente problemáticos para um recurso específico. DevOpsO Guru for RDS então cria insights no console do DevOps Guru quando novos valores métricos ultrapassam um limite especificado em um determinado período de tempo de forma consistente. Os insights contêm recomendações para evitar um impacto futuro no desempenho do banco de dados.
Por exemplo, o DevOps Guru for RDS pode monitorar o número de tabelas temporárias usando disco por um período de 15 minutos e criar uma visão quando a taxa de tabelas temporárias usando disco por segundo é anormalmente alta. Níveis maiores de uso de tabelas temporárias em disco podem afetar o desempenho do banco de dados. Ao expor essa situação antes que ela se torne crítica, o DevOps Guru for RDS ajuda você a tomar ações corretivas para evitar problemas.
Detectar problemas com anomalias
Embora os limites forneçam uma maneira simples e eficaz de detectar problemas no banco de dados, em algumas situações eles não são suficientes. Considere um caso em que os valores indicadores estão aumentando e se transformando em comportamentos potencialmente problemáticos regularmente devido a um processo conhecido, como um trabalho diário de gerar relatórios. Como esses picos são esperados, criar insights e notificações para cada um deles seria contraproducente e provavelmente levaria à fadiga por excesso de alertas.
No entanto, ainda é necessário detectar picos altamente incomuns, pois indicadores muito mais altas que as demais ou que duram muito mais podem representar problemas reais de desempenho do banco de dados. Para resolver essa preocupação, o DevOps Guru for RDS monitora determinadas métricas para detectar quando o comportamento de uma métrica se torna altamente incomum ou anômalo. DevOpsO Guru então relata essas anomalias em insights.
Por exemplo, o DevOps Guru for RDS pode criar uma visão quando a carga do banco de dados não é apenas alta, mas também se desvia significativamente de seu comportamento normal, o que indica uma grande desaceleração inesperada das operações do banco de dados. Ao reconhecer apenas os picos anômalos de carga do banco de dados, o DevOps Guru for RDS permite que você se concentre nas questões que são realmente importantes.
Carga de banco de dados
O conceito-chave para o ajuste do banco de dados é o indicador de carga do banco de dados (carga do BD). A carga do BD representa o quanto o seu banco de dados está ocupado em um determinado momento. Um aumento na carga do banco de dados significa um aumento na atividade do banco de dados.
Uma sessão de banco de dados relacional representa o diálogo de um aplicativo com um banco de dados relacional. Uma sessão ativa é uma sessão que está executando uma solicitação de banco de dados. 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 seja lida na memória e, em seguida, consumir CPU enquanto faz a leitura dos dados na página.
A média de sessões ativas (AAS) é o indicador DBLoad no Performance Insights. Para calcular a AAS, o Performance Insights faz uma amostra do número de sessões ativas a cada segundo. Para um período de tempo específico, a AAS é o número total de sessões, dividido pelo número total de amostra. Um valor AAS igual a 2 significa que, em média, duas sessões estavam ativas em solicitações em um determinado momento.
Uma analogia à carga de banco de dados é a atividade em um armazém. Suponha que o armazém empregue 100 trabalhadores. Se um pedido chegar, um trabalhador atenderá a esse pedido, enquanto os demais permanecerão ociosos. Se 100 ou mais pedidos chegarem, todos os 100 trabalhadores atenderão aos pedidos simultaneamente. Se você obtiver amostras periodicamente de quantos trabalhadores estão ativos durante um determinado período, poderá calcular o número médio de trabalhadores ativos. O cálculo mostra que, em média, N trabalhadores estão ocupados atendendo a pedidos em um determinado momento. Se a média era de 50 trabalhadores ontem e hoje é de 75 trabalhadores, significa que nível de atividades no armazém aumentou. Da mesma maneira, a carga do banco de dados aumenta à medida que a atividade da sessão aumenta.
Para saber mais, consulte Carga do banco de dados no Guia do usuário do Amazon Aurora ou Carga do banco de dados no Guia do usuário do Amazon RDS.
Eventos de espera
Um evento de espera é um tipo de instrumentação de banco de dados que informa qual recurso uma sessão de banco de dados está aguardando para continuar. Quando o Performance Insights conta as sessões ativas para calcular a carga do banco de dados, ele também registra os eventos de espera que estão fazendo com que as sessões ativas esperem. Essa técnica permite que o Performance Insights mostre quais eventos de espera estão contribuindo para a carga do banco de dados.
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 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 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 solucionar o problema.
Considere a analogia de um trabalhador de armazém. Chega um pedido de um livro. O trabalhador pode estar atrasado no processamento desse pedido. Por exemplo, outro trabalhador pode estar reabastecendo as prateleiras, ou talvez um carrinho não esteja disponível. Ou talvez o sistema utilizado para informar o status do pedido esteja lento. Quanto mais tempo o trabalhador aguardar, mais tempo ele demorará para atender ao pedido. Esperar é uma parte natural do fluxo de trabalho do armazém, mas, se o tempo de espera se tornar excessivo, a produtividade diminuirá. Da mesma maneira, esperas de sessão repetidas ou longas podem prejudicar o desempenho do banco de dados.
Para obter mais informações sobre eventos de espera no Amazon Aurora, consulte Ajustar eventos de espera para o Aurora PostgreSQL e Ajustar eventos de espera para o Aurora MySQL, no Guia do usuário do Amazon Aurora.
Para obter mais informações sobre eventos de espera em outros bancos de dados do Amazon RDS, consulte Tuning with wait events for RDS for PostgreSQL no Guia do usuário do Amazon RDS.
