En SQL Server, la memoria caché del búfer es la memoria que le permite consultar rápidamente los datos a los que se accede con frecuencia. Cuando los datos se escriben o se leen en una base de datos de SQL Server, el administrador de búfer los copia en la memoria caché del búfer (también conocido como grupo de búfer). Cuando está lleno, las páginas de datos más antiguas o menos utilizadas se mueven al disco duro.
¿Por qué necesito monitorear el caché del búfer?
El uso de la memoria puede tener un impacto significativo en el rendimiento. Cuando no hay suficiente memoria, las páginas de datos se eliminan con frecuencia de la memoria caché del búfer. Esto ralentiza las consultas porque SQL Server tiene que ir al disco para encontrar la página de datos, restaurarla en el caché del búfer y luego leer la página antes de que pueda devolver los resultados de la consulta.
Hay muchas razones por las que las consultas comienzan a ejecutarse lentamente. Pero si desea descartar problemas de memoria, mire lo que sucede dentro del caché del búfer. Un vistazo a su interior identificará qué base de datos, tabla o índice está acaparando la memoria y ejerciendo presión sobre el búfer.
Para ver qué base de datos consume más memoria, utilice la consulta:
SELECT CASE database_id WHEN 32767 THEN 'ResourceDb' ELSE db_name(database_id) END AS database_name, COUNT(1)/128 AS megabytes_in_cache FROM sys.dm_os_buffer_descriptors GROUP BY DB_NAME(database_id) ,database_id ORDER BY megabytes_in_cache DESC;
Para identificar la tabla o el índice que consume más memoria, ejecute esta consulta en la base de datos que desea inspeccionar:
SELECT COUNT(1)/128 AS megabytes_in_cache ,name ,index_id FROM sys.dm_os_buffer_descriptors AS bd INNER JOIN ( SELECT object_name(object_id) AS name ,index_id ,allocation_unit_id FROM sys.allocation_units AS au INNER JOIN sys.partitions AS p ON au.container_id = p.hobt_id AND (au.type = 1 OR au.type = 3) UNION ALL SELECT object_name(object_id) AS name ,index_id, allocation_unit_id FROM sys.allocation_units AS au INNER JOIN sys.partitions AS p ON au.container_id = p.partition_id AND au.type = 2 ) AS obj ON bd.allocation_unit_id = obj.allocation_unit_id WHERE database_id = DB_ID() GROUP BY name, index_id ORDER BY megabytes_in_cache DESC;
Gestionar la memoria con métricas
Si bien es útil verificar el uso excesivo de la memoria en las bases de datos y los índices, el seguimiento de las métricas de la memoria caché del búfer es realmente la mejor manera de identificar y resolver los problemas de rendimiento causados por la presión interna sobre la memoria.
Estas son las cinco métricas principales que se deben monitorear para mejorar los problemas de rendimiento relacionados con la memoria:
1. Proporción de aciertos de caché de búfer
- Esta métrica muestra cómo SQL Server utiliza la memoria caché del búfer
- La proporción de aciertos identifica el porcentaje de solicitudes de página que fueron completadas por páginas de datos del caché del búfer frente a todas las solicitudes de páginas de datos
- Las páginas que no se encuentran en la memoria caché del búfer se leen del disco, lo que es mucho más lento
- La proporción ideal de caché de búfer es 100 (es decir, SQL Server lee todas las páginas del caché de búfer y ninguna del disco)
- El valor de caché de búfer recomendado es superior a 90
2. Esperanza de vida de la página (PLE)
- La esperanza de vida de la página mide cuánto tiempo (en segundos) permanece una página de datos en la memoria caché del búfer
- Cuanto más largo sea el PLE, mayores serán las posibilidades de que SQL Server lea las páginas del caché del búfer y no tenga que ir al disco
- Si no hay suficiente memoria, las páginas de datos se eliminan de la memoria caché del búfer con más frecuencia para liberar espacio para nuevas páginas
- Históricamente, cuando los sistemas tenían mucha menos memoria que ahora, un valor PLE "normal" era de 300 segundos
- Hoy en día, se usa una fórmula para determinar el PLE "bueno":expectativa de vida de la página =300 segundos por cada 4 GB de RAM en su servidor
- El PLE debería permanecer estable si se monitorea a lo largo del tiempo
- Las disminuciones rápidas y frecuentes indican problemas de memoria
- Una caída de más del 50 % debe investigarse de inmediato
3. Lecturas de página/s (nivel de servidor)
- Esta métrica muestra cuántas lecturas físicas (es decir, lecturas del disco) se produjeron en un segundo en todas las bases de datos de una instancia
- Las lecturas físicas son costosas y lentas
- Reduzca las lecturas físicas mediante el uso de una caché de datos más grande, índices inteligentes y consultas más eficientes, o cambiando el diseño de la base de datos
- El valor recomendado es inferior a 90
- Un valor superior a 90 indica memoria insuficiente y problemas de indexación
4. Escrituras de página/seg
- Esta métrica muestra la cantidad de veces que las páginas se escribieron en el disco en el nivel del servidor en un segundo
- El valor recomendado es inferior a 90
5. Entrada de páginas/seg. y salida de páginas/seg. (contadores de memoria)
- La entrada de páginas por segundo es el número de páginas que se traen del disco cada segundo
- La salida de páginas por segundo es el número de páginas escritas en el disco cada segundo para hacer espacio en la memoria caché del búfer
- Páginas/seg es la suma de páginas de entrada/seg y páginas de salida/seg
- Si el valor de páginas/segundo es constantemente superior a 50, se necesita una investigación adicional
Una caché de búfer en buen estado es un componente importante para optimizar la velocidad de consulta de SQL Server. Aunque los problemas de memoria son solo uno de varios factores que pueden ralentizar las respuestas a las consultas, son bastante fáciles de identificar y resolver. El seguimiento de estas cinco métricas clave puede ayudarlo a mantener las páginas de datos en el grupo de búfer por más tiempo para que SQL Server no tenga que perder tiempo buscando en el disco antes de devolver los resultados de la consulta.
