SQL Server se vuelve más lento con el tiempo hasta que tenemos que reiniciarlo

Tenemos una base de datos con una carga de trabajo mixta OLAP / OLTP. Las consultas son bastante ad-hoc y se crean dinámicamente en el servidor de aplicaciones de nivel medio. Cuando iniciamos el servidor, el rendimiento es bastante aceptable, pero el consumo de memoria aumenta cada vez más hasta que se agota toda la memoria disponible (30 GB). Después de eso, el sistema se vuelve más y más lento.

Los comandos como Dbcc freeproccacheno tienen efecto.

No hay muchas transacciones select * from sys.dm_tran_session_transactions(no más que cuando el sistema está bien), algunas veces esta lista está vacía.

El primer resultado de dbcc memorystatuses

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

Un reinicio de SQL Server resuelve el problema por un tiempo.

1. ¿Qué causa este comportamiento? ¿Cómo se puede evitar?
2. Si una solución real para la causa es demasiado difícil, ¿hay un comando que obligue a SQL Server a liberar toda la memoria sin un reinicio completo de DBMS?

El servidor se ejecuta en hardware dedicado (no en una VM). Teníamos algunos trabajos programados, pero los deshabilitamos por un tiempo, sin cambios. Hay otras aplicaciones de nivel medio que se ejecutan en el mismo servidor, pero no usan más de 2 GB de memoria, CPU insignificante y casi no E / S. Reiniciamos todas esas aplicaciones sin cambios.

Sugeriría recopilar métricas de rendimiento en este servidor, para que pueda eliminar las conjeturas de la resolución de este tipo de problemas. Consulte este artículo para obtener una guía más completa si no sabe por dónde empezar con esto.

En particular, verificaría los contadores de rendimiento Memory\Available MBytesy Paging File(_Total)\% Usageporque usted dijo que los problemas solo comienzan a ocurrir cuando el grupo de búferes está lleno. Los números que obtiene de estos contadores pueden indicar que la configuración de memoria máxima del servidor debe ajustarse (hacia arriba o hacia abajo) para la cantidad de memoria física asignada al servidor. Como mencioné aquí , no recomiendo basar la configuración de memoria máxima en la cantidad de memoria física, excepto como una suposición educada para un punto de partida . Siempre mida el resultado y ajústelo desde allí.

Si la cantidad de memoria libre es demasiado baja (<500), o el uso del archivo de página es superior a cero , esto puede indicar que la instancia de SQL Server se ha comprometido en exceso: en SQL Server 2008 R2, la configuración de memoria máxima del servidor solo controla el tamaño de la agrupación de almacenamiento intermedio , y no otro uso de memoria como el caché del plan. SQL Server tampoco se preocupa por otras aplicaciones que pueda tener en ejecución en el sistema. Este uso adicional de memoria puede ejercer presión sobre la memoria de Windows, o de otras aplicaciones, lo que puede provocar el intercambio de discos. Esto es algo que desea evitar a toda costa, especialmente si el archivo de página existe en un volumen respaldado por un simple espejo RAID 1. Mi sensación es que este es el problema, y ​​retroceder la configuración de memoria máxima del servidor debería solucionar el problema.

Si la cantidad de memoria libre es alta (> 1000) y el uso del archivo de página es cero, probablemente pueda aumentar ligeramente la memoria máxima del servidor (en incrementos de 256 MB) para maximizar el uso de la memoria del servidor. Sin embargo, lo más probable es que esto no resuelva el problema y tendrá que buscar en otro lado, probablemente en los contadores de disco físico y la expectativa de vida útil de la página del grupo de búferes. Si las consultas están agotando el grupo de búferes, no hay nada que pueda hacer excepto mejorar el rendimiento del disco, aumentar la cantidad de memoria física disponible para el servidor para que todas las páginas de datos puedan caber en la memoria a la vez o modificar la base de datos para no ocupar tanto espacio físico (tal vez mediante el uso de compresión de fila o página, o mediante la reconstrucción de índices con un mayor FILLFACTOR).

He publicado un artículo sobre este tema aquí que profundiza más sobre este problema y cómo resolverlo.

En general, la tendencia a la lentitud en el tiempo debería ser inversa, ya que a medida que las páginas de las bases de datos se mueven a la memoria caché, el rendimiento debería mejorar (la esperanza de vida de la página y la proporción de aciertos del búfer aumentan con el tiempo), ¿ha configurado su memoria máxima en (total_physical_mem - 2GB)?

Parece que un par de sus consultas están causando que el Servidor SQL salga y pague muchas cosas. Puede probar Resource Governor para limitar el consumo de memoria de las consultas grandes y medianas, de modo que las consultas de la aplicación siempre tengan suficiente búfer disponible.