¿Por qué se requieren reinicios periódicos para que mi instancia funcione bien?

Tenemos un servidor de base de datos de producción en SQL 2005. Todo funciona normalmente durante un tiempo, pero después de un par de semanas vemos una caída notable en el rendimiento. Solo reiniciar SQL Server hace que el rendimiento vuelva a la normalidad.

Algunos antecedentes:

• Ejecución de más de 1200 bases de datos (en su mayoría de un solo inquilino, algunas de múltiples inquilinos). Antes de que alguien dé una conferencia sobre el cambio a solo multiinquilino, hay razones válidas para mantener esta estructura ......
• RAM es de 16 GB. Después de reiniciar, SQL Server no tarda demasiado en volver a usar 15 GB.
• Las conexiones de base de datos activas son aproximadamente 80 conexiones, lo que creemos que es bastante saludable teniendo en cuenta que hay un grupo de conexiones por servidor web por proceso, por lo que no tenemos un problema de pérdida de conexión.

Hemos intentado varias cosas en horas no pico: - Ejecute DBCC DROPCLEANBUFFERS (con un PUNTO DE CONTROL) para borrar la memoria caché de datos. No tiene ningún efecto, ni borra el uso de RAM). - Ejecute FREEPROCCACHE y FREESYSTEMCACHE para borrar los planes de consulta y el caché de proceso almacenado. Sin efecto.

Obviamente, reiniciar SQL Server no es ideal en un entorno de producción activo. Nos falta algo ¿A alguien más le pasa esto?

ACTUALIZACIÓN: 28 de abril de 2012 Sigue luchando contra este problema. Bajé la memoria para SQL Server a 10 GB, solo para descartar cualquier disputa con el sistema operativo. Me estoy acercando a reducirlo, pero necesito ayuda de mi próximo paso.

Esto es lo que encontré, después de reiniciar SQL Server, el archivo de página oscila entre 12.3 GB y 12.5 GB. Permanecerá así durante días. Los subprocesos totales del servidor pasarán entre 850 y 930, también estables y consistentes durante días (sqlserver está constantemente entre 55 y 85 de los que dependen del tráfico).

Entonces, hay "un evento". No tengo idea de cuál es el evento, no puedo verlo en los registros, y no puedo ver nada consistente en el día de la semana o el momento en que sucede, pero todo el archivo de paginación repentino salta a 14.1 o 14.2 GB, y los hilos saltan a entre 1750 y 1785.

Al comprobar el rendimiento cuando esto sucede, más de 900 de esos hilos son sqlserver. Así que voy a sp_who2 para ver de dónde provienen estos subprocesos ... y solo hay 80 o más conexiones db usadas.

Entonces ... ¿alguien tiene alguna idea de cómo puedo ubicar dónde están el resto de estos 900 subprocesos en el servidor SQL y qué están haciendo?

ACTUALIZACIÓN: junio-01-2012 Todavía luchando contra el problema. Para cualquiera que lea esto aún, el problema con los hilos saltando ha sido resuelto. Esto fue causado por el software de respaldo ComVault autodatado. Estaba creando un hilo tratando de hacer una copia de seguridad de las bases de datos que ya no estaban allí (estaba manteniendo una lista de bases de datos anteriores) en lugar de simplemente hacer una copia de seguridad de las bases de datos actuales.

Pero, el problema aún persiste, y tenemos que reiniciar cada semana, más o menos unos días. Trabajando con el equipo de Rackspace para ver si pueden arrojar algo de luz.

Dices que todo está bien, luego de un par de semanas, el rendimiento cae. (Por lo general, las personas afirman que el rendimiento cae rápidamente, o en momentos específicos, o en intervalos aparentemente aleatorios. Eso podría significar un mal rendimiento de E / S o tormentas de bloqueo o consultas intensivas en CPU que se ejecutan en momentos extraños, o un trabajo programado pesado o la falta de indexación o estadísticas incorrectas que causan consultas intensivas en CPU o lecturas de disco u otras cosas.) Semanas es inusual.

