Como monitorizar los checkpoint en Informix

Los chekpoint son un punto de consistencia en Informix que garantiza el retorno en caso de fallo

Visitas: 382

Checkpoint es el proceso mediante el cual Informix vuelca a disco los buffers modificados en memoria. Es un punto de consistencia que garantiza el retorno a dicho estado en caso de fallo.

Un checkpoint puede ocurrir de forma automática bajo varias circunstancias o hacerlo manualmente ejecutando el comando onmode –c.

Hasta la versión 10 de Informix, los checkpoint eran bloqueantes. Esto significa que se suspendía la actividad del usuario hasta finalizar el checkpoint. Aunque los checkpoint ya no son bloqueantes, ciertos eventos como por ejemplo, el inicio del backup o añadir un dbspace son bloqueantes. Por otra parte, cuando un checkpoint comienza a ejecutarse con recursos insuficientes, Informix bloquea las transacciones para asegurarse de finalizarlo antes de quedarse sin ellos.

¿Por qué es importante analizar los checkpoint?

  • Mejorar el rendimiento y aumentar la disponibilidad.
  • Conocimiento del perfil de actividad.
  • Análisis de cambio de tendencia y comportamiento de nuestro motor de BBDD.

Veamos cada uno de los puntos:

Mejorar rendimiento y aumentar la disponibilidad

Monitorizar los checkpoint nos proporciona información muy valiosa a la hora de conocer la actividad y recursos disponibles.

Informix guarda información de los últimos 20 checkpoint. Podemos consultarlos mediante el comando onstat –g ckp o haciendo una query sobre la tabla syscheckpoint de la base de datos sysmaster.

Si la duración de los checkpoint (expresada en segundos) es alta y hay pocos buffers sucios (dirty buffers), indicará sin duda un cuello de botella en disco. Esta situación mantenida en el tiempo, será percibida por los usuarios y repercutirá negativamente en la disponibilidad de la información.

Conocimiento del perfil de actividad

Si analizamos gráficamente la media de la duración de los checkpoint en cada hora, identificaremos en qué momentos del día hay más actividad sobre el motor de base de datos. Podremos identificar los puntos valle para planificar la ejecución de trabajos en batch, o bien, identificar ventana para realizar trabajos de mantenimiento.

Análisis de cambio de tendencia y comportamiento de nuestro motor de BBDD

Si analizamos gráficamente la media de la duración de los checkpoint diariamente, semanalmente o mensualmente, podremos detectar cambios de tendencia. Si hemos cambiado el almacenamiento, cualquier otro recurso hardware, o bien, la configuración de Informix ($ONCONFIG), podremos observar cómo ha influido en la duración de los checkpoint.

Si no hemos cambiado nada y observamos un cambio de tendencia, seguramente habrá sido causado por un cambio en la actividad sobre el motor de base de datos. Si la duración ha aumentado, quizá haya que plantearse una mejora de recursos.

¿Cómo puedo recopilar los checkpoint y analizarlos?

Como hemos indicado anteriormente, dada la importancia que tiene el análisis de los checkpoint y teniendo en cuenta que solo podemos consultar los últimos 20 checkpoint, es necesario desarrollar procedimientos adicionales para almacenar todos los checkpoint.

Para ello nos apoyaremos en un script para descargar periódicamente (tener en cuenta el valor de parámetro CKPTINTVL) el contenido de syscheckpoint y otro script para cargarlo en una tabla similar, creada por nosotros. Dado que cada checkpoint tiene un identificador único en la tabla syscheckpoint (Columna Interval) podemos apoyarnos en el comando merge de Informix para no contener registros duplicados. Mediante crontab planificaremos adecuadamente las tareas de descarga y carga.

Una vez que tenemos almacenados todos los checkpoint, podremos analizarlos con la ayuda de herramientas de Business Intelligence.

Ejemplos de monitorización de checkpoint

En la siguiente imagen podemos observar la salida del comando onstat –g ckp. Se muestran los últimos 20 checkpoint. Esta información la podemos consultar en la tabla sysadmin:syscheckpoint.

La explicación de cada campo no es el objetivo de este documento y se puede consultar en el manual IBM Informix Administrator’s Reference. No obstante haremos hincapié en los datos a supervisar y que pueden ser de utilidad para nuestro objetivo:

Interval: número secuencial del checkpoint.

Clock Time: hora de ejecución (campo datetime en syscheckpoint)

Trigger: evento que ha disparado el checkpoint.

LSN: número de logical log que contiene el checkpoint (ver onstat –l)

Total Time: duración total del chekpoint (seg.)

Flush Time: duración del volcado de los dirty buffers a disco.

Waits número de transacciones bloqueadas durante el checkpoint.

Dirty Buffers: número de buffers volcados a disco. A mayor número mayor actividad de INSERT, UPDATE, DELETE.

Dskflu/Sec = Dirty Buffers / Flush Time

Log Avg/Sec = Logical Total Pages / tiempo transcurrido desde el último checkpoint. Idem para el Physical log.

Podemos graficar por un lado el Total Time, y por otro las gráficas de Dirty Buffers y Dskflu/Sec conjuntamente (que estas dos graficas permanezcan próximas indicará que nuestros checkpoint son bajos). De esta manera identificaremos los picos de actividad y evolución del comportamiento tras cambios que hayamos realizado.

Veamos ahora algunos ejemplos de gráficas evolutivas.

Ejemplo de cambio de comportamiento en la duración de checkpoint tras sustituir la cabina de almacenamiento por una de mejores prestaciones. Se puede observar como a partir de la semana 6 bajó la duración de los checkpoint (media semanal).

De la misma manera podemos ver como las gráficas de Dirty Buffers y Disk Flush se aproximan tras la semana 6.

Via: https://www.ibm.com/support/...

Autor

Imagen de Business Platform

Equipo

CAPTCHA
Esta pregunta es para comprobar si usted es un visitante humano y prevenir envíos de spam automatizado.