IBAnalyst: lo que puedes ver en la Vista de Resumen

Dmitry Kuzmenko, última actualización 31-03-2014

Resumen

Este documento está dedicado a explicar la información en la página “Vista de resumen” de IBAnalyst, y cómo interpretar esta información para tus propias estadísticas de base de datos. También hemos añadido varios ejemplos de estadísticas al paquete de instalación para facilitarte el estudio de todos los detalles de las estadísticas de InterBase. Están en el directorio Examples de la instalación de IBAnalyst.

Si no sabes qué es Oldest transaction, Oldest snapshot, active y Next, por favor lee antes el artículo de Craig Stunz “Understanding Transactions Lifetime”:

http://blogs.teamb.com/craigstuntz/articles/UnderstandingTransactionLifetimes.aspx

Números de transacción

Si has leído el artículo Understanding Transaction Lifetimes, quizás todavía tengas preguntas sobre los números OIT/OST/OAT. Aquí hay una breve descripción:


Número	Se mantiene, …	Avanza, …
Oldest transaction	cuando una transacción con este número fue revertida, y había muchos cambios de datos en ella, o cuando se perdió la conexión del cliente	cuando el barrido automático o manual tiene éxito.
Oldest Snapshot	cuando una snapshot (o read committed write anterior a IB 7.1) está activa durante mucho tiempo (recordó la snapshot activa más antigua como su OST local)	cuando comienza una nueva transacción, si la transacción que mantiene OST ha terminado
Oldest Active	cuando una transacción con este número está activa durante mucho tiempo	cuando comienza una nueva transacción, si la transacción que mantiene OAT ha terminado
Next	nunca	cuando comienza una nueva transacción

nota: Oldest transaction aquí es lo mismo que Oldest Interesting Transaction (OIT), mencionado en muchos otros artículos.

Estadísticas finas con configuración estándar

Vamos a iniciar IBAnalyst y abrir (con Statistics/Load statistics from file menu) el archivo !allok.txt.

IBAnalyst no solo informa la fecha de creación de la base de datos, sino que también reconoce la fecha y hora actual del servidor si las estadísticas se tomaron a través de Services API, o la fecha del archivo si es un archivo de estadísticas cargado.

Por eso sugerimos no modificar los archivos de estadísticas, porque en ese caso IBAnalyst calculará incorrectamente el promedio de transacciones por día. La fila de transacciones por día aquí muestra aproximadamente ~12500 transacciones por día y que la base de datos “vive” desde su creación o restauración durante 8 días.

Oldest, Oldest snapshot, Oldest active y Next transactions están en estado perfecto aquí, deseo que siempre tengas estadísticas que se vean así.

Muchas transacciones activas

A continuación, abre el archivo !lotofactive.txt (puedes mirar la imagen de !allok en cualquier momento para comparar los siguientes ejemplos con ella).

Aquí la fila de Active transactions está marcada en rojo, porque hay una gran diferencia entre Oldest active y Next transaction. Esto significa que alguna transacción en el momento en que se tomaron las estadísticas todavía estaba activa, y después de su inicio ya comenzaron 55,000 transacciones (pueden estar en cualquier estado - activas, confirmadas, revertidas). Dado que el conteo de transacciones promedio por día es ~12500, IBAnalyst te muestra una advertencia de que alguna transacción todavía vive durante 4.4 días. Esto puede suceder cuando:

alguna aplicación todavía está en ejecución y tiene al menos una transacción abierta - algún usuario quizás mantiene la aplicación en ejecución durante mucho tiempo
la aplicación se ejecuta durante mucho tiempo y pierde los manejadores de transacción - es decir, tu código (o los componentes/bibliotecas que usas) inicia transacciones dinámicamente, y bajo algunas circunstancias “olvida” terminarlas con rollback o commit.
tu aplicación no usa transacciones explícitas (BDE), dejando el manejo de transacciones a los componentes que se usan. Como resultado, la vida útil de las transacciones no está controlada por la aplicación, y puedes pensar con seguridad que la mayoría de las transacciones Next-OAT están realmente activas.
tu aplicación usa un controlador o componentes que permiten “transacción predeterminada”. Si tu código no controla esta transacción, puede ejecutarse durante mucho tiempo.

Lamentablemente, las estadísticas no muestran el número real de transacciones actualmente activas. Esto solo se puede ver en InterBase 7.x usando IBConsole, IB Performance Monitor o mediante una consulta directa a la tabla temporal del sistema tmp$transactions. En Firebird 1.5 puedes llamar a isc_database_info con el parámetro isc_info_active_transactions.

Barrido (Sweep)

