Melhorar a performance de consultas usando os insights

Para detectar e analisar gargalos de desempenho de consultas, inspecionar planos de consulta e rastrear solicitações de alta latência nas instâncias do AlloyDB para PostgreSQL, use o painel Query Insights. Para uma visão geral desse recurso, consulte Visão geral do Query Insights.

Você pode usar o Gemini Cloud Assist para ajudar a monitorar e resolver problemas nos 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 realizar o rastreamento completo, será necessário ter permissões específicas do Identity and Access Management (IAM). É possível criar um papel personalizado e adicionar as permissões necessárias do IAM a ele. Em seguida, adicione esse papel a cada conta de usuário que usa o Query Insights para resolver 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 do Query Insights

Para abrir o painel do Query Insights, siga estas etapas:

  1. Na lista de clusters e instâncias, clique em uma instância.
  2. Clique em Acessar o 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 Query Insights no painel de navegação à esquerda.

Na página seguinte, use as seguintes opções para filtrar os resultados:

  1. Seletor de instâncias. Permite selecionar a instância principal ou as instâncias do pool de leitura no cluster. Por padrão, a instância principal é selecionada. Os detalhes mostrados são agregados para todas as instâncias de pool de leitura conectadas e os nós delas.
  2. Banco de dados. Filtra a carga de consulta em um banco de dados específico ou em todos os bancos de dados.
  3. Usuário. Filtra a carga de consulta de contas de usuário específicas.
  4. Endereço do cliente. Filtra a carga de consulta de um endereço IP específico.
  5. Período. Filtra a carga da consulta por períodos, como hora, dia, semana ou um intervalo personalizado.
O painel do Query Insights oferece um seletor de instâncias e menus suspensos para bancos de dados, usuários e endereços. À direita dos menus suspensos, há um filtro para definir um período.

Editar a configuração do Query Insights

O Query Insights é ativado por padrão nas instâncias do AlloyDB. É possível editar a configuração padrão do Query Insights.

Para editar a configuração do Query Insights de uma instância do AlloyDB, siga estas etapas:

Console

  1. No Google Cloud console, acesse a página Clusters.

    Acessar Clusters

  2. Clique em um cluster na coluna Nome do Recurso.

  3. Clique em Query Insights no painel de navegação à esquerda.

  4. Selecione Principal ou Pool de leitura na lista Query Insights e clique em Editar.

  5. Edite os campos do Query Insights:

    1. Para alterar o limite padrão de 1.024 bytes no tamanho das consultas para o AlloyDB analisar, no campo Tamanho das consultas, insira um número de 256 a 4.500.

      A instância é reiniciada depois que você edita esse campo.

      Observação: limites de comprimento de consulta mais altos exigem mais memória.

    2. Para personalizar os conjuntos de atributos do Query Insights, ajuste as seguintes opções:

      • Amostragem do plano de consulta: marque essa caixa de seleção para visualizar as operações usadas para concluir uma amostra 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ó.

        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 Amostragem do plano de consulta.

      • Armazenar endereços IP do cliente: marque essa caixa de seleção para saber de onde as consultas estão vindo e agrupar essas informações para gerar métricas.

      • Armazenar tags de aplicativos: marque essa caixa de seleção para saber quais aplicativos com tags estão fazendo solicitações e agrupar essas informações para gerar métricas. Para mais informações sobre tags de aplicativo, consulte a especificação.

  6. Clique em Atualizar instância.

gcloud

Para ativar o Query Insights em uma instância do AlloyDB usando comandos da Google Cloud CLI, faça o seguinte:

  1. Instale a CLI do Google Cloud.
  2. Para inicializar a CLI gcloud, execute o seguinte comando: 
    gcloud init

  3. Se você estiver usando um shell local, crie credenciais de autenticação local para sua conta de usuário: 

    gcloud auth application-default login

    Não é necessário fazer isso se você estiver usando o Cloud Shell.

    Para mais informações, consulte Configurar a autenticação para um ambiente de desenvolvimento local.

Veja um exemplo:

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:

  • INSTANCE: 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 tamanho da consulta, que 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. Tamanhos de consulta maiores são mais úteis para consultas analíticas, mas também exigem mais memória. Para alterar o tamanho da consulta, é necessário reiniciar 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. Altere esse valor para um número de 1 a 20. Para desativar a amostragem, insira 0. É provável que o aumento da taxa de amostragem ofereça mais pontos de dados, mas isso pode adicionar um overhead 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. A análise de gráficos para consultas de endereços IP de clientes pode ajudar a identificar a origem de um problema. Se você não quiser armazenar endereços IP do cliente, 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 dados para executar métricas neles. Essa opção exige que você comente as consultas com um conjunto específico de tags. Se você não quiser armazenar tags de aplicativos, use --no-insights-config-record-application-tags.

Terraform

Para usar o Terraform e configurar o Query Insights, use o recurso google_alloydb_instance.

Veja um exemplo:

  query_insights_config {
    query_string_length = QUERY_STRING_LENGTH_VALUE
    record_application_tags = RECORD_APPLICATION_TAG_VALUE
    record_client_address = RECORD_CLIENT_ADDRESS_VALUE
    query_plans_per_minute = QUERY_PLANS_PER_MINUTE_VALUE5
  }

