Identificando un Problema de Memoria

Una de las tareas de un administrador de base de datos es el poder identificar la raíz de un problema de performance, en este artículo hablare de la memoria, pero es importante mencionar que aunque todo apunte a un problema de memoria, debe de analizarse el porque se esta requiriendo de tanta memoria en un equipo.

Muchas de estas veces es por falta de índices que como consecuencia en cada consulta se suben más datos a memoria de los que se requieren, otra causa puede ser un mal diseño en la base de datos o queries mal diseñados.

¿Como saber si tenemos un problema de memoria.?
Los cuellos de botella en la memoria de un servidor de Base de Datos se pude identificar cuando se esta generando demasiado paging, un alto consumo de memoria, un “buffer cache hit ratio” muy bajo  y un alto volumen de lecturas y escrituras en el disco. Todo esto es posible medirlo con los contadores del sistema operativo y de SQL Server que se muestran a continuación:

• Memory: Pages/Sec
• Memory: Available Bytes
• SQL Server: Buffer Manager: Buffer Cache Hit Ratio
• Physical Disk: Disk Reads/sec
• Physical Disk: Disk Writes/sec

Memory: Pages/Sec
Este contador nos indica el número de páginas por segundo que son movidas de memoria RAM a memoria virtual en el disco duro. Cuando tenemos lecturas muy grandes de este contador, indica que nuestra memoria se encuentra bajo mucho stress. Entre mayor paging tengamos, se genera más IO en el disco. OJO el paging es normal en un servidor pero debemos tener en niveles aceptables, por lo que no hay que intentar eliminarlo.
Si asumimos que en nuestro servidor de Base de Datos, lo único que se esta ejecutando es SQL Server y no una aplicación extra el valor promedio que debemos tener debe encontrarse entre 0 y 20 paginas por segundo, picos mayores a 20 es normal, pero si nos encontramos constantemente en un valor mayor a 20 paginas por segundo, entonces estamos teniendo un cuello de botella. Con esto podemos concluir que entre más RAM tenga el servidor, menor será el paging que se presente.
Si no tuviéramos solamente SQL Server ejecutándose en nuestro servidor de base de datos, la manera de identificar que en realidad es SQL Server y no otro proceso el causante del paging, se debe de monitorear el contador Process: Page Faults/sec para el proceso de SQL Server.

Memory: Available Bytes
Este contador mide  la cantidad de memoria disponible en un servidor. El valor promedio de este contador debe ser mayor a los 5MB, de no ser así se puede estar presentando problemas de desempeño en el equipo por falta de memoria.

SQL Server: Buffer Manager: Buffer Cache Hit Ratio
Este contador indica que tan frecuente SQL Server 2005 accede el buffer en lugar del disco duro para extraer datos. Si nuestro servidor tiene una aplicación OLTP, este valor puede exceder el 90%, el valor ideal es 99%. Un buffer cache hit ratio menos al 90% generalmente indica que la RAM esta teniendo demasiada presión y que esta degradando el desempeño de SQL Server. Si las lecturas se encuentran entre el 90% y 99%, generalmente no se tienen problemas pero el agregarle más memoria el desempeño de SQL Server mejoraría.
Si nuestro servidor se encuentra ejecutando aluna aplicación OLAP, el valor de este contador puede ser menor al 90% debido a la forma de trabajar de este tipo de aplicaciones. Debido a esto se debe ser muy cauteloso al momento de realizar un diagnostico con este contador.

Physical Disk: Disk Reads/sec y Physical Disk: Disk Writes/sec
Estos contadores son un poco difíciles de interpretar, porque los límites de transferencia de los discos dependen del hardware instalado en el servidor, por ejemplo un disco SCSI puede manejar entre 50 y 70 I/O por segundo. Para poder interpretar este contador es necesario ayudarse de los otros mencionados. Lo que ayuda mucho en estos casos es tener un baseline con el cual se pueda comparar al momento de tener sospechas que tenemos un cuello de botella en la memoria.