Ahora abramos !needsweep.txt.

El barrido es un proceso de mantenimiento dentro de InterBase. El barrido recorre todos los registros de la base de datos e intenta limpiar todas las versiones de basura, luego intenta avanzar el número de Oldest transaction. En una base de datos recién creada, el intervalo de barrido por defecto es 20000. Cuando la diferencia entre transacciones (ver tabla abajo) se vuelve mayor que el intervalo de barrido, el barrido se ejecutará automáticamente. Así, puedes ver degradaciones periódicas de rendimiento en tu base de datos. Por ejemplo, tus aplicaciones funcionan bien durante el lunes y martes, pero el miércoles los usuarios informan problemas de rendimiento durante algunas horas, y luego el rendimiento vuelve a ser normal.

Si ves un comportamiento similar - es un barrido automático.


Versión del servidor	Cuándo se ejecuta el barrido
InterBase 7.x	(Oldest Active - Oldest) > Intervalo de barrido
InterBase 4.x, 5.x, 6.x, Firebird anterior a 1.5.2, Yaffil	(Oldest Snapshot - Oldest) > Intervalo de barrido

Tabla 1. Condiciones para que se ejecute el barrido automático

nota: IBAnalyst muestra automáticamente la información correcta de Sweep gap para todas las versiones. IBAnalyst solo puede detectar la diferencia entre implementaciones de servidor por el id de ODS, por ejemplo, InterBase 7.x tiene ODS 11.x, otros servidores modernos tienen ODS 10.x. Si solo trabajas con bases de datos InterBase 7.x (ODS 11), puedes cambiar la opción correspondiente en el diálogo de Opciones.

Cuando tu base de datos tiene un intervalo de barrido <> 0, IBAnalyst básicamente marca esta fila en amarillo (advirtiéndote que el barrido automático puede comenzar en cualquier momento impredecible). Generalmente el 60% de todas las aplicaciones tienen problemas con el barrido automático. La forma más fácil de evitar este problema es establecer el intervalo de barrido en 0, lo que lleva a desactivar el barrido automático. Pero, si alguna aplicación hace muchos cambios y luego revierte, Oldest transaction se congelará y no avanzará hasta que se ejecute el barrido. Dado que el estado efectivo de las transacciones se calcula desde Oldest hasta Next transaction, esta distancia crecerá y el rendimiento caerá. Para prevenir esto, debes ejecutar el barrido manualmente (gfix -sweep). En esta imagen puedes ver el comportamiento cuando el intervalo de barrido es 0 y hubo una gran transacción revertida:

Aquí el valor de sweep gap muestra que alguna transacción grande (con muchos cambios) fue revertida hace aproximadamente 4.5 días. Te recomendamos ejecutar el barrido manualmente cada día.

Por supuesto, para ese 60% de aplicaciones mencionado quizás sea mejor establecer el intervalo de barrido mayor o menor que 20000, pero depende de muchos factores (las transacciones diarias son uno de estos factores, por ejemplo) y solo se puede entender de manera experimental. Así que, si estableces el intervalo de barrido en 0, puedes estar seguro de que el barrido no se ejecutará automáticamente en un momento impredecible.

La misma imagen la puedes ver para el archivo !rollback.txt.

nota: Si el barrido se ejecuta automáticamente, para una base de datos grande o una base de datos con muchas versiones de registros basura, Snapshot, Active y Next transactions pueden avanzar mientras el barrido trabaja, y el barrido puede comenzar de nuevo en el inicio de transacción más cercano.

Cuando el barrido no puede hacer su trabajo

Hay muchos casos en los que el barrido no puede mover Oldest transaction más arriba. Por supuesto, el barrido primero intenta hacer su trabajo, es decir, revisar todos los registros de la base de datos y recoger las versiones de registros innecesarias. Pero se ejecutará una y otra vez sin éxito si

hubo algún problema cuando se ejecutó el barrido: el servidor se detuvo durante el barrido, o hubo un error durante la limpieza de versiones de registros basura. Además, puedes ver esta imagen cuando:

las estadísticas se tomaron mientras el barrido trabajaba
el barrido se está ejecutando e intentando recoger basura para una tabla que se está actualizando constantemente. Esto puede durar hasta que las actualizaciones terminen.
el barrido está bloqueado por bloqueos de página, porque hay muchos usuarios trabajando con los datos.

En general, el barrido no tiene posibilidades de terminar durante una carga alta de la base de datos. Usualmente, cuando el rendimiento se degrada hasta la imposibilidad de continuar el trabajo normal, el DBA reinicia el servidor, y el barrido se ejecuta en la primera conexión de usuario. Dado que habrá algo de tiempo mientras otros usuarios se conectan, el barrido tendrá tiempo de terminar su trabajo.