Substitua:

  • QUERY_STRING_LENGTH_VALUE: tamanho da string de consulta. O valor padrão é 1024. Qualquer número inteiro entre 256 e 4.500 é válido.
  • RECORD_APPLICATION_TAG_VALUE: registra a tag de aplicativo para uma instância. O valor padrão é true.
  • RECORD_CLIENT_ADDRESS_VALUE: registra o endereço do cliente para uma instância. O valor padrão é true.

  • QUERY_PLANS_PER_MINUTE_VALUE: o número de planos de execução de consultas capturados por insights por minuto de todas as consultas combinadas. O valor padrão é 5. Qualquer número inteiro entre 0 e 20 é válido.

    Para aprender a aplicar ou remover uma configuração do Terraform, consulte Comandos básicos do Terraform.

    A configuração de instância de amostra com a configuração do Query Insights adicionada deve aparecer da seguinte maneira:

    resource "google_alloydb_instance" "instance_name" {
provider = "google-beta"
cluster       = google_alloydb_cluster.default.name
instance_id   = "instance_id"
instance_type = "PRIMARY"

machine_config {
 cpu_count = 8
}

query_insights_config {
query_string_length = 1024
record_application_tags = false
record_client_address = false
query_plans_per_minute = 5
}

depends_on = [google_alloydb_instance.default]
}

REST v1

Este exemplo define as configurações de observabilidade na sua instância do AlloyDB. Para uma lista completa de parâmetros dessa chamada, consulte Método: projects.locations.clusters.instances.patch.

Para definir as configurações do Query Insights, modifique os campos opcionais conforme necessário. Para uma lista completa de campos dessa chamada, consulte QueryInsightsInstanceConfig.

Antes de usar os dados da solicitação, faça as seguintes substituições:

  • CLUSTER_ID: o ID do cluster que você está criando. Ele precisa começar com uma letra minúscula e pode conter letras minúsculas, números e hifens.
  • PROJECT_ID: o ID do projeto em que você quer colocar o cluster.
  • LOCATION_ID: o ID da região do cluster.
  • INSTANCE_ID: o nome da instância primária que você quer criar.

Para modificar a configuração da instância, use a seguinte solicitação PATCH:

PATCH https://alloydb.googleapis.com/v1beta/{instance.name=projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled}

O corpo JSON da solicitação que configura todos os campos de observabilidade é parecido com este:

{
  "queryStringLength": integer,
  "recordApplicationTags": boolean,
  "recordClientAddress": boolean,
  "queryPlansPerMinute": integer
}

Melhorar o desempenho da consulta

O Query Insights resolve problemas de consultas do AlloyDB para procurar problemas de desempenho. O painel do Query Insights mostra a carga de 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.

O Query Insights ajuda a detectar e analisar problemas de desempenho de consultas. Para resolver problemas de consultas com o Query Insights, siga estas etapas:

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 consultas mais frequentes usando dados filtrados. A carga de consulta do banco de dados é uma medida do trabalho (em segundos de CPU) realizado pelas consultas executadas no banco de dados selecionado 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.

Mostra o gráfico de carga do banco de dados com uma carga para a capacidade da CPU, a CPU e a espera da CPU, a E/S de espera e a espera de bloqueio.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

As seções Consultas e tags permitem filtrar ou classificar a carga de consulta para uma consulta selecionada ou 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 do Query Insights.

Por padrão, a tabela classifica as consultas pelo tempo total de execução dentro do período selecionado.

Mostra o gráfico de carga do banco de dados com uma carga para consultas, com filtros selecionados para capacidade de CPU, espera de CPU e CPU, espera de E/S e espera de bloqueio.

Para filtrar a tabela, selecione uma propriedade em Filtrar consultas. Para classificar a tabela, selecione o título de uma coluna. A tabela mostra as seguintes propriedades:

  • String de consulta. A string de consulta normalizada. Por padrão, o Query Insights mostra apenas 1.024 caracteres na string de consulta.

    As consultas rotuladas como UTILITY COMMAND geralmente incluem comandos BEGIN, COMMIT e EXPLAIN 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 etc. 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 o Query Insights possa 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.

O Query Insights fornece 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, o Query Insights fornecerá 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 Query Insights usa o tempo gasto por cada consulta que usa a tag selecionada. O Query Insights calcula o tempo de conclusão no limite dos minutos usando o tempo convencional.

No painel do Query Insights, selecione TAGS para ver a tabela de tags. A tabela TAGS classifica as tags pelo carregamento total por tempo total.

A Figura 5 mostra o painel do Query Insights, com carga para tags. Abaixo do gráfico, há uma lista de tags.

É 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:

  1. Clique no cabeçalho Carga por tempo total para classificar a lista em ordem decrescente.
  2. 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:

Mostra uma versão truncada da consulta selecionada.

Se você selecionou uma tag, uma visão geral dela será mostrada.

Analisar 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 superior da tabela, são exibidos os primeiros 1.024 caracteres da consulta normalizada, com literais removidos para fins 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. A carga de consulta é dividida em Capacidade da CPU, CPU e espera de CPU, Espera de E/S e Espera de bloqueio.

