En SQL Server 2014 aparece una nueva funcionalidad denominada Buffer pool extension que permite ampliar la capacidad de nuestro buffer pool mediante el uso de discos rápidos. Habitualmente situaremos esta extensión en discos SSD o en unidades que tengan garantizado un rendimiento muy elevado comparado con los discos que almacenan nuestros ficheros de datos. Esta característica extiende el buffer pool para almacenar únicamente páginas limpias, permitiéndonos mantener un working set mayor entre la memoria y el SSD. Esto reducirá las operaciones aleatorias que se realicen sobre los ficheros de datos, mejorando el rendimiento.

En el siguiente gráfico podemos apreciar donde se sitúa esta caché de nivel 2 (L2) y cómo el acceso es transparente desde el punto de vista del storage engine:

 

En concreto el diseño utilizado en SQL Server 2014 es el denominado Clean-Write (CW) Design en el whitepaper, donde las páginas almacenadas en el SSD son siempre páginas limpias.

Como en muchas caches, el dimensionamiento de éstas para que el rendimiento sea óptimo es importante. En la jerarquía de acceso (dentro de SQL Server, dejando de lado las cachés de los procesadores) tendríamos la L1 (memoria RAM), la L2 (buffer pool extension) y finalmente la L3 podría ser el disco magnético. El tamaño recomendado, aunque debería ser ajustado mediante pruebas, es de que la L2, la buffer pool extension, sea entre 4 y 8 veces mayor que la memoria. Por otra parte, se están reportando resultados pobres en sistemas que disponen de cantidades de memoria ya bastante significativas (>64GB) por lo que esta funcionalidad creemos que podría tener un mejor desempeño en entornos virtuales donde la cantidad de memoria asignable puede ser más reducida que en un entorno físico.

También debemos tener en cuenta que si tenemos disponible un precioso almacenamiento rápido SSD en el servidor podríamos sacarle un buen partido para tempdb o para logs de transacciones de bases de datos OLTP. Quizás no sea posible utilizarlo para datos o logs por ser almacenamiento local y nuestra instancia estar en failover cluster pero desde SQL Server 2012 si podemos usarlo para tempdb aunque estemos en una instancia en cluster. También podríamos utilizar este almacenamiento SSD para mantener las particiones o tablas más utilizadas por nuestra aplicación.Lo que quiero decir en definitiva es que si tenemos almacenamiento SSD el utilizarlo como buffer pool extension no nos ayudará a aliviar problemas de congestión en tempdb o latencias excesivas en el log de transacciones, ambos problemas con los que nos encontramos muy frecuentemente.

Para que esta funcionalidad pueda llegar a ser una funcionalidad realmente “killer” necesitamos que la implementación Lazy-Cleaning (LC)  realizada para el Whitepaper de Microsoft, ya probada sobre SQL Server 2008 R2, pueda ver la luz en algún momento. Con esta implementación el SSD se utilizaría como una caché write-back de forma que se pudieran realizar mucho más rápidamente las operaciones de escritura a la vez que el acceso a las páginas sucias se podría realizar directamente desde el SSD y no únicamente desde la memoria. También necesitaríamos una política de “envejecimiento” de las páginas, de reemplazo en la caché dinámica, basada en el uso, la frecuencia del acceso y el tipo de acceso (priorizando los accesos aleatorios al SSD respecto a los secuenciales). En definitiva estaríamos utilizando el SSD como una caché real para el acceso a disco en todos sus sentidos, mejorando de forma importante la capacidad de entrada/salida a disco 🙂

 

Como muestra de las ventajas que obtendríamos os muestro los dos siguientes gráficos que muestran el beneficio de la implementación LC (en gris) en TPC-C, TPC-E y TPC-H:

En conclusión, la versión actual de la buffer pool extension puede ser útil en escenarios muy muy específicos donde la cantidad de memoria disponible (o a la que podemos ampliar la máquina) es claramente insuficiente para mantener el working set necesario para nuestra carga (que puede llegar a ser de cientos de GB en escenarios DW). En estos casos veremos esperanzas de vida de páginas muy bajos y una actividad sobre los ficheros de datos elevada. En escenarios donde la memoria está correctamente dimensionada las mejoras que podemos obtener con esta característica no serían apreciables por lo que en cierta forma podemos ver esta funcionalidad como una especie de “parche” que podemos aplicar en casos especiales (máquinas virtuales con poca memoria, entornos con working sets muy amplios…).

 

Rubén Garrigós