Dado que InterBase 7.1/7.5 calcula el Sweep gap de manera diferente a versiones anteriores, la otra situación en la que el barrido no puede hacer su trabajo es cuando alguna aplicación tiene una transacción snapshot de larga duración:

Aquí hay dos advertencias - una (amarilla) sobre snapshot de larga duración, y otra (roja) sobre el intervalo de barrido y el sweep gap.

Snapshot de larga duración

La imagen anterior indica una snapshot de larga duración en InterBase 7.1/7.5. Si el intervalo de barrido se hubiera establecido en 0, no habría advertencias rojas, solo amarillas. Una imagen similar indicará una transacción snapshot de larga duración en otras versiones de InterBase, Firebird y Yaffil:

Como ves aquí, el Sweep gap se calcula por la diferencia entre Oldest Snapshot y Oldest transaction (para ODS 10, versiones pre-IB7.x). Así que no hay advertencia de barrido (excepto el intervalo de barrido predeterminado).

Pero, no solo las transacciones snapshot afectan el estado de las transacciones de esta manera. Todas las versiones de InterBase, Firebird y Yaffil excepto InterBase 7.1/7.5 tienen el siguiente comportamiento, que hemos llamado “artefacto read committed”.

Snapshots de nuevo y Cuándo ReadCommitted congela Oldest Snapshot

Abre !snapshot2.txt.:

Nota que Oldest transaction es mayor que Oldest snapshot. Y Sweep gap tiene un valor negativo. Esto puede suceder en dos casos. El primer caso es cuando hay algunas transacciones snapshot que comienzan y se confirman una tras otra. Es decir, esta imagen puede suceder con snapshots así como la imagen anterior. El siguiente caso sucede solo en servidores distintos de IB 7.1/7.5 con transacciones ReadCommitted (o en combinación de transacciones ReadCommitted y Snapshot). Pueden bloquear el número de Oldest Snapshot de la misma manera que lo hacen las transacciones Snapshot. El estado actual de las transacciones se puede emular con la siguiente secuencia

iniciar transacción 1, snapshot o read_committed
iniciar/confirmar algunas transacciones read_committed
iniciar transacción 2, snapshot o read_committed
iniciar/confirmar algunas transacciones read_committed
confirmar transacción 1

(por supuesto, hablamos aquí de transacciones read_committed write, no de solo lectura).

En este punto, la transacción 2 actualmente activa (snapshot o read committed), iniciada después de snapshot 1 (marca 3), mantendrá el número de snapshots como Oldest Snapshot (si trabajas con IB 7.1/7.5 esto solo puede suceder con transacciones snapshot concurrentes. read_committed o read_committed+snapshot no producirán este efecto). Dado que no hubo grandes reversiones, Oldest transaction avanza y se vuelve mayor que Oldest Snapshot.

Ahora, si tienes una transacción read committed de larga duración, verás una imagen como esta. Lamentablemente, no puedes hacer nada aquí con tus aplicaciones (excepto agregar el parámetro “read” para transacciones de solo lectura). Y por supuesto, el barrido no se ejecutará automáticamente (si está establecido <> 0) en este caso.

nota: este comportamiento se corregirá en Firebird 2.0

Vistas absolutas y relativas

Por defecto, IBAnalyst llena las filas de transacciones según el porcentaje de su valor absoluto. Es decir, el 100% es de 0 a Next transaction. A veces, cuando la base de datos funciona durante mucho tiempo, puedes ver la información de transacciones como

Mientras hay muchas transacciones, la diferencia entre snapshot, active y oldest se ve muy pequeña (cerca del 98%). Para aclarar la situación, abre el diálogo de Opciones, pestaña Transactions, y marca la opción “Relative (from oldest) bars %” (no puedes marcar esta casilla si usas la vista de estilo antiguo, sin barras gráficas). Después de presionar el botón OK, la vista de transacciones cambiará a

Ahora verás la diferencia de transacciones en vista relativa (100% es desde la transacción más antigua (o snapshot) hasta la siguiente, no desde 0). Es más fácil entender la situación actual y ver las advertencias (si las hay).

Esta vista se mantendrá hasta que la desmarques con el diálogo de Opciones. Puedes entender qué vista estás viendo por la fila de Transacción más antigua o Snapshot más antiguo: en la vista relativa, una de estas filas nunca se llena de color verde. En la vista absoluta, siempre está llena (parcialmente, por supuesto).

¿Aún tienes preguntas? Pregúntanos en [email protected]