Mostra os gráficos de latência e carga do banco de dados de uma consulta específica.

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.

Mostra os gráficos de latência e carga do banco de dados de uma consulta específica.

Analisar 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 no tempo real. O painel de latência mostra as latências de 50º, 95º e 99º percentis para encontrar comportamentos atípicos.

Mostra o gráfico de latência de uma consulta específica com filtros selecionados para a capacidade de CPU, a CPU e a espera da CPU, o pedido de veiculação de espera e a espera de bloqueio.

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:

  1. 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.
  2. Quanto tempo a carga tem sido alta? Está alta no momento? Ou faz muito tempo? Altere os períodos para encontrar a data e a hora em que a carga começou a apresentar baixo desempenho.
  3. Houve picos de latência? É possível alterar a janela de tempo para estudar a latência histórica da consulta normalizada.

Ao encontrar as áreas e os horários de maior carga, você pode detalhar ainda mais.

Analisar 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 instâncias no cluster.

Mostra o gráfico de latência de uma consulta específica com filtros selecionados para a capacidade de CPU, a CPU e a espera da CPU, o pedido de veiculação de espera e a espera de bloqueio.

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.

Mostra um gráfico para amostras de planos de consulta, com o tempo em que foram executados na parte inferior do gráfico (eixo x) e o número de segundos em que foram executados à direita (eixo y).

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. O AlloyDB para PostgreSQL faz amostras de consultas automaticamente. Quanto mais uma consulta é executada, maior é a probabilidade de ela ser amostrada. Se você precisar ver mais amostras de planos de consulta, siga as instruções em Editar a configuração do Query Insights para aumentar a Taxa máxima de amostragem.

Ao visualizar os detalhes expandidos de um plano de consulta, você vê um modelo de todas as operações dentro desse plano. Cada operação mostra a latência, as linhas retornadas e o custo da operação. Quando você seleciona uma operação, pode ver mais detalhes, como blocos de hits compartilhados, o tipo de esquema, os loops reais, as linhas de planejamento e muito mais.

O plano de consulta mostra a latência e o custo de cada operação executada para a consulta.

Para restringir o problema, observe o seguinte:

  1. Qual é o consumo de recursos?
  2. Como ele se relaciona com outras consultas?
  3. O consumo muda com o tempo?

Analisar um trace gerado por uma consulta de amostra

Além de visualizar o plano de consulta de amostra, use o Query Insights para visualizar um trace de aplicativo completo e contextualizado para uma consulta de amostra. Esse trace pode ajudar a identificar a origem de uma consulta problemática, mostrando a atividade do banco de dados para uma solicitação específica. Além disso, as entradas de registro que o aplicativo envia ao Cloud Logging durante a solicitação são vinculadas ao trace, o que ajuda na investigação.

Para visualizar o trace no contexto, faça o seguinte:

  1. No painel Consulta de amostra, clique na guia Trace de ponta a ponta. Essa guia mostra um diagrama de Gantt que detalha os períodos, que são registros de operações individuais, para o trace gerado pela consulta.

  2. Para ver mais detalhes sobre cada período, como atributos e metadados, clique nele.

Também é possível ver o trace na página Explorador de traces. Para isso, clique em Ver no Cloud Trace. Para saber como usar a página do Explorador de traces para analisar seus dados de trace, consulte Encontrar e analisar 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 resolver esse problema, o Query Insights fornece uma biblioteca de código aberto chamada sqlcommenter, uma biblioteca de instrumentação de 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 Query Insights mostram as tags para que você saiba qual aplicativo está causando a carga da consulta. Essas informações ajudam a encontrar qual código do 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
  • Django
  • psycopg2
  • Sqlalchemy
  • Flask
Java
  • Hibernate
  • Spring
Ruby
  • Rails
Node.js
  • Knex.js
  • Sequelize.js
  • Express.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=''

O Query Insights remove todas as outras chaves. Consulte a documentação do sqlcommenter para ver o formato correto de comentário SQL.

Tempo e duração da execução

O Query Insights fornece uma métrica de 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 a otimizar a utilização agregada de recursos dos bancos de dados, encontrando e otimizando consultas que criam a maior sobrecarga de CPU.

Para conferir o tempo decorrido, meça a duração de uma consulta executando o comando \timing no cliente psql. Ela mede o tempo que decorre entre o recebimento da consulta e o envio de uma resposta pelo servidor do PostgreSQL. Essa métrica pode ajudar a analisar por que uma determinada consulta está demorando muito e decidir se ela deve ser otimizada para ser executada mais rapidamente.

Se uma consulta for concluída em uma única linha de execução por uma única tarefa, a duração e o tempo médio de execução permanecerão os mesmos.

Ativar os recursos avançados de Query Insights para o AlloyDB

Os recursos avançados do Query Insights para o painel do AlloyDB estão integrados ao painel padrão do Query Insights. Para mais informações sobre como ativar os recursos avançados do Query Insights, consulte Melhorar o desempenho de consultas usando os recursos avançados do Query Insights.

A seguir