Ejemplo de análisis de rendimiento

Para seguir las instrucciones del video, abra el informe de ejemplo aquí.

Cómo interpretar el informe de rendimiento

Usando HQbird, o, como un servicio separado, el Análisis de Rendimiento de IBSurgeon desde cc.ib-aid.com, puede generar un informe de rendimiento a partir de los registros de seguimiento (trace logs) de Firebird.

Este informe es una poderosa herramienta de diagnóstico que proporciona información detallada sobre la ejecución de consultas SQL en bases de datos Firebird. Esta guía explica cómo interpretar y utilizar los informes de seguimiento para identificar y resolver cuellos de botella de rendimiento de manera sistemática.

1. Estructura del Informe de Rendimiento

┌─────────────────────────────────────────┐
│         Informe de Rendimiento          │
├─────────────────────────────────────────┤
│ 1. Gráficos de Resumen de Rendimiento   │
│    ┌────────────────────────┐           │
│    │  Consultas principales │           │
│    │     Resumen principal  │           │
│    │     Frecuencia principal│          │
│    │     Duraciones         │           │
│    │     Fetchs             │           │
│    │     Lecturas           │           │
│    │     Escrituras         │           │
│    │  Gráfico de Serie Temporal│        │
│    │     Duraciones         │           │
│    │     Conteo de consultas│           │
│    │     Fetchs             │           │
│    │     Lecturas/Escrituras│           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 2. Análisis de Consultas Principales    │
│    ┌────────────────────────┐           │
│    │ Clasificaciones de Consultas       │
│    │                        │           │
│    │  Por Duración───┐      │           │
│    │                │       │           │
│    │  Por Tiempo ───┤       │           │
│    │  Resumen       │       │           │
│    │                │       │           │
│    │  Por Plan  ────┤       │           │
│    │  Resumen       │       │           │
│    │                │       │           │
│    │  Por Frecuencia┤       │           │
│    │                │       │           │
│    │  Por Plan  ────┤       │           │
│    │  Frecuencia    │       │           │
│    │                │       │           │
│    │  Por Fetchs ───┤       │           │
│    │                │       │           │
│    │  Por Lecturas ─┤       │           │
│    │                │       │           │
│    │  Por Escrituras┘       │           │
│    │                        │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 3. Resumen de Procesos                  │
│    ┌────────────────────────┐           │
│    │ Estadísticas por Proceso│          │
│    │ - Conteos de ejecución │           │
│    │ - Fetchs, etc.         │           │
│    │ - Métricas de duración │           │
│    └────────────────────────┘           │
├─────────────────────────────────────────┤
│ 4. Resumen de Direcciones               │
│    ┌────────────────────────┐           │
│    │Estadísticas por Dirección de Cliente│
│    │ - Conteos de conexiones│           │
│    │ - Duraciones           │           │
│    │ - Fetchs, etc.         │           │
│    │ - Nombres de procesos  │           │
│    └────────────────────────┘           │
└─────────────────────────────────────────┘

Estructura de Detalles de Consulta:
┌────────────────────┐
│ Información de Consulta │
├────────────────────┤
│ - Texto SQL        │
│ - Info de transacción │
│ - Plan de ejecución│
│ - Estadísticas de duración│
│ - Estadísticas de recursos│
│   * Fetchs          │
│   * Lecturas        │
│   * Escrituras      │
│   * Marcas          │
│ - Info del cliente  │
└────────────────────┘

El informe de rendimiento proporciona una vista jerárquica de la actividad de la base de datos:

1. Gráficos de Resumen de Rendimiento

• Representación visual de métricas clave a lo largo del tiempo - puede ver fácilmente los picos de actividad/carga. (También hay un informe de análisis por minuto disponible en el Monitoreo Avanzado de Rendimiento en HQbird; la versión abreviada está disponible en la herramienta del Portal - vea este video para más detalles).

