Exemplo de análise de desempenho

Para acompanhar as instruções em vídeo, abra o exemplo de relatório aqui.

Como interpretar o relatório de desempenho

Usando o HQbird ou, como um serviço separado, o IBSurgeon Performance Analysis de cc.ib-aid.com, você pode gerar um relatório de desempenho a partir dos logs de rastreamento do Firebird.

Este relatório é uma ferramenta de diagnóstico poderosa que fornece informações detalhadas sobre a execução de consultas SQL em bancos de dados Firebird. Este guia explica como interpretar e usar relatórios de rastreamento para identificar e resolver gargalos de desempenho de forma sistemática.

1. Estrutura do Relatório de Desempenho

┌─────────────────────────────────────────┐
│         Relatório de Desempenho         │
├─────────────────────────────────────────┤
│ 1. Gráficos de Resumo de Desempenho     │
│    ┌────────────────────────┐           │
│    │  Principais consultas  │           │
│    │     Resumo principal   │           │
│    │     Frequência principal│          │
│    │     Durações           │           │
│    │     Buscas (fetches)   │           │
│    │     Leituras           │           │
│    │     Gravações          │           │
│    │  Gráfico de Séries Temporais│       │
│    │     Durações           │           │
│    │     Contagem de consultas│         │
│    │     Buscas (fetches)   │           │
│    │     Leituras/Gravações │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Análise das Principais Consultas     │
│    ┌────────────────────────┐           │
│    │ Classificações de Consultas│       │
│    │                        │           │
│    │  Por Duração────────┐  │           │
│    │                     │  │           │
│    │  Por Tempo──────────┤  │           │
│    │  Resumo             │  │           │
│    │                     │  │           │
│    │  Por Plano──────────┤  │           │
│    │  Resumo             │  │           │
│    │                     │  │           │
│    │  Por Frequência─────┤  │           │
│    │                     │  │           │
│    │  Por Plano──────────┤  │           │
│    │  Frequência         │  │           │
│    │                     │  │           │
│    │  Por Buscas─────────┤  │           │
│    │                     │  │           │
│    │  Por Leituras───────┤  │           │
│    │                     │  │           │
│    │  Por Gravações──────┘  │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Resumo por Processo                  │
│    ┌────────────────────────┐           │
│    │ Estatísticas por Processo│         │
│    │ - Contagens de execução│           │
│    │ - Buscas, etc.         │           │
│    │ - Métricas de duração  │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Resumo por Endereço                  │
│    ┌────────────────────────┐           │
│    │Estatísticas por Endereço de Cliente││
│    │ - Contagens de conexões│           │
│    │ - Durações             │           │
│    │ - Buscas, etc.         │           │
│    │ - Nomes de processos   │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Estrutura de Detalhes da Consulta:
┌────────────────────┐
│ Informações da Consulta│
├────────────────────┤
│ - Texto SQL        │
│ - Informações da transação│
│ - Plano de Execução│
│ - Estatísticas de Duração│
│ - Estatísticas de Recursos│
│   * Buscas (fetches)│
│   * Leituras       │
│   * Gravações      │
│   * Marcações      │
│ - Informações do Cliente│
└────────────────────┘

O relatório de desempenho fornece uma visão hierárquica da atividade do banco de dados:

1. Gráficos de Resumo de Desempenho

• Representação visual das métricas principais ao longo do tempo - você pode facilmente ver picos de atividade/carga. (Também existe um relatório de análise por minuto disponível no Monitoramento Avançado de Desempenho no HQbird; a versão resumida dele está disponível na ferramenta do Portal - veja este vídeo para detalhes).

• Ajuda a identificar padrões e anomalias: comparar gráficos de períodos com bom desempenho (por exemplo, semana/mês passado) com problemas de desempenho pode ajudar a identificar o problema.

2. Análise das Principais Consultas

• Múltiplas perspectivas de classificação para análise abrangente: as consultas mais longas, as consultas mais frequentes, as consultas que mais consomem tempo (agrupadas por texto ou plano), e mais.

• Cada dimensão revela diferentes oportunidades de otimização

• Estatísticas detalhadas para cada consulta, incluindo:

• Métricas de duração (mín, máx, média, mediana)

• Consumo de recursos (buscas, leituras, gravações)

• Padrões de execução - número de origens para as principais consultas.

3. Resumo por Processo

• Agrupa estatísticas por processo de execução

• Ajuda a identificar aplicativos problemáticos

• Mostra consumo de recursos e operações do banco de dados (conexões, consultas, etc.) e métricas (buscas, leituras, etc.) por processo

4. Resumo por Endereço

• Agrupa estatísticas por conexão de cliente

• Revela a distribuição de carga entre clientes

• Ajuda a identificar problemas específicos de conexão

Cada seção suporta análise de desempenho em diferentes níveis:

• Padrões de todo o sistema (Gráficos) - veja quando e onde os problemas ocorrem em geral.

• Impacto mais notável das consultas (Principais Consultas) - identifique consultas que devem ser otimizadas primeiro.

• Problemas no nível do aplicativo (Resumo por Processo) - identifique aplicativos que produzem problemas de desempenho.

• Problemas no nível do cliente (Resumo por Endereço) - identifique endereços IP (estações de trabalho, computadores de clientes) com o maior fluxo de consultas.

2. Análise de Resumo de Tempo e Resumo de Plano

Recomenda-se iniciar a análise da situação de desempenho pelas seções de Resumo. Clique aqui para abrir a seção Resumo de Plano no relatório de exemplo.

O Resumo de Tempo agrega o tempo total de execução para cada padrão de instrução SQL exclusivo.

Pense nele como um relatório de “centro de custo” que mostra quais consultas estão consumindo mais recursos do banco de dados ao longo do tempo.

Se as consultas não forem parametrizadas, ou seja, contiverem explicitamente os valores dos parâmetros dentro do texto SQL em vez de um espaço reservado para parâmetros (:myparam1), é necessário usar a seção "Resumo de Plano" para identificar consultas com maior frequência.
Exemplo de consulta não parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Exemplo de consulta parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Cada consulta na seção Resumo tem um cabeçalho com as seguintes partes principais:

• Resumo: Percentual do tempo total, mostra qual parte do tempo total do banco de dados uma consulta consome.

• Frequência: Quantas vezes o padrão de consulta aparece

• Busca, Leitura, Gravação: métricas de recursos

Por exemplo, se houver

Resumo: 19.08% (3920272 de 20541791 ms)

Isso nos diz que este padrão de consulta está consumindo quase 20% do tempo total do banco de dados - uma parte significativa que merece atenção imediata.

Abaixo do cabeçalho na seção Resumo de Plano, veremos o plano de execução SQL usado para agrupar consultas; no Resumo de Tempo, será o texto da própria consulta.

Como o padrão de consulta representa mais de uma consulta específica, as informações específicas sobre a conexão são obtidas da primeira consulta que corresponde ao padrão:

Na captura de tela acima, você pode ver o cabeçalho do exemplo de instrução para o padrão; ele consiste no nome do aplicativo que iniciou este SQL, ID da conexão e ID da transação, bem como endereço IP e detalhes da transação.

Abaixo seguem o plano (para Resumo de Tempo; para Resumo de Plano é omitido porque já é mostrado no início), valores dos parâmetros (na ordem de aparecimento) e estatísticas por tabela:

Lembre-se: no Resumo de Plano, agrupamos SQLs usando o plano de execução, o que significa que apenas o plano é persistente para o padrão; no Resumo de Tempo, agrupamos usando o texto da instrução SQL, e outras coisas (valores de parâmetros, tempos de execução, etc.) podem ser diferentes. Use essas informações como exemplo do padrão de execução (em 99% dos casos, é suficiente para reproduzir o problema).

Abaixo, temos um gráfico individual com execuções desta consulta específica. Como você pode ver, esta consulta foi iniciada no período de alta carga que notamos no gráfico geral.

E, no final, temos uma coleção muito importante de estatísticas para TODAS as consultas que correspondem ao padrão, e a lista de endereços de origem:

Nessas estatísticas, podemos ver os tempos de execução mínimo, máximo, médio e mediano, e as mesmas estatísticas para buscas, leituras, gravações e marcações (operações de liberação de cache).

2.1. Como Usar o Resumo de Tempo:

• Primeiro, identifique consultas que consomem tempo desproporcional (elas são as 3 primeiras desta seção - #1, 2, 3)

• Compare o consumo de tempo com a frequência

• Veja o tempo médio de execução (tempo total / frequência) na parte inferior da seção da consulta (veja abaixo)

• Procure padrões onde:

• Alto tempo + Baixa frequência = Consultas individuais ineficientes

• Alto tempo + Alta frequência = Consultas potencialmente ineficientes, mas muito usadas

3. Análise de Frequência: Frequência e Frequência de Plano

Use a análise de frequência para entender com que frequência as consultas são executadas. Pense nisso como contar quantas vezes uma determinada estrada é usada durante a hora do rush.

Se as consultas não forem parametrizadas, ou seja, contiverem explicitamente os valores dos parâmetros dentro do texto SQL em vez de um espaço reservado para parâmetros (:myparam1), é necessário usar a seção "Resumo de Plano" para identificar consultas com maior frequência.
Exemplo de consulta não parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Exemplo de consulta parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Entendendo o Impacto da Frequência

A representação do padrão de consulta por Frequência é muito semelhante ao Resumo de Plano/Tempo:

Consultas de alta frequência são como cruzamentos movimentados - mesmo que cada carro (consulta) se mova rapidamente, o grande volume pode causar congestionamento. Isso afeta:

• Conexões do banco de dados (como vagas de estacionamento - limitadas em número)

• Largura de banda da rede (como capacidade da estrada)

• Uso de CPU (como controladores de tráfego ficando sobrecarregados)

• Eficiência de cache (como ter que acessar repetidamente as mesmas informações)

Para estimar o impacto de consultas de alta frequência, colete o trace com o parâmetro threshold = 0.

3.2. Categorias de Impacto de Frequência

3.3. Exemplo de Análise

Vamos examinar um caso real do nosso relatório de trace:

Frequência: 4.428 execuções (24,43% do total)
Impacto: Crítico - alto volume de consultas na tabela SALES
Causa Raiz: Verificações repetitivas de saldo do cliente
Prioridade de Otimização: Alta

Explicação: Esta consulta está sendo executada milhares de vezes, semelhante a um
cruzamento movimentado. Mesmo que cada execução possa ser rápida, o
impacto cumulativo é significativo. A aplicação pode estar verificando
saldos com mais frequência do que o necessário.

4. Análise das estatísticas das principais consultas nas seções xx-Summary e Frequency

Ao analisar relatórios de trace do Firebird, cada agrupamento de consultas contém estatísticas agregadas detalhadas que fornecem insights cruciais sobre padrões de desempenho. Vamos detalhar cada métrica e entender sua importância para a otimização do banco de dados.

4.1. Análise de Estatísticas Agregadas

Vamos examinar este exemplo de conjunto de estatísticas:

Total: 4428 itens:
Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20,29%);
Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0,75%);
Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0,00%);
Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8,22%);
Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0,00%);
De 1 endereço único: TCPv6:::1 (4428)

4.2. Análise do Número de Execuções

4.2.1. Total de Itens

Total: 4428 itens

Isso representa o número de vezes que este padrão específico de consulta foi executado durante o período do trace.

Entender este número ajuda você a:

• Calcular o uso de recursos por execução

• Determinar se o cache de consultas pode ser benéfico (ou simplesmente executá-la com menos frequência)

Contagens altas de execução podem indicar oportunidades para:

• Implementar statements preparados (e parametrizados) - a mesma consulta com a mesma frequência, quando parametrizada e preparada para execução repetitiva, exigirá menos recursos

• Adicionar cache de resultados - armazenar em cache o valor resultante para uso durante a operação longa ou até por mais tempo, para a sessão do usuário, pode reduzir a necessidade de executar a consulta com frequência

• Operações em lote - considere executar a consulta para retornar ou processar muitos registros de uma vez, isso eliminará a sobrecarga de executar a consulta (preparação, transmissão de rede, etc.)

4.3. Métricas de Duração

4.3.1. Exemplo de Componentes de Duração

Durations: min: 351; max: 3919; avg: 457.70; median: 455.00; sum: 2026710 (20,29%);

4.3.2. Análise de Duração

• Mediana e média próximas (457,70 vs 455,00 ms) sugerem desempenho consistente

• Proporção máx/mín (~11x) indica alguma variabilidade

• 20,29% do tempo total é significativo - esta consulta está no top 3 da seção Frequency ou Plan-Frequency? (sim, está.)

4.4. Métricas de Uso de Recursos

4.4.1. Operações de Fetch

Fetches: min: 7135; max: 7168; avg: 7146.86; median: 7147.00; sum: 31646289 (0,75%);

Fetches representam recuperações de linhas:

• Contagens de fetch consistentes (diferença mín/máx de apenas 33) sugerem conjuntos de resultados estáveis

• Contagens de fetch relativamente altas (>7000 por execução) podem indicar:

• Necessidade de limitar o conjunto de resultados e/ou paginação, se muitos registros forem retornados.

• Potencial para otimização da consulta - especialmente faz sentido se a consulta estiver no top 3 de Frequency/Plan-Frequency.

4.5. Operações de Leitura

Reads: min: 0; max: 6995; avg: 3.13; median: 0.00; sum: 13856 (8,22%);

Leituras físicas indicam acesso a disco:

• Mediana zero com máximo não nulo sugere falhas ocasionais de cache

• 8,22% do total de leituras indica impacto moderado de I/O

• Grande diferença entre mín (0) e máx (6995) sugere eficácia variável do cache.

4.6. Operações de Escrita

Writes: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0,00%);

Se a consulta não realiza escritas, geralmente é uma operação somente leitura.

4.7. Operações de Mark

Marks: min: 0; max: 0; avg: 0.00; median: 0.00; sum: 0 (0,00%);

Operações de mark estão relacionadas ao gerenciamento de cache de páginas de dados:

• Marks zero indicam que nenhuma página de dados foi marcada para flush, comum para consultas SELECT simples

• Operações de mark não nulas com cache

4.8. Análise de Conexão do Cliente

De 1 endereço único: TCPv6:::1 (4428)

Isso mostra a distribuição da origem da consulta:

• Endereço de cliente único sugere consulta específica da aplicação

• Conexão local (::1 é localhost IPv6)

• Todas as 4428 execuções da mesma origem

4.9. Usando Estas Métricas para Otimização

4.9.1. Análise de Padrões de Desempenho

Consistência de Execução

• Compare durações mín/máx

• Procure por valores atípicos no uso de recursos

• Verifique mediana vs média para variabilidade

Padrões de Uso de Recursos

• Fetches altos → Revise o tamanho do conjunto de resultados

• Reads altos → Verifique a cobertura dos índices

• Marks altos → Examine contenção de locks

Análise de Impacto do Cliente

• Múltiplos clientes → Dimensionamento do pool de conexões

• Cliente único → Otimização da aplicação

4.9.2. Prioridades de Otimização

Com base nestas métricas, priorize:

• Tamanho do Conjunto de Resultados

• 7000 fetches por execução

• Considere adicionar LIMIT/OFFSET

• Revise a lista de colunas do SELECT

Estratégia de Cache

• Execução frequente (4428 vezes)

• Tamanho de resultado consistente

• Sem escritas envolvidas

Provavelmente, esta consulta pode ser executada com menos frequência.

Uso de Índices

• Contagens de leitura variáveis

• Mediana de leituras zero, mas máximo alto

• Revise a cobertura dos índices

5. Aplicação Prática

Para este exemplo específico:

Melhorias de Curto Prazo:

• Implementar cache de resultados (alta contagem de execuções, fetches consistentes)

• Revisar o tamanho do conjunto de resultados (>7000 fetches por execução)

Otimização de Médio Prazo:

• Analisar padrões de uso de índices

• Considerar uso de statements preparados

• Revisar a lógica da aplicação quanto à frequência de execução

Considerações de Longo Prazo:

• Monitorar padrões de execução ao longo do tempo

• Planejar estratégia de manutenção de índices

• Considerar mudanças nos padrões de acesso a dados

6. Análise de Duração

A análise de duração examina quanto tempo consultas individuais levam para executar. Pense na duração como um cronômetro medindo cada consulta - quanto mais tempo uma consulta leva, maior a probabilidade de causar problemas de desempenho.

6.1. Entendendo as Métricas de Duração

As métricas de duração são cruciais porque afetam diretamente a experiência dos usuários, ou seja, os usuários reclamam que “o sistema está lento”. Assim como os clientes ficam frustrados esperando em uma fila longa, os usuários ficam frustrados quando as consultas demoram demais para concluir. Consultas de longa duração causam:

• Má experiência do usuário quando as telas demoram demais para carregar

• Recursos do sistema ocupados por períodos prolongados

• Outras consultas esperando na fila atrás das lentas

• Possíveis problemas de timeout nas aplicações

6.2. Categorias de Impacto

6.3. Exemplo de Análise

Duração: 77.793ms
Impacto: Crítico - consulta única consumindo 77,7 segundos
Causa Raiz: Agregação complexa em PRC_COLLECT_RANKCATEGORY
Prioridade de Otimização: Imediata

Explicação: Esta consulta está levando mais de um minuto para executar, o que é como
uma parada total no trânsito. A stored procedure provavelmente está processando
muitos dados ou usando algoritmos ineficientes.

7. Estratégia de Implementação

Pense na otimização como melhorar um sistema de transporte - você precisa identificar problemas, planejar soluções e implementar mudanças com cuidado.

7.1. Matriz de Priorização

Esta matriz ajuda você a decidir o que precisa de atenção primeiro, como fazer triagem de problemas de tráfego em uma cidade:

7.2. Processo de Otimização Passo a Passo

1. Identificar Consultas Críticas

• Procure os maiores congestionamentos (consultas lentas)

• Encontre os cruzamentos mais movimentados (consultas de alta frequência)

• Identifique rotas ineficientes (alto uso de recursos)

2. Analisar Planos de Execução

• Estude as rotas atuais (uso de índices)

• Examine os padrões de tráfego (métodos de join)

• Verifique gargalos (operações de ordenação)

3. Implementar Otimizações

• Construa novas estradas (índices)

• Redesenhe rotas (reestruture consultas)

• Adicione atalhos (cache)

4. Verificar Melhorias

• Meça o novo fluxo de tráfego (novo relatório de trace)

• Compare métricas antes/depois

• Documente o que funcionou

Entre em contato com a IBSurgeon para qualquer dúvida

Sinta-se à vontade para nos contatar com qualquer dúvida: [email protected].