Dimensionar bien los buffer pools en Db2 for z/OS es una de las palancas de rendimiento más potentes… y a la vez una de las más peligrosas si decides “subir a ojo” el valor de un buffer pool en producción.
El Buffer Pool Simulator es una herramienta integrada directamente en el motor de Db2, por lo que no tiene ningún coste extra y te permite probar, medir y justificar un aumento de memoria antes de comprometerla de verdad.
¿Qué problema resuelve el Buffer Pool Simulator?
En casi todos los clientes ocurre lo mismo:
- Subes el VPSIZE “porque hay memoria” y esperas que el hit ratio de los buffer pools mejore.
- No tienes claro cuánta E/S realmente vas a evitar.
- Si te pasas, puedes comprometer memoria real, penalizar otros subsistemas y generar el efecto contrario al que buscabas.
El Buffer Pool Simulator ataca este problema permitiendo una simulación “what‑if” del tamaño del buffer pool, sin asignar buffers físicos adicionales. Db2 sigue ejecutando tu carga real, pero empieza a llevar la cuenta de qué habría pasado si el pool fuera más grande.
Conceptos clave:
Para entender cómo funciona el simulador, hay tres parámetros que tienes que tener claros.
- VPSIZE: tamaño real del buffer pool (número de buffers).
- SPSIZE: tamaño simulado adicional que quieres probar.
- SPSEQT: Porcentaje del buffer pool simulado que puede ser ocupado por páginas accedidas secuencialmente antes de que Db2 empiece a robarlas preferentemente.
El tamaño “efectivo” que Db2 simula es:
Tamaño total simulado = VPSIZE + SPSIZEFuncionamiento de la simulación
El Db2 no reserva nuevos buffers reales para SPSIZE. En su lugar, crea estructuras de control que representan esos buffers simulados y calcula qué páginas habrían vivido en ese espacio extra. El consumo de memoria de estas estructuras ronda un pequeño porcentaje del tamaño simulado, muy inferior a asignar buffers reales.
- En el funcionamiento normal de un buffer pool , cuando una página es «robada» porque el buffer no tiene espacio para almacenar una nueva, se pierde para el buffer pool.
- Con la simulación activa, cuando una página es expulsada del buffer pool real (VPSIZE), su bloque de control no se descarta. En su lugar, se mueve a la cadena simulada (SPSIZE).
- Este descriptor reside en la cadena simulada, envejeciendo tal como lo haría en un buffer pool real más grande.
- Si una aplicación solicita esa página mientras su descriptor aún reside en la cadena simulada, el Db2 registra un «Acierto Simulado».
- En la realidad: Db2 tuvo que ir a disco a buscar la página (porque no estaba en el VPSIZE real).
- En la simulación: El sistema anota: «Si hubieras tenido esa memoria extra, te habrías ahorrado este viaje al disco».
Este mecanismo permite a Db2 cuantificar con precisión absoluta los I/O Evitables (Avoidable I/Os), ya que se basa en la carga de trabajo real y exacta que está ocurriendo en ese momento, no en proyecciones estadísticas.
El coste de CPU aproximado según la documentación es de alrededor del 1-2% por buffer pool simulado, mientras que el coste de memoria real es aproximadamente el 2% del tamaño de la memoria que se está simulando.
Limitaciones importantes
El Buffer Pool Simulator tiene varias restricciones que debes conocer:
- Solo simula aumentos de tamaño, no reducciones.
- No simula movimiento de objetos entre pools (no “what‑if mover este tablespace a BP1”).
- Requiere PGSTEAL = LRU para la simulación.
- El total VPSIZE + SPSIZE no puede superar ciertos límites internos ni la memoria real disponible en el LPAR.
Cómo activar una simulación paso a paso
1. Elegir el buffer pool candidato
Antes de tocar nada:
- Identifica el buffer pool con más E/S síncrona y tiempos de respuesta sensibles.
- Comprueba que esté usando PGSTEAL = LRU.
- Anota su VPSIZE actual y el tipo de páginas (4K, 8K, etc.).
2. Definir el escenario “what‑if”
Decide cuánto quieres simular. Un patrón prudente es empezar con un incremento del 20–30% del tamaño actual.
Ejemplo: si el BP1 tiene un VPSIZE de 100.000, puedes probar con SPSIZE 30.000.
Si los resultados que se obtengan al final muestran saturación, puedes aumentar a un 50% y luego un 100%.
3. Activar trazas de estadísticas
Para tener datos consistentes, necesitas activar estadísticas activas (IFCID 2) y/o la salida de comandos de monitorización.
-START TRACE(STAT) CLASS(1) IFCID(2)Nota: El IFCID 2 es el registro que contiene los datos del simulador. Sin esto, en el SMF no se verá nada, aunque el comando DISPLAY en tiempo real sí funcione.
4. Activación de la simulación
El siguiente paso es realizar un ALTER sobre el buffer pool que quieres simular:
-ALTER BUFFERPOOL(BP1) SPSIZE(30000)A tener en cuenta:
- SPSIZE > 0 es lo que activa la simulación.
- En la misma instrucción de ALTER se permite modificar el VPSIZE. Sin embargo, no pongas el VPSIZE a 0 mientras simulas; ya que eso desasigna el buffer pool real.
5. Dejar correr la carga de trabajo “real”
La simulación solo tiene sentido si el sistema recibe una carga representativa. Es recomendable esperar al menos 15-30 minutos para que el simulador llene sus estructuras de control.
Como recomendación:
- Duración mínima: De 1 a 3 horas aproximadamente de trabajo normal.
- Idealmente se debería realizar la simulación en alguna ventana con alta actividad (cierre de día, batch crítico, fin de mes, etc.).
- Es mejor no activar simulaciones masivas, sobretodo si existen problemas de rendimiento.
6. Consultar los resultados
Puedes obtener los resultados de dos formas típicas:
- Mediante estadísticas (IFCID 2) recogidas en el SMF.
- Con el comando:
-DISPLAY BUFFERPOOL(BP1) DETAILLa salida del comando incluye información del pool real y de la parte simulada.
Veamos un ejemplo de esta parte simulada y como interpretarla:
DSNB431I -DB2A SIMULATED BUFFER POOL SIZE = 50000 BUFFERS -
ALLOCATED = 50000
IN-USE = 34999 HIGH IN-USE = 35000
SEQ-IN-USE = 30469 HIGH SEQ-IN-USE = 34978 La salida anterior muestra que si se asignaran 50.000 buffers extra, solo se utilizarían 35.000, por lo que este puede ser un buen numero en el que incrementar tu VPSIZE real.
Vamos a analizar la siguiente parte de la salida:
DSNB432I -DB2A SIMULATED BUFFER POOL ACTIVITY -
AVOIDABLE READ I/O -
SYNC FROM DASD (R) =8425678
SYNC FROM DASD (S) =102357
ASYNC FROM DASD =1184257
SYNC FROM GBP (R) =894062
SYNC FROM GBP (S) =2747
ASYNC FROM GBP = 53212
PAGES MOVED INTO SIMULATED BUFFER POOL =12257444
TOTAL AVOIDABLE SYNC I/O DELAY =4275760 MILLISECONDS Entre los campos más interesantes de esta sección simulada encontrarás métricas como:
- PAGES MOVED INTO SIMULATED BUFFER POOL: páginas que “habrían” residido en el pool simulado.
- AVOIDABLE READ I/O:
- SYNC READ I/O (R): lecturas síncronas aleatorias que no se habrían producido.
- SYNC READ I/O (S): lecturas síncronas secuenciales que no se habrían producido.
- ASYNC READ I/O: lecturas asíncronas (prefetch) que se habrían evitado.
- TOTAL AVOIDABLE SYNC I/O DELAY: milisegundos de espera de I/O síncrona que el simulador estima que habrías ahorrado.
7. Detener la simulación
No olvides dejarte simulaciones corriendo indefinidamente en producción sin razón, ya que consumen memoria real y CPU innecesariamente.
Para detener la simulación, basta con poner a 0 el valor del SPSIZE:
-ALTER BUFFERPOOL(BP1) SPSIZE(0)Mejores prácticas y errores típicos
Buenas prácticas
- Empezar con SPSIZE moderado (≈20–30% de VPSIZE) y subir solo si el beneficio es claro.
- Ejecutar la simulación en ventanas de carga representativa (mejor en horario de alta actividad que no solo en “horas valle”).
- Ajustar SPSEQT si la carga tiene mucho acceso secuencial; un mal valor puede distorsionar resultados.
- Documentar cada simulación realizada: parámetros usados, fechas y conclusiones.
- Para un análisis completo en un Data Sharing, se debe ejecutar la simulación a la misma vez en todos los miembros Db2 del grupo. En este caso, no olvides revisar también las métricas relacionadas con GBP.
- En un Data Sharing, es recomendable optimizar en cada miembro el pool local (por ejemplo, si se decide aumentar de tamaño el BP0, es recomendable indicar el mismo valor para este buffer pool en cada miembro del Sysplex).
Errores habituales
- Olvidar desactivar la simulación:
- Asumir que “más memoria siempre es mejor” y no buscar el punto de rendimientos decrecientes.
- Usar solo el “buffer hit ratio” como indicador, ignorando métricas de I/O real.
- No validar que la LPAR tenga memoria real suficiente para soportar el tamaño que estás planteando en producción.
Referencias
- Buffer pool simulation – IBM
- Performing buffer pool simulation
- Db2 13 – Messages – DSNB508I – IBM
- Buffer pool simulation results