La Memoria y los Discos Parte I

Sin duda alguna, uno de los recursos que más puede impactar el desempeño de cualquier motor de base de datos es el subsistema de almacenamiento, el cual es el actor principal en operaciones críticas como el páginamiento (paging), el escribir a la bitácora (log file) o escribir y leer de la base de datos temporal (tempdb).

Hoy en día, las bases de datos son tan grandes que no es posible cargarlas todas a memoria por lo que SQL Server carga y descarga grupos o conjuntos de páginas de disco a memoria constantemente. La intensidad de ésta actividad tiene un efecto directo en el desempeño del subsistema de discos y es directamente proporcional al volúmen de datos solictados por las consultas (queries). Por su parte, el volúmen varía en función de los planes de ejecución seleccionados por el optimizador y la configuración del motor de la base de datos.

En otras palabras, el desempeño del subsistema de discos está íntimamente relacionado con el volúmen de datos requerido por las consultas y a su vez dicho volúmen se vé influenciado por la configuración del motor y los planes de ejecución de consultas seleccionados por el optimizador.

En lo que se refiere a la configuración del motor, el recurso fundamental a considerar es la memoria ya que si el volúmen es insuficiente se incurrirá en una mayor actividad en los discos.

Por ejemplo, SQL Server utiliza la memoria para procesar todas las consultas. Cuándo las páginas requeridas no se encuentran en memoria, el motor hace campo para ellas seleccionando un conjunto de páginas y descargándo su contenido a los discos. Una vez hecho esto, lee los discos de nuevo obteniendo el contenido de páginas que necesita y lo pone en el conjunto de páginas cuyo contenido fué recientemente descargado. Como se puede obsevar, cuando la memoria escasea SQL Server utiliza más el sistema de discos y descarga de la memoria páginas frecuentemente accesadas con el fin de hacer campo para otras páginas que también necesita.

La pregunta natural entonces es, y cómo sé si el servidor tiene memoria suficiente? Para empezar a contestar esa pregunta podemos utilizar el Monitor de Desempeño de Windows (Performance Monitor) el cual ofrece varios contadores útiles para detectar indicios de problemas de memoria:

SQL Server: Buffer Manager – Page Life Expectancy: Este contador arroja segundos y nos dice el tiempo promedio que pasan las páginas de datos en la memoria de SQL Server. Aunque es normal que este contador fluctúe durante períodos de alta actividad, en promedio debemos ver valores que excedan los 500 segundos, de lo contrario habrá que investigar más a fondo.

SQL Server: Buffer Manager – Buffer Cache Hit Ratio: Este contador indica el porcentaje de tiempo en que las páginas requeridas por las consultas (queries) son servidas desde la memoria en lugar de los discos. Entre más alto el porcentaje, mejor. Como guía general, se considera aceptable si se obsevan valores del 95% o más. Si los valores observados son menores, entoces puede haber problemas y un buen primer paso sería analizar los métodos de acceso para determinar si existe un alto porcentaje de escaneo completo de tablas (Full Table Scans), lo cual podría atribuirse a la falta de índices correctos.

SQL Server: Access Methods – Full Scans/Sec -Indica el número de escaneos completos que está realizando el motor. Con este contador no existen números o niveles buenos o malos, si no más bien hay que analizar tendencias y si es a la alza pudiera significar que el optimizador ha dejado de utilizar ciertos índices o que se han introducido consultas (queries) que no habían sido utilizadas antes.

Otra herramienta es el comando DBCC MEMORYSTATUS el cuál es frecuentemente utilizado por soporte técnico y muestra un panorama general sobre la distribución actual y el uso de la memoria.

This entry was posted in Optimización. Bookmark the permalink.

Leave a Reply