Checkpoints no bloqueantes

08/01/2016

Introduccion

  1. La problemática de los checkpoints en versiones anteriores a la 11.1
  2. Nueva característica: Nonblocking Checkpoint
  3. Ventajas
  4. Funcionamiento
  5. Recomendaciones
  6. Cuando bloquearán los checkpoints

 

La problemática de los checkpoints en versiones anteriores a la 11.1

El proceso de checkpoint implica bloquear temporalmente la actividad del servidor mientras se escriben los buffers de la memoria compartida a disco. La frecuencia y duración de los checkpoints, y el tiempo necesario para bloquear depende de como esté configurado el servidor. Para afinar correctamente la actividad de checkpoint, es necesario encontrar un equilibrio entre la duración del checkpoint y su frecuencia.

Para impedir que los checkpoints bloqueen durante largos períodos de tiempo, la única solución es lanzarlos con más fecuenca y establecer los umbrales de LRU bajos. Aumentar la frecuencia de los checkpoints implica más operaciones de I/O a disco con el consiguiente perjuicio de rendimiento. Establecer las LRU’s a valores bajos, reduce el cache de escritura, provoca volcados constantes del bufferpool, consume muchos ciclos de cpu e incrementa la contención en los buffers.

Nueva característica: Nonblocking Checkpoint

En la versión 11 de Informix se ha modificado el algoritmo de checkpoint para reducir el tiempo de bloqueo del servidor. Los fuzzy checkpoints se han eliminado.

Los checkpoints provocados por intervalo de tiempo o limitaciones de recursos no bloquean la actividad de usuario mientras se vuelcan los buffers a disco.

Los checkpoints administrativos (los requeridos por el servidor cuando ocurren ciertos eventos, como adición de un dbspace) y los de backup (ocurren al inicio de un backup) sí bloquean la actividad de usuario.

Ventajas

Con los nonblocking checkpoints no se para el proceso transaccional mientras se escriben los buffers de la memoria compartida. Además, los valores de LRU pueden incrementarse, provocando el aumentando del cache de escritura, disminuyendo accesos de escritura a disco y disminuyendo la contención en los buffers. Se ha introducido también la característica de autotuneado de las LRU’s que modifican los umbrales en función de la actividad transaccional del servidor.

Funcionamiento

  1. Petición de checkpoint
  2. Bloqueo de transacciones
  3. Registro de checkpoint (como si hubiese ocurrido) en la página reservada de physical log, pero no en la página reservada de checkpoint.
  4. Desbloqueo de transacciones.
  5. Escritura a disco de todos los buffers modificados al inicio del checkpoint.
  6. Registro de checkpoint en la página reservada de checkpoint en disco.

Con este nuevo algoritmo la duración de bloqueo se reduce al tiempo de escritura de registro de checkpoint a la página reservada de physical log, después las transacciones se desbloquean para iniciar el vaciado de los buffers. Si el servidor cae antes del último regitro de checkpoint en la página reservada de checkpoint, la recuperación se incia desde el último checkpoint completo.

Recomendaciones de uso

Se recomienda aumentar los parámetros lru_min_dirty y lru_max_dirty al menos a 60 y 70 respectivamente en el nuevo parámetro de configuración BUFFERPOOLS.

Tener un tamaño de physical y logical log suficientemente grande para acomodar toda la actividad de checkpoint (>2GB). Observar recomendaciones de tamaño registradas en el fichero de mensajes.

Uso del comando onstat –g ckp como guía de ayuda de configuración de estos recursos.

Cuando bloquearán los checkpoints

Los checkpoint bloquearán la actividad transaccional cuando:

  1. No hayan recursos de log:
    1. El physical log se llena hasta un 75%
    2. El logical log completa una vueta desde el último checkpoint.
  2. Los recursos de log se están agotando de forma crítica. Tener en cuenta que durante el proceso de checkpoint las transacciones continúan consumiendo espacio de physical y logical log, de tal forma que a mayor duración de escritura de buffers durante checkpoint se necesitará más espacio de log.

Para prevenir dicha situación, aumentar los tamaños de physical y logical log y hacer uso de la nueva característica de automatic checkpoint (AUTO_CKPTS = 1).

Con esta caracterísitica el servidor automáticamente lanzará checkpoints con más frecuencia para impedir que se quede sin recursos de log.