Mi hipótesis es que otra aplicación en su servidor está perdiendo memoria. He visto esto con software de virus (el villano de software de servidor favorito de todos los DBA) y software de monitoreo de terceros. Verificaría dos veces el uso de memoria de SQL Server, con el tiempo, y también tomaría todo el uso de memoria de todas las otras aplicaciones en la caja. Si tiene límites estrictos establecidos en el uso de memoria de SQL Server y lo ha configurado para que no permita la paginación, podrían ser otras aplicaciones que se están paginando y consumiendo la capacidad de E / S.

No es difícil de buscar. Si aún no mantiene las métricas en el servidor, simplemente iniciaría Perfmon y haría que tomara una muestra cada 30 o 60 minutos. Después de unos días, es posible que vea el uso de memoria de otras aplicaciones progresivamente.

¿Hay mensajes de error en el registro de SQL Server que indiquen que "partes significativas del servidor SQL se han paginado"? Eso también sería una gran pista.

Permítame felicitarlo por poder ejecutar 1200 DB en una sola instancia de servidor SQL con solo 16 GB de RAM y tener solo este tipo de problemas después de un par de semanas de funcionamiento sin problemas. Bonita historia para contar en el capítulo local de PASS.

Ahora para solucionar problemas: su RAM es de 16 GB tanto para el SQL como para el sistema operativo. Supongo que su configuración de memoria máxima es de 15 GB o máximo. Esto podría estar causando que el grupo de búferes use toda la memoria y ahogue el sistema operativo. Está diciendo que limpiar el grupo de búferes y las memorias caché no muestran diferencias, además su PLE está por encima de 300. Esto atestigua contra los cuellos de botella de memoria. ¿Cómo está la CPU y la E / S en el servidor (especificaciones / estadísticas)?

Ejecute select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidy cuáles son las contenciones de recursos que ve (wait_type, wait_time, last_wait_type, wait_resource).

¿1200 bases de datos, un sistema operativo y posiblemente otras cosas? Sí, creo que el servidor en sí necesitará más de 1 gb de ram para funcionar, especialmente teniendo en cuenta que, si configura 15 gb como configuración de memoria máxima de SQL Server, todavía necesita memoria adicional fuera de esos 15 gb para subprocesos.

Bajaría SQL Server a 14 gb para darle al servidor un poco más de espacio para respirar.

Además, un ejemplo dado en "Solución de problemas internos y profesionales de SQL Server 2008" para asignaciones de memoria en un sistema SQL Server 2008 x64 con una utilidad de respaldo de terceros con 16 GB de RAM:

• 2 GB para Windows
• 1 GB para hilos de trabajo
• 1 GB para AMP, etc.
• 1 GB para el programa de respaldo
• 11 GB para SQL Server

En el libro muestra cómo determinar el número máximo de hilos que puede tener, y cómo calcular cuánta memoria ocuparán. Ejecute esto (cambie el tipo de servidor para que coincida con su servidor) para determinar cuánta memoria necesitarán sus subprocesos.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Si la memoria de la base de datos se distribuye uniformemente en todas las bases de datos, solo tiene 12.8 Megas para cada base de datos (15 * 1024) /1200=12.8. Necesitas más memoria.

Debe investigar por qué el rendimiento se está ralentizando. ¿Estás viendo bloqueo, bloqueo, etc.? ¿Cómo son las estadísticas de espera?

Los comandos DBCC solo van a borrar los búferes de memoria, no van a liberar la memoria al sistema operativo.

¿Sabes que SQL Server está consumiendo realmente la memoria? Sugeriría buscar configurar la sesión de Perfmon o comenzar a recopilar información del DMV después de un reinicio para averiguar qué está haciendo y trabajando SQL Server. También tenga en cuenta si los usuarios están haciendo más trabajo de lo normal durante el tiempo de recolección (como el procesamiento de fin de mes, etc.). ¿Está ejecutando SSRS, SSIS o SSAS en el mismo servidor?

Tiene 1200 bases de datos en el sistema, ¿cuál es el DB de mayor tamaño que tiene?