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.