Esta página descreve como usar o painel Query Insights para detectar e analisar problemas de desempenho. Para uma visão geral desse recurso, consulte a Visão geral dos insights de consulta.
Você pode usar a assistência do Gemini em bancos de dados para monitorar e resolver problemas dos seus recursos do AlloyDB. Para mais informações, consulte Monitorar e resolver problemas com a assistência do Gemini.
Antes de começar
Se você ou outros usuários precisarem visualizar o plano de consulta ou executar um rastreamento completo, precisará de permissões específicas do Identity and Access Management (IAM). Crie uma função personalizada e adicione as permissões de IAM necessárias a ela. Depois, adicione esse papel a cada conta de usuário que vai usar insights de consulta para solucionar um problema. Consulte Criar uma função personalizada.
A função personalizada precisa ter a seguinte permissão do IAM: cloudtrace.traces.get
.
Abrir o painel Insights de consulta
Para abrir o painel Insights de consulta, siga estas etapas:
- Na lista de clusters e instâncias, clique em uma instância.
- Clique em Acessar Query Insights para ver informações mais detalhadas sobre consultas e desempenho abaixo do gráfico de métricas na página de visão geral do cluster ou selecione a guia Insights de consulta no painel de navegação à esquerda.
Na página seguinte, use as seguintes opções para filtrar os resultados:
- Seletor de instâncias. Permite selecionar a instância principal ou as instâncias do pool de leitura no cluster. A instância principal é selecionada por padrão. Os detalhes mostrados são agregados para todas as instâncias do pool de leitura conectadas e os nós delas.
- Banco de dados. Filtra a carga de consulta em um banco de dados específico ou em todos os bancos de dados.
- Usuário. Filtra a carga de consulta de contas de usuário específicas.
- Endereço do cliente. Filtra a carga de consulta de um endereço IP específico.
- Intervalo de tempo. Filtra a carga de consulta por intervalos de tempo, como hora, dia, semana ou um intervalo personalizado.
Editar a configuração Query Insights
O Query Insights é ativado por padrão nas instâncias do AlloyDB. É possível editar a configuração padrão dos Query Insights.
Para editar a configuração do Query Insights em uma instância do AlloyDB, siga estas etapas:
Console
No console do Google Cloud, acesse a página Clusters.
Clique em um cluster na coluna Nome do recurso.
Clique em Insights da consulta no painel de navegação à esquerda.
Selecione Principal ou Read pool na lista Insights de consulta e clique em Editar.
Edite os campos Query Insights:
Para mudar o limite padrão de 1.024 bytes nos tamanhos de consulta para análise do AlloyDB, insira um número de 256 a 4.500 no campo Personalizar tamanhos de consulta.
A instância é reiniciada depois que você edita esse campo.
Observação: limites de comprimento de consulta mais altos exigem mais memória.
Para personalizar os conjuntos de recursos dos Query Insights, ajuste as seguintes opções:
- Ativar planos de consulta: marque esta caixa para saber quais operações foram usadas
para executar uma amostra de consulta.
No campo Taxa de amostragem máxima, insira um número de 1 a 20. Por padrão, a taxa de amostragem é definida como 5. Para desativar a amostragem, desmarque a caixa de seleção Ativar planos de consulta.
A taxa de amostragem determina o número máximo de consultas que o AlloyDB pode amostrar por minuto para a instância por nó. - Armazenar endereços IP de clientes. Marque esta caixa para saber de onde as consultas estão vindo e agrupar essas informações para gerar métricas.
- Armazene tags de aplicativos. Marque essa caixa de seleção para saber quais aplicativos com tag estão fazendo solicitações e agrupar essas informações para gerar métricas. Para mais informações sobre tags de aplicativos, consulte a especificação .
- Ativar planos de consulta: marque esta caixa para saber quais operações foram usadas
para executar uma amostra de consulta.
Clique em Atualizar instância.
gcloud
gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS} \
--insights-config-record-application-tags \
--insights-config-record-client-address
Substitua:
- CLUSTER: o ID da instância a ser atualizada
- CLUSTER: o ID do cluster da instância
- PROJECT: o ID do projeto do cluster
- REGION: a região do cluster, por exemplo,
us-central1
- QUERY_LENGTH: o comprimento da consulta varia de 256 a 4.500
- QUERY_PLANS: o número de planos de consulta a serem configurados por minuto
Além disso, use uma ou mais das seguintes flags opcionais:
--insights-config-query-string-length
: define o limite de tamanho da consulta padrão como um valor especificado de 256 a 4.500 bytes. O tamanho de consulta padrão é 1024 bytes. Comprimentos de consulta mais altos são mais úteis para consultas analíticas, mas também exigem mais memória. Se você mudar o tamanho da consulta, reinicie a instância. Ainda é possível adicionar tags às consultas que excedem o limite de tamanho.--insights-config-query-plans-per-minute
: por padrão, no máximo cinco amostras de planos de consulta executadas são capturadas por minuto em todos os bancos de dados da instância. Mude esse valor para um número entre 1 e 20. Para desativar a amostragem, insira 0. É provável que o aumento da taxa de amostragem ofereça mais pontos de dados, mas pode adicionar uma sobrecarga de desempenho.--insights-config-record-client-address
: armazena os endereços IP do cliente de origem das consultas e ajuda a agrupar esses dados para gerar métricas. As consultas vêm de mais de um host. Analisar os gráficos para consultas de endereços IP do cliente pode ajudar a identificar a origem de um problema. Se você não quiser armazenar endereços IP de clientes, use--no-insights-config-record-client-address
.--insights-config-record-application-tags
: armazena tags de aplicativos que ajudam a determinar as APIs e as rotas modelo-visualização-controlador (MVC) que fazem solicitações e agrupam os dados para executar métricas. Essa opção exige que você comente consultas com um conjunto específico de tags. Se você não quiser armazenar tags de aplicativos, use--no-insights-config-record-application-tags
.
Etapas para melhorar o desempenho da consulta
Query Insights resolvem problemas das consultas do AlloyDB em busca de problemas de performance. O painel "Query Insights" mostra o carregamento da consulta com base nos fatores selecionados. A carga de consulta é uma medida do trabalho total de todas as consultas na instância no intervalo de tempo selecionado.
Os insights de consulta ajudam você a detectar e analisar problemas de desempenho da consulta. Use os insights de consulta para solucionar problemas em quatro etapas:
- Visualizar a carga do banco de dados de todas as consultas.
- Identificar uma consulta ou tag potencialmente problemática.
- Analisar a consulta ou tag para identificar problemas.
- Rastrear a origem do problema.
Visualizar a carga do banco de dados de todas as consultas
O painel de Query Insights de nível superior mostra o gráfico Carga do banco de dados: todas as principais consultas usando dados filtrados. A carga de consulta do banco de dados é uma medida do trabalho (em segundos de CPU) que as consultas executadas no banco de dados selecionado realizam ao longo do tempo. Cada consulta em execução está usando ou aguardando recursos de CPU, recursos de E/S ou recursos de bloqueio. A carga de consulta do banco de dados é a proporção entre o tempo gasto por todas as consultas concluídas em uma determinada janela de tempo e o tempo real decorrido.
As linhas coloridas no gráfico mostram a carga da consulta, dividida em quatro categorias:
- Capacidade da CPU: o número de CPUs disponíveis na instância.
CPU e espera de CPU: a proporção entre o tempo gasto pelas consultas em um estado ativo e o tempo real decorrido. As esperas de E/S e de bloqueio não bloqueiam consultas que estão em estado ativo. Essa métrica pode significar que a consulta está usando a CPU ou aguardando o programador do Linux programar o processo do servidor que executa a consulta enquanto outros processos a usam.
Observação: a carga da CPU considera tanto o ambiente de execução quanto o tempo que aguarda o programador do Linux programar o processo do servidor em execução. Como resultado, a carga da CPU pode ir além da linha principal do núcleo.
Espera de E/S: a proporção entre o tempo gasto pelas consultas que estão aguardando E/S e o tempo real decorrido. Inclui a espera de E/S de leitura e de gravação. Consulte a tabela de eventos do PostgreSQL. Se você quiser um detalhamento de informações para espera de IO, poderá vê-las no Cloud Monitoring. Para mais informações, consulte Gráficos de métricas.
Espera de bloqueio: a proporção entre o tempo gasto pelas consultas que estão aguardando bloqueios e o tempo real decorrido. Inclui esperas de Lock, de LwLock e de BufferPin Lock. Se você quiser um detalhamento de informações para espera de Lock, poderá vê-las no Cloud Monitoring. Para mais informações, consulte Gráficos de métricas.
Agora, revise o gráfico e use as opções de filtragem para responder a estas perguntas:
- A consulta está alta? O gráfico está piscando ou aumentando ao longo do tempo? Se você não vê uma carga alta, o problema não está nas consultas.
- Quanto tempo a carga tem sido alta? Está alta no momento? Ou faz muito tempo? Use a seleção de intervalo para selecionar vários períodos e descobrir por quanto tempo o problema tem ocorrido. Ou aumente o zoom para visualizar uma janela de tempo em que os picos de carga da consulta são observados. Você pode diminuir o zoom para ver até uma semana da linha do tempo.
- O que está causando a carga alta? Você pode selecionar opções para analisar a capacidade da CPU, a CPU e a espera da CPU, a espera de bloqueio ou a espera de E/S. O gráfico para cada uma dessas opções é uma cor diferente para que você possa ver qual tem a carga mais alta. A linha azul-escuro no gráfico mostra a capacidade máxima da CPU do sistema. Com ela, é possível comparar a carga de consulta com a capacidade máxima do sistema de CPU. Essa comparação ajuda você a saber se uma instância está ficando sem recursos de CPU.
- Qual banco de dados está passando pela carga? Selecione diferentes bancos de dados no menu suspenso "Bancos de dados" para encontrar os bancos de dados com as cargas mais altas.
- Usuários ou endereços IP específicos estão causando cargas maiores? Selecione usuários e endereços diferentes nos menus suspensos para comparar quais estão causando carregamentos maiores.
Filtrar a carga do banco de dados
Nas seções Consultas e tags, você pode filtrar ou classificar a carga de consulta de uma consulta selecionada ou de uma tag de consulta SQL.
Filtrar por consultas
A tabela QUERIES fornece uma visão geral das consultas que geram a maior parte da carga de consultas. A tabela mostra todas as consultas normalizadas para a janela de tempo e as opções selecionadas no painel de insights da consulta.
Por padrão, a tabela classifica as consultas pelo tempo total de execução na janela de tempo selecionada.
Para filtrar a tabela, selecione uma propriedade em Filtrar consultas. Para classificar a tabela, selecione um cabeçalho de coluna. A tabela mostra as seguintes propriedades:
String de consulta. A string de consulta normalizada. Por padrão, os insights da consulta mostram apenas 1.024 caracteres na string dela.
As consultas rotuladas como
UTILITY COMMAND
geralmente incluem comandosBEGIN
,COMMIT
eEXPLAIN
ou comandos de wrapper.Banco de dados. O banco de dados em que a consulta foi executada.
Carregamento por tempo total/carregamento por CPU/carregamento por espera de pedido de veiculação e de bloqueio. Essas opções permitem filtrar consultas específicas para encontrar a maior carga para cada opção.
Tempo médio de execução (ms). O tempo total que todas as subtarefas levam em todos os workers paralelos para concluir a consulta. Para mais informações, consulte Tempo e duração médios de execução.
Hora da chamada. O número de vezes que a consulta foi chamada pelo aplicativo.
Média de linhas buscadas. O número médio de linhas buscadas para a consulta.
O Query Insights exibe consultas normalizadas, ou seja, $1, $2 e assim por diante substituem os valores constantes literais. Exemplo:
UPDATE
"demo_customer"
SET
"customer_id" = $1::uuid,
"name" = $2,
"address" = $3,
"rating" = $4,
"balance" = $5,
"current_city" = $6,
"current_location" = $7
WHERE
"demo_customer"."id" = $8
O valor da constante é ignorado para que os Query Insights possam agregar consultas semelhantes e remover quaisquer informações de PII que a constante possa mostrar.
Filtrar por tags de consulta
Para solucionar problemas em um aplicativo, você precisa adicionar tags às suas consultas SQL primeiro.
Os insights de consulta fornecem monitoramento centrado no aplicativo para diagnosticar problemas de desempenho de aplicativos criados com o uso de ORMs.
Se você for responsável por toda a pilha do aplicativo, os insights de consulta fornecerão monitoramento de consulta a partir de uma visualização do aplicativo. A inclusão de tag de consulta ajuda a encontrar problemas em construções de alto nível, como usar a lógica de negócios, um microsserviço ou outra construção. Marque as consultas pela lógica de negócios, por exemplo, usando as tags de pagamento, inventário, análise de negócios ou frete. Em seguida, é possível encontrar a carga de consulta criada por vários tipos de lógica de negócios. Por exemplo, você pode encontrar eventos inesperados, como picos para uma tag de análise de dados de negócios às 13h. Ou talvez você veja um crescimento inesperado de um serviço de pagamento em alta na semana anterior.
As tags de carga de consulta fornecem um detalhamento do carregamento da consulta da tag selecionada ao longo do tempo.
Para calcular a carga do banco de dados para a tag, o Insights de consulta usa o tempo gasto por cada consulta que usa a tag selecionada. Os insights de consulta calculam o tempo de conclusão no limite de minutos usando o tempo decorrido.
No painel de insights da consulta, selecione TAGS para ver a tabela de tags. A tabela TAGS classifica as tags pelo carregamento total por tempo total.
É possível classificar a tabela selecionando uma propriedade em Filtrar consultas ou clicando em um cabeçalho de coluna. A tabela mostra as seguintes propriedades:
- Action, Controller, Framework, Route, Application, DB Driver. Cada propriedade adicionada às consultas é mostrada como uma coluna. É preciso adicionar pelo menos uma dessas propriedades para filtrar por tags.
- Carregamento por tempo total/carregamento por CPU/carregamento por espera de pedido de veiculação e de bloqueio. Essas opções permitem filtrar consultas específicas para encontrar a maior carga para cada opção.
- Tempo médio de execução (ms). O tempo total que todas as subtarefas levam em todos os workers paralelos para concluir a consulta. Para mais informações, consulte Tempo e duração médios de execução.
- Hora da chamada. O número de vezes que a consulta foi chamada pelo aplicativo.
- Média de linhas buscadas. O número médio de linhas buscadas para a consulta.
- Banco de dados. O banco de dados em que a consulta foi executada.
Examinar uma consulta ou tag específica
Para saber se uma consulta ou tag é a causa raiz do problema, faça o seguinte nas guias Consultas ou Tags, respectivamente:
- Clique no cabeçalho Carga por tempo total para classificar a lista em ordem decrescente.
- Clique na consulta ou tag que parece ter a carga mais alta e que está demorando mais que as outras.
Um painel é aberto mostrando os detalhes da consulta ou tag selecionada.
Se você selecionou uma consulta, uma visão geral dela será mostrada:
Se você tiver selecionado uma tag, uma visão geral dela vai aparecer.
Examinar a carga de uma consulta ou tag específica
O gráfico Carga do banco de dados, consulta específica mostra uma medida do trabalho (em segundos da CPU) que a consulta normalizada executou na consulta selecionada ao longo do tempo. Para calcular a carga, ele usa o tempo gasto pelas consultas normalizadas que são concluídas no limite de minutos para o tempo convencional. Na parte de cima da tabela, são exibidos os primeiros 1.024 caracteres da consulta normalizada, em que os literais são removidos por motivos de agregação e PII. Como no gráfico de consultas totais, é possível filtrar a carga de uma consulta específica por Banco de dados, Usuário e Endereço do cliente. O carregamento da consulta é dividido em Capacidade da CPU, CPU e espera de CPU, Espera de pedido de veiculação e Espera de bloqueio.
O gráfico Carga do banco de dados - tags específicas mostra uma medida do trabalho (em segundos de CPU) que as consultas com as tags selecionadas realizaram no banco de dados selecionado ao longo do tempo. Como no gráfico de consultas totais, é possível filtrar a carga de uma tag específica por Banco de dados, Usuário e Endereço do cliente.
Examinar a latência
Use o gráfico Latência para examinar a latência na consulta ou tag. Latência é o tempo que uma consulta normalizada leva para ser concluída em tempo real decorrido. O painel de latência mostra a latência dos percentis 50º, 95º e 99º para encontrar comportamentos atípicos.
A latência de consultas paralelas é medida em tempo real decorrido, mesmo que a carga de consultas seja maior no caso de uma consulta devido ao uso de vários núcleos para executar parte dela.
Para restringir o problema, observe o seguinte:
- O que está causando a carga alta? Selecione as opções para ver a capacidade da CPU, a CPU e a espera da CPU, a espera de bloqueio ou a espera de E/S.
- Quanto tempo a carga tem sido alta? Está alta no momento? Ou faz muito tempo? Altere os intervalos de tempo para encontrar a data e a hora em que a carga começou a apresentar baixo desempenho.
- Houve picos de latência? É possível alterar a janela de tempo para estudar a latência histórica da consulta normalizada.
Quando você encontrar as áreas e os horários com a carga mais alta, poderá detalhar ainda mais.
Examinar a latência em um cluster
Use o gráfico Latência P99 na mesma consulta no cluster para examinar a latência P99 na consulta ou tag em todas as instâncias do cluster.
Examinar operações em um plano de consulta de amostra
Um plano de consulta usa uma amostra da sua consulta e a divide em operações individuais. Ela explica e analisa cada operação na consulta. No gráfico Amostras do plano de consulta, todos os planos de consulta são executados em momentos específicos e o tempo que cada plano foi executado.
Para ver detalhes sobre o plano de consulta do exemplo, clique nos pontos no gráfico Planos de consulta de amostra. Há uma visualização de exemplos de planos de consulta executados para a maioria das consultas, mas não todas. Os detalhes expandidos mostram um modelo de todas as operações no plano de consulta. Cada operação mostra a latência, as linhas retornadas e o custo dessa operação. Ao selecionar uma operação, você pode ver mais detalhes, como blocos de hits compartilhados, tipo de esquema, loops reais, linhas de plano e muito mais.
Para restringir o problema, observe o seguinte:
- Qual é o consumo de recursos?
- Como ele se relaciona com outras consultas?
- O consumo muda com o tempo?
Rastrear a origem do problema
Para ajudar a identificar a origem específica do problema, como modelo, visualização, controlador, rota, host ou usuário específicos, os insights de consulta fornecem uma visualização completa do trace no contexto para entender o que está acontecendo na camada do banco de dados de uma solicitação específica e encontrar a origem de uma consulta problemática por modelo, visualização, controladores e rota. Se você ativar o OpenCensus ou o OpenTelemetry, as informações do período de abertura vão ser enviadas ao banco de dados com as informações da tag dentro dos comentários do SQL. Todos os traces do aplicativo com o Cloud Logging são vinculados aos traces do plano de consulta do banco de dados para identificar a origem do problema. Clique na guia END to END na tela Consulta de amostra para analisar o trace no contexto.
Para determinar qual cliente e usuário estão causando o problema, use os principais endereços de cliente e as principais tabelas de usuários para encontrar as cargas mais altas. É possível adicionar um usuário ou endereço IP ao filtro para analisar ainda mais um usuário ou endereço de cliente específico.
Nas consultas, use o Cloud Trace para ver o rastreamento completo de cada etapa do plano. No painel Insights de consulta, clique no link Visualizar no trace para abrir a ferramenta Cloud Trace.
Para detalhes sobre como usar ferramentas no Cloud Trace, consulte Como localizar e visualizar traces.
Adicionar tags às consultas SQL
A marcação de consultas SQL simplifica a solução de problemas de aplicativos. É possível usar o sqlcommenter para adicionar tags às consultas SQL automaticamente, usando o mapeamento relacional de objeto (ORM, na sigla em inglês), ou manualmente.
Usar o sqlcommenter com o ORM
Quando o ORM é usado em vez de escrever as consultas SQL diretamente, talvez você não encontre o código do aplicativo que está causando os problemas de desempenho. Talvez você também tenha problemas para analisar como o código do aplicativo afeta o desempenho da consulta. Para enfrentar esse problema, o Query Insights fornece uma biblioteca de código aberto chamada sqlcommenter, uma biblioteca de instrumentação ORM. Essa biblioteca é útil para desenvolvedores que usam ORMs e administradores para detectar qual código do aplicativo está causando problemas de desempenho.
Se você estiver usando o ORM e o sqlcommenter juntos, as tags serão criadas automaticamente sem a necessidade de alterar ou adicionar código personalizado ao aplicativo.
Você pode instalar o sqlcommenter no servidor de aplicativos. A biblioteca de instrumentação permite que as informações do aplicativo relacionadas ao framework do MVC sejam propagadas para o banco de dados juntamente com as consultas como um comentário SQL. O banco de dados coleta essas tags e começa a registrar e agregar estatísticas por tags, que são ortogonais com estatísticas agregadas por consultas normalizadas. Os insights de consulta mostram as tags para que você saiba qual aplicativo está causando o carregamento da consulta. Essas informações ajudam você a descobrir qual código de aplicativo está causando problemas de desempenho.
Quando você examinar os resultados nos registros do banco de dados SQL, eles vão aparecer assim:
SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/
As tags compatíveis incluem nome, rota, framework e ação do controlador.
O conjunto de ORMs em sqlcommenter é compatível com várias linguagens de programação:
Python |
|
Java |
|
Ruby |
|
Node.js |
|
Veja mais informações sobre o sqlcommenter e como usá-lo no seu framework ORM na documentação do sqlcommenter no GitHub.
Usar o sqlcommenter para adicionar tags manualmente
Se você não estiver usando o ORM, adicione manualmente as tags do sqlcommenter às suas consultas SQL. Na consulta, você precisa aumentar cada instrução SQL com um comentário que contenha um par de chave-valor serializado. Use pelo menos uma das seguintes chaves:
action=''
controller=''
framework=''
route=''
application=''
db driver=''
Os insights de consulta removem todas as outras chaves. Consulte a documentação do sqlcommenter para ver o formato correto de comentário SQL.
Tempo de execução e duração
Query Insights fornecem a métrica Tempo médio de execução (ms), que informa o tempo total que todas as subtarefas levam em todos os workers paralelos para concluir a consulta. Essa métrica pode ajudar você a otimizar a utilização de recursos agregados de bancos de dados encontrando e otimizando consultas que criam a maior sobrecarga de CPU.
Para conferir o tempo decorrido, é possível medir a duração de uma consulta executando o comando \timing
no cliente psql
. Ele mede o tempo decorrido entre
o recebimento da consulta e o envio de uma resposta pelo servidor PostgreSQL. Essa métrica pode
ajudar a analisar por que uma consulta está demorando muito e decidir se ela precisa
ser otimizada para ser executada mais rapidamente.
Se uma consulta for concluída em um único thread por uma única tarefa, a duração e o tempo médio de execução vão permanecer os mesmos.
A seguir
- Visão geral dos insights de consulta
- Melhorar a performance da consulta usando os insights de consulta aprimorados para o AlloyDB
- Métricas do AlloyDB
- Blog SQL Commenter: apresentação do Sqlcommenter: uma biblioteca de instrumentação automática ORM de código aberto
- Blog de instruções: ativar a inclusão de tag de consulta com o sqlcommenter