A captura de desempenho do Cloud SQL para MySQL ajuda a diagnosticar e resolver problemas de desempenho complexos e temporários no banco de dados MySQL causados pela demanda do sistema em evolução. À medida que as cargas de trabalho do aplicativo são escalonadas e a infraestrutura ao redor se torna mais complexa, os bancos de dados são submetidos a demandas cada vez maiores e imprevisíveis. Essas pressões externas do sistema podem causar lentidão ou paralisação do banco de dados.
Quando o banco de dados apresenta degradação de desempenho, as métricas padrão podem ser insuficientes para identificar a causa raiz no contexto da sua infraestrutura maior. A captura de desempenho resolve esse problema capturando snapshots detalhados e pontuais do banco de dados no momento em que um problema é detectado. É possível usar acionadores configuráveis para fazer snapshots em todo o sistema quando ocorrem problemas temporários. Os acionadores também podem detectar transações de longa duração, que podem ser as causas raiz de problemas de desempenho. É possível configurar acionadores para encerrar transações de longa duração automaticamente.
Exemplos de casos de uso
Esta seção lista exemplos de casos de uso de como usar a captura de desempenho depois de ativá-la para sua instância.
| Caso de uso | Condição do gatilho | Insight de diagnóstico |
|---|---|---|
| Lentidão em todo o sistema devido ao acúmulo de registros de desfazer | Comprimento da lista do histórico | Identifica quando o processo de limpeza do InnoDB está atrasado devido a leituras de longa duração ou grandes operações de linguagem de manipulação de dados (DML). O atraso pode levar ao aumento da pressão de armazenamento e à degradação do desempenho. |
| Paralisação do banco de dados causada por contenção interna do mecanismo | Espera de semáforos | Útil para diagnosticar um banco de dados que não responde. Esse acionador pode detectar contenção de mutex ou de bloqueio de leitura/gravação no mecanismo de armazenamento do InnoDB, como o índice de hash adaptável (AHI) ou a contenção do pool de buffers. |
| Contenção de bloqueio no nível do aplicativo ou consultas não indexadas | Espera de bloqueio de transação | Aciona quando um grande número de transações está em um estado LOCK WAIT, apontando para contenção no nível da linha ou transações inativas de longa duração. |
| Sobrecarga de instância devido a classificação ou agregação complexa | Alta utilização da CPU | Captura o estado durante o uso alto da CPU do contêiner, geralmente causado por consultas ineficientes ou picos de simultaneidade massivos. |
| Risco de reinicializações por falta de memória (OOM) | Uso alto de memória | Ajuda a diagnosticar problemas como buffers por linha de execução muito grandes ou vazamentos de memória antes que eles levem a uma falha de instância. |
| Picos repentinos de tráfego ou apps de cliente com gargalo | Linhas de execução em andamento | Um indicador geral de carga da instância, útil para identificar aumentos repentinos em conexões ativas simultâneas. |
| Dados desatualizados na réplica devido a cargas de trabalho de gravação pesadas | Segundos atrás da origem | Monitora o atraso de replicação em réplicas de leitura para ajudar a diagnosticar atrasos na sincronização de dados da instância principal. |
| Consultas de longa duração que bloqueiam a limpeza | Transações de longa duração | Identifica transações que estão abertas há muito tempo e que podem estar mantendo bloqueios críticos. Além disso, é possível encerrar transações de longa duração automaticamente. |
Como os dados de performance são capturados
A captura de desempenho funciona como um serviço baseado em agente que monitora sua instância. Quando você ativa a captura de desempenho, a instância do Cloud SQL faz o seguinte para capturar dados de desempenho:
O agente sonda a configuração da instância para ler os acionadores baseados em limite que você definiu. Em seguida, o agente sonda as métricas da instância em um intervalo configurável,
probingIntervalSeconds, que é definido como 30 segundos por padrão.Se um problema for detectado e o limite de um acionador tiver sido excedido, o agente continuará comparando o estado ativo da instância com suas regras. Para evitar alarmes falsos de picos temporários, o agente aciona uma captura de desempenho completa. Uma captura é acionada somente se a condição for atendida durante sondagens consecutivas para o
probeThresholdconfigurado, que é3por padrão. Esse limite consecutivo impede capturas devido a picos temporários.Por exemplo, o agente poderá acionar uma captura de desempenho se detectar que o número de linhas de execução é alto para três sondagens consecutivas.
Se várias condições de acionamento forem configuradas, o Cloud SQL iniciará uma captura se qualquer uma das condições for atendida.
Quando uma captura é acionada, a captura de desempenho se conecta ao banco de dados e executa uma série de comandos de diagnóstico para capturar um snapshot detalhado.
As informações capturadas são formatadas em entradas de registro e enviadas diretamente para o Cloud Logging do projeto da instância do Cloud SQL em um fluxo de registro específico chamado
mysql-performance-capture.log.
Períodos de espera e de retirada adaptativa
Para evitar a geração excessiva de registros e o overhead do sistema, a captura de desempenho implementa um período de espera após uma captura.
Resfriamento padrão
Após uma captura bem-sucedida, a captura de desempenho inicia um período de espera padrão de 30 minutos. Durante esse período, o agente não aciona novas capturas, mesmo que a instância esteja em um estado de problema estendido.
Resfriamento e retirada adaptativos
Se uma instância acionar repetidamente capturas para a mesma violação, a captura de desempenho usará um mecanismo de retirada de resfriamento adaptativo. Esse mecanismo ajuda a limitar o volume de registros e o custo de limites mal configurados.
Nesse mecanismo:
- O resfriamento se estende a 24 horas.
- A captura de desempenho entra em um modo de suspensão, que suspende todas as verificações de acionamento e capturas de diagnóstico.
- A instância é limitada a uma única captura de desempenho por dia.
Acionadores de captura de desempenho
Esta seção lista os acionadores disponíveis para captura de desempenho do MySQL. Todos os acionadores listados na tabela, exceto quando indicado, usam os valores de configuração de sondagem probingIntervalSeconds e probeThreshold para validar condições de acionamento sustentadas.
| Nome da condição do acionador | Nome da API | Descrição | Valor padrão | Intervalo de configuração |
|---|---|---|---|---|
| Alta utilização da CPU |
cpuUtilizationThresholdPercent
|
Aciona uma captura quando a utilização geral da CPU da instância do banco de dados excede consistentemente essa porcentagem. Isso ajuda a detectar a sobrecarga da instância, geralmente causada por consultas ineficientes com classificação e agregação massivas, indexação insuficiente ou simultaneidade muito alta. Para evitar capturas em picos menores, configure o padrão para estar no intervalo de porcentagem mais alto da instância. | 0 (desativado)
|
0 ou 10-99 (%)
|
| Uso alto de memória |
memoryUsageThresholdPercent
|
Aciona uma captura quando o uso da memória do contêiner do banco de dados excede consistentemente essa porcentagem da memória alocada da instância. Esse acionador pode ajudar a diagnosticar possíveis problemas de falta de memória, vazamentos de memória ou configuração de memória ineficiente. Para evitar a captura de picos menores, defina o padrão na extremidade superior do intervalo da instância. | 0 (desativado)
|
0 ou 10-99 (%)
|
| Uso alto de arquivos temporários |
Não configurável. Esse acionador é ativado automaticamente para o MySQL 8.0 e versões mais recentes. | Aciona automaticamente uma captura quando há um aumento significativo no uso do disco dos arquivos temporários criados pelo processo do MySQL.
Muitas vezes, os arquivos temporários são excluídos, mas ainda são mantidos abertos por um processo do MySQL. O limite para esse acionador usa um modelo de escalonamento progressivo para limites de diferença. Ele começa em 100 GB e dobra sequencialmente para 200 GB, 400 GB, até 1,6 TB após cada período de espera. Ao usar um modelo de escalonamento progressivo, a captura de desempenho ocorre somente se a diferença no uso de arquivos temporários aumentar em um nível alto. |
Ativado | n/a |
| Comprimento da lista do histórico |
historyListLengthThresholdCount
|
Aciona uma captura quando o comprimento da lista do histórico (HLL) do InnoDB cresce além do valor configurado. Um HLL persistentemente alto indica que o processo de limpeza do InnoDB não consegue acompanhar e que a contagem de transações não limpas está aumentando, geralmente devido a transações de longa duração. Esse número alto pode levar ao aumento do consumo de armazenamento e problemas de desempenho. Esse limite depende da carga de trabalho. Algumas instâncias podem operar suficientemente mesmo com HLL consistentemente alto. No entanto, ainda é possível usar esse acionador para destacar possíveis problemas, como leituras de longa duração, grandes instruções de linguagem de manipulação de dados (DML) ou gargalos de linhas de execução de limpeza. |
0 (desativado)
|
0 ou 10000-10000000
|
| Transações de longa duração |
transactionDurationThreshold
|
Uma transação será registrada se ela for executada por mais tempo do que a duração configurada em segundos. Esse acionador é útil para identificar operações que podem estar mantendo bloqueios por períodos excessivos ou consumindo recursos por muito tempo. As transações que excedem transactionDurationThreshold são avaliadas após cada intervalo especificado na configuração probingIntervalSeconds (padrão de 30 segundos). No entanto, para gerenciar o volume de registros, os detalhes de até 10 dessas transações de longa duração são enviados ao Cloud Logging no máximo uma vez a cada período de espera (30 minutos).
O texto completo da consulta de até 1.024 bytes de INFORMATION_SCHEMA.INNODB_TRX está incluído em cada entrada de registro para as 10 principais transações. |
3600 (segundos)
|
60 ou mais
|
| Erro de linha de execução SQL/IO da réplica |
Não configurável. Esse acionador é ativado automaticamente por padrão em todas as instâncias de réplica e não pode ser desativado. | Aciona uma captura imediatamente se a linha de execução SQL ou a linha de execução de E/S de replicação em uma instância de réplica encontrar algum erro e parar. Esse acionador é fundamental para manter a integridade da réplica e identificar falhas de replicação. Esse acionador não usa nenhuma configuração de sondagem, como probingIntervalseconds ou probeThreshold, para validar as condições de captura de desempenho. |
Ativado | n/a |
| Linhas de execução em andamento | runningThreadsThreshold
|
Aciona uma captura quando o número de linhas de execução ativas com base na variável de status threads_running excede o valor especificado. Por exemplo, é possível configurar o limite para executar a captura de desempenho se o número de linhas de execução ativas for maior que 100.Esse acionador é necessário para a captura de desempenho. Se você não configurar esse acionador explicitamente, o padrão será calculado com base no número de vCPUs que pertencem à instância. |
MIN(600,
cpuCount * 20)
|
10 ou mais
|
| Segundos atrás da origem |
secondsBehindSourceThreshold
|
Aciona uma captura quando o atraso de replicação na instância de réplica de leitura, medido em segundos, excede o valor especificado. É possível usar esse acionador para monitorar e diagnosticar atrasos na replicação. Esse acionador é ativado automaticamente para instâncias de réplica. Se você não configurar o acionador explicitamente, o padrão será de 900 segundos. Recomendamos que você configure o valor na extremidade superior para evitar capturas excessivas e resfriamentos frequentes. | 900 (segundos)
|
1 ou mais
|
| Espera de semáforos | semaphoreWaitThresholdCount
|
Aciona uma captura quando o número de linhas de execução que aguardam semáforos internos do InnoDB excede o valor configurado desse acionador. Essa métrica avançada indica contenção, usando um mutex ou um bloqueio de leitura/gravação, no próprio mecanismo de armazenamento do InnoDB.
As contenções comuns observadas são a contenção do índice de hash adaptável (AHI), a contenção do pool de buffers e a contenção de E/S de disco. Uma captura também será acionada se o tempo máximo de espera de um único semáforo exceder 200 segundos, independentemente do valor configurado desse acionador. |
0 (desativado)
|
0 ou 10-10000
|
| Espera de bloqueio de transação |
transactionLockWaitThresholdCount
|
Aciona uma captura quando o número de transações em um estado LOCK WAIT ultrapassa a contagem configurada. Um pequeno número de transações no estado de espera de bloqueio pode ser normal em um sistema ocupado, mas um número consistentemente alto de esperas de bloqueio é um forte indicador de contenção de bloqueio no nível do aplicativo, DMLs não indexadas, transações inativas longas e contenções de linhas de alta simultaneidade que podem degradar severamente o desempenho e a capacidade de processamento. |
0 (desativado)
|
0 ou 10-10000
|
Preços
A captura de desempenho está disponível em todas as regiões do Cloud SQL sem custos adicionais. As cobranças padrão se aplicam apenas aos recursos de banco de dados subjacentes. A captura de desempenho armazena registros no Cloud Logging, o que pode gerar custos adicionais de armazenamento do Cloud Logging.
Para mais informações sobre os preços do armazenamento de registros no Logging, consulte Preços.
Limitações
- É necessário ativar os insights de consulta para usar a captura de desempenho. Se você desativar os insights de consulta, a captura de desempenho também será desativada.
- A captura de desempenho está disponível apenas para o Cloud SQL para MySQL 5.7 e versões mais recentes.