• Ayuda a identificar patrones y anomalías: comparar gráficos de períodos con buen rendimiento (por ejemplo, la semana/mes pasado) con problemas de rendimiento puede ayudar a identificar el problema.

2. Análisis de Consultas Principales

• Múltiples perspectivas de clasificación para un análisis completo: las consultas más largas, las consultas más frecuentes, las consultas que consumen más tiempo (agrupadas por texto o plan), y más.

• Cada dimensión revela diferentes oportunidades de optimización

• Estadísticas detalladas para cada consulta, incluyendo:

• Métricas de duración (mín, máx, promedio, mediana)

• Consumo de recursos (fetchs, lecturas, escrituras)

• Patrones de ejecución: número de orígenes para las consultas principales.

3. Resumen de Procesos

• Agrupa estadísticas por proceso de ejecución

• Ayuda a identificar aplicaciones problemáticas

• Muestra el consumo de recursos y las operaciones de base de datos (conexiones, consultas, etc.) y métricas (fetchs, lecturas, etc.) por proceso

4. Resumen de Direcciones

• Agrupa estadísticas por conexión de cliente

• Revela la distribución de la carga entre clientes

• Ayuda a identificar problemas específicos de conexión

Cada sección respalda el análisis de rendimiento en diferentes niveles:

• Patrones a nivel de sistema (Gráficos): vea cuándo y dónde ocurren los problemas en general.

• Impacto más notable de las consultas (Consultas Principales): identifique las consultas que deben optimizarse primero.

• Problemas a nivel de aplicación (Resumen de Procesos): identifique las aplicaciones que generan problemas de rendimiento.

• Problemas a nivel de cliente (Resumen de Direcciones): identifique las direcciones IP (estaciones de trabajo, computadoras de clientes) con el mayor flujo de consultas.

2. Análisis de Resumen de Tiempo y Resumen de Plan

Se recomienda comenzar el análisis de la situación de rendimiento con las secciones de Resumen. Haga clic aquí para abrir la sección de Resumen de Plan en el informe de ejemplo.

El Resumen de Tiempo agrega el tiempo total de ejecución para cada patrón de declaración SQL único.

Piense en ello como un informe de “centro de costos” que muestra qué consultas están consumiendo más recursos de la base de datos a lo largo del tiempo.

Si las consultas no están parametrizadas, es decir, contienen explícitamente los valores de los parámetros dentro del texto SQL en lugar de un marcador de posición de parámetro (:myparam1), es necesario usar la sección "Resumen de Plan" para identificar las consultas con mayor frecuencia.
Ejemplo de consulta no parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Ejemplo de consulta parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

Cada consulta en la sección de Resumen tiene un encabezado con las siguientes partes clave:

• Resumen: Porcentaje de tiempo total; muestra qué porción del tiempo total de la base de datos consume una consulta.

• Frecuencia: Cuántas veces aparece el patrón de consulta.

• Fetch, Lectura, Escritura: Métricas de recursos.

Por ejemplo, si hay

Resumen: 19.08% (3920272 de 20541791 ms)

Esto nos dice que este patrón de consulta está consumiendo casi el 20% del tiempo total de la base de datos: una porción significativa que merece atención inmediata.

Debajo del encabezado en la sección de Resumen de Plan veremos el plan de ejecución SQL que se usó para agrupar las consultas; en el Resumen de Tiempo será el texto de la consulta en sí.

Dado que el patrón de consulta representa más de una consulta específica, la información específica sobre la conexión se toma de la primera consulta que corresponde al patrón:

En la captura de pantalla anterior puede ver el encabezado de la declaración de ejemplo para el patrón; consiste en el nombre de la aplicación que inició este SQL, el ID de conexión y el ID de transacción, así como la dirección IP y los detalles de la transacción.

Debajo va el plan (para el Resumen de Tiempo; para el Resumen de Plan se omite porque ya se muestra al principio), los valores de los parámetros (en el orden de aparición) y las estadísticas por tabla:

Recuerde que en el Resumen de Plan agrupamos los SQL usando el plan de ejecución, lo que significa que solo el plan es persistente para el patrón; y para el Resumen de Tiempo agrupamos usando el texto de la declaración SQL, y otras cosas (valores de parámetros, tiempos de ejecución, etc.) pueden ser diferentes. Use esta información como ejemplo del patrón de ejecución (en el 99% de los casos es suficiente para reproducir el problema).

Debajo tenemos un gráfico individual con las ejecuciones de esta consulta específica. Como puede ver, esta consulta se inició en el período de alta carga que notamos en el gráfico general.

Y, al final, tenemos una colección muy importante de estadísticas para TODAS las consultas que corresponden al patrón, y la lista de direcciones de origen:

En estas estadísticas podemos ver los tiempos de ejecución mínimo, máximo, promedio y mediana, así como las mismas estadísticas para fetchs, lecturas, escrituras y marcas (operaciones de vaciado de caché).

2.1. Cómo usar el Resumen de Tiempo:

• Primero identifique las consultas que consumen tiempo desproporcionado (son las 3 principales de esta sección: #1, 2, 3).

• Compare el consumo de tiempo con la frecuencia.

• Vea el tiempo promedio de ejecución (tiempo total / frecuencia) en la parte inferior de la sección de la consulta (ver más abajo).

• Busque patrones donde:

• Alto tiempo + Baja frecuencia = Consultas individuales ineficientes

• Alto tiempo + Alta frecuencia = Consultas potencialmente ineficientes pero muy utilizadas

3. Análisis de Frecuencia: Frecuencia y Frecuencia de Plan

Use el análisis de frecuencia para comprender con qué frecuencia se ejecutan las consultas. Piense en ello como contar cuántas veces se usa una carretera en particular durante la hora pico.

Si las consultas no están parametrizadas, es decir, contienen explícitamente los valores de los parámetros dentro del texto SQL en lugar de un marcador de posición de parámetro (:myparam1), es necesario usar la sección "Resumen de Plan" para identificar las consultas con mayor frecuencia.
Ejemplo de consulta no parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=2'
Ejemplo de consulta parametrizada: 'SELECT * FROM COUNTRY WHERE COUNTRYID=:paramid'

3.1. Comprendiendo el Impacto de la Frecuencia

La representación del patrón de consulta de Frecuencia es muy similar al Resumen de Plan/Tiempo:

Las consultas de alta frecuencia son como intersecciones concurridas: incluso si cada automóvil (consulta) se mueve rápido, el gran volumen puede causar congestión. Esto afecta:

• Conexiones de base de datos (como espacios de estacionamiento: limitados en número)

• Ancho de banda de red (como la capacidad de la carretera)

• Uso de CPU (como controladores de tráfico que se saturan)

• Eficiencia de caché (como tener que acceder repetidamente a la misma información)

Para estimar el impacto de consultas de alta frecuencia, recopile un trace con umbral de parámetro = 0.

3.2. Categorías de Impacto por Frecuencia

3.3. Análisis de Ejemplo

Examinemos un caso real de nuestro informe de trace:

Frecuencia: 4,428 ejecuciones (24.43% del total)
Impacto: Crítico - alto volumen de consultas a la tabla SALES
Causa raíz: Verificaciones repetitivas de saldo de clientes
Prioridad de optimización: Alta

Explicación: Esta consulta se ejecuta miles de veces, similar a una
intersección concurrida. Aunque cada ejecución pueda ser rápida, el
impacto acumulativo es significativo. La aplicación podría estar
verificando saldos con más frecuencia de la necesaria.

4. Análisis de estadísticas de las consultas principales en las secciones xx-Summary y Frequency

Al analizar informes de trace de Firebird, cada agrupación de consultas contiene estadísticas agregadas detalladas que proporcionan información crucial sobre los patrones de rendimiento. Desglosemos cada métrica y comprendamos su importancia para la optimización de bases de datos.

4.1. Análisis de Estadísticas Agregadas

Examinemos este conjunto de estadísticas de ejemplo:

Total: 4428 items:
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%);
From 1 unique addresses: TCPv6:::1 (4428)

4.2. Análisis del Número de Ejecuciones

4.2.1. Total de Elementos

Total: 4428 items

Esto representa el número de veces que este patrón de consulta particular se ejecutó durante el período de trace.

Comprender este número le ayuda a:

• Calcular el uso de recursos por ejecución

• Determinar si el almacenamiento en caché de consultas podría ser beneficioso (o simplemente ejecutarlo con menos frecuencia)

Los recuentos de ejecución altos podrían indicar oportunidades para:

• Implementar sentencias preparadas (y parametrizadas): la misma consulta con la misma frecuencia, cuando se parametriza y prepara para ejecución repetitiva, requerirá menos recursos

• Agregar caché de resultados: almacenar en caché el valor resultante para usarlo durante la operación larga o incluso más tiempo, durante la sesión del usuario, puede reducir la necesidad de ejecutar consultas con frecuencia

• Operaciones por lotes: considere ejecutar la consulta para devolver o procesar muchos registros a la vez, lo que eliminará la sobrecarga de ejecutar la consulta (preparación, transmisión de red, etc.).

4.3. Métricas de Duración

4.3.1. Ejemplo de Componentes de Duración

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

4.3.2. Análisis de Duración

• La mediana y el promedio cercanos (457.70 vs 455.00 ms) sugieren un rendimiento consistente

• La relación máx/mín (~11x) indica cierta variabilidad

• El 20.29% del tiempo total es significativo: ¿está esta consulta en las 3 principales de la sección Frequency o Plan-Frequency? (sí, lo está).

4.4. Métricas de Uso de Recursos

4.4.1. Operaciones de Fetch

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

Los fetches representan recuperaciones de filas:

• Recuentos de fetch consistentes (diferencia mín/máx de solo 33) sugieren conjuntos de resultados estables

• Recuentos de fetch relativamente altos (>7000 por ejecución) podrían indicar:

• Necesidad de limitar el conjunto de resultados y/o paginación, si se devuelven muchos registros.

• Potencial de optimización de consultas - especialmente tiene sentido si la consulta está en las 3 principales de Frequency/Plan-Frequency.

4.5. Operaciones de Lectura

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

Las lecturas físicas indican acceso a disco:

• Mediana cero con máximo no nulo sugiere fallos de caché ocasionales

• El 8.22% del total de lecturas indica un impacto de E/S moderado

• La gran brecha entre mín (0) y máx (6995) sugiere una efectividad de caché variable.

4.6. Operaciones de Escritura

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

Si la consulta no realiza escrituras, generalmente es una operación de solo lectura.

4.7. Operaciones de Mark

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

Las operaciones de mark se relacionan con la gestión de caché de páginas de datos:

• Cero marks indican que ninguna página de datos fue marcada para vaciado, común en consultas SELECT simples

• Operaciones de mark no nulas con caché

4.8. Análisis de Conexión del Cliente

From 1 unique addresses: TCPv6:::1 (4428)

Esto muestra la distribución del origen de la consulta:

• Dirección de cliente única sugiere consulta específica de la aplicación

• Conexión local (::1 es localhost IPv6)

• Las 4428 ejecuciones provienen de la misma fuente

4.9. Uso de Estas Métricas para la Optimización

4.9.1. Análisis de Patrones de Rendimiento

Consistencia de Ejecución

• Comparar duraciones mín/máx

• Buscar valores atípicos en el uso de recursos

• Verificar mediana vs promedio para variabilidad

Patrones de Uso de Recursos

• Fetches altos → Revisar tamaño del conjunto de resultados

• Lecturas altas → Verificar cobertura de índices

• Marks altos → Examinar contención de bloqueos

Análisis de Impacto del Cliente

• Múltiples clientes → Dimensionamiento del pool de conexiones

• Cliente único → Optimización de la aplicación

4.9.2. Prioridades de Optimización

Basado en estas métricas, priorice:

• Tamaño del Conjunto de Resultados

• 7000 fetches por ejecución

• Considere agregar LIMIT/OFFSET

• Revise la lista de columnas del SELECT

Estrategia de Caché

• Ejecución frecuente (4428 veces)

• Tamaño de resultado consistente

• Sin escrituras involucradas

Probablemente, esta consulta podría ejecutarse con menos frecuencia.

Uso de Índices

• Recuentos de lectura variables

• Mediana de lecturas cero pero máximo alto

• Revise la cobertura de índices

5. Aplicación Práctica

Para este ejemplo específico:

Mejoras a Corto Plazo:

• Implementar caché de resultados (alto número de ejecuciones, fetches consistentes)

• Revisar el tamaño del conjunto de resultados (>7000 fetches por ejecución)

Optimización a Mediano Plazo:

• Analizar patrones de uso de índices

• Considerar el uso de sentencias preparadas

• Revisar la lógica de la aplicación para la frecuencia de ejecución

Consideraciones a Largo Plazo:

• Monitorear patrones de ejecución a lo largo del tiempo

• Planificar estrategia de mantenimiento de índices

• Considerar cambios en los patrones de acceso a datos

6. Análisis de Duración

El análisis de duración examina cuánto tiempo tardan las consultas individuales en ejecutarse. Piense en la duración como un cronómetro que mide cada consulta: cuanto más tarda una consulta, más probable es que cause problemas de rendimiento.

6.1. Comprensión de las Métricas de Duración

Las métricas de duración son cruciales porque afectan directamente la experiencia del usuario, es decir, los usuarios afirman que “el sistema está lento”. Así como los clientes se frustran al esperar en una fila larga, los usuarios se frustran cuando las consultas tardan demasiado en completarse. Las consultas de larga duración causan:

• Mala experiencia de usuario cuando las pantallas tardan demasiado en cargar

• Recursos del sistema ocupados durante períodos prolongados

• Otras consultas esperando en fila detrás de las lentas

• Posibles problemas de tiempo de espera en las aplicaciones

6.2. Categorías de Impacto

6.3. Análisis de Ejemplo

Duración: 77,793ms
Impacto: Crítico - consulta única consumiendo 77.7 segundos
Causa raíz: Agregación compleja en PRC_COLLECT_RANKCATEGORY
Prioridad de optimización: Inmediata

Explicación: Esta consulta tarda más de un minuto en ejecutarse, lo que es como
una parada total del tráfico. El procedimiento almacenado probablemente está
procesando demasiados datos o utilizando algoritmos ineficientes.

7. Estrategia de Implementación

Piense en la optimización como mejorar un sistema de transporte: necesita identificar problemas, planificar soluciones e implementar cambios cuidadosamente.

7.1. Matriz de Priorización

Esta matriz le ayuda a decidir qué necesita atención primero, como clasificar problemas de tráfico en una ciudad:

7.2. Proceso de Optimización Paso a Paso

1. Identificar Consultas Críticas

• Busque los mayores atascos de tráfico (consultas lentas)

• Encuentre las intersecciones más concurridas (consultas de alta frecuencia)

• Detecte rutas ineficientes (alto uso de recursos)

2. Analizar Planes de Ejecución

• Estudie las rutas actuales (uso de índices)

• Examine los patrones de tráfico (métodos de join)

• Verifique los cuellos de botella (operaciones de ordenamiento)

3. Implementar Optimizaciones

• Construya nuevas carreteras (índices)

• Rediseñe rutas (reestructure consultas)

• Agregue atajos (caché)

4. Verificar Mejoras

• Mida el nuevo flujo de tráfico (nuevo informe de trace)

• Compare métricas antes/después

• Documente lo que funcionó

Contacte a IBSurgeon con cualquier pregunta

No dude en contactarnos con cualquier pregunta: [email protected].