Están sucediendo muchas cosas aquí, y la mayoría es bastante amplia y vaga.
2008R2 RTM salió el 21 de abril de 2010. Está totalmente fuera de soporte. Querrás priorizar el obtener el último Service Pack, que salió hace solo 3 años. De esa manera, estarás cubierto si te encuentras con un error extraño o algo así. Dirígete aquí para descubrir qué necesitas descargar.
Como agregó vCPU (de 1 a 4) y no cambió ninguna configuración, sus consultas ahora pueden ir en paralelo. Sé que parece que todos serán más rápidos, ¡pero espera!
Es posible que haya agregado RAM, pero es posible que no haya cambiado la memoria máxima del servidor para que su servidor pueda aprovecharla.
Averigua qué está esperando tu servidor. Un proyecto de código abierto en el que trabajo proporciona scripts gratuitos para ayudarlo a medir su SQL Server. Pásate por aquí si quieres intentarlo.
Querrás obtener sp_BlitzFirst para ver las estadísticas de espera de tu servidor. Puedes ejecutarlo de dos maneras.
Esto le mostrará lo que su servidor ha estado esperando desde que se inició.
EXEC dbo.sp_BlitzFirst @SinceStartup = 1;
Esto le mostrará qué consultas están esperando ahora, durante una ventana de 30 segundos.
EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;
Una vez que descubra qué consultas están esperando (hay un montón de cosas escritas sobre las estadísticas de espera), puede comenzar a hacer cambios para tener las cosas bajo control.
Si los ve esperando CXPACKET
, eso significa que sus consultas van paralelas y tal vez se pisotean entre sí. Si logra esto, probablemente desee considerar aumentar el Umbral de costo para paralelismo hasta 50, y tal vez bajar MAXDOP a 2.
Después de este paso es cuando desea usar algo como sp_WhoIsActive o sp_BlitzWho (este último se encuentra en el repositorio de GitHub de antes) para comenzar a capturar planes de consulta. Además de las estadísticas de espera, son una de las cosas más importantes que puedes ver para descubrir qué está mal.
También puede consultar este artículo de Jonathan Kehayias sobre VMWare Counters para consultar en relación con SQL Server.
Actualizar
Revisando las estadísticas de espera y chico, son raros Definitivamente hay algo con las CPU. Su servidor está más que nada aburrido, pero cuando las cosas se calientan, las cosas se ponen mal. Intentaré analizar esto fácilmente.
Estás golpeando una llamada de veneno llamada THREADPOOL
. No tiene una tonelada, pero eso tiene sentido porque su servidor no está terriblemente activo. Explicaré por qué en un minuto.
Tienes un promedio de espera muy largo SOS_SCHEDULER_YIELD
y CXPACKET
. Estás en una máquina virtual, por lo que querrás asegurarte de que el servidor SQL tenga reservas o que la caja no esté demasiado suscrita. Un vecino ruidoso realmente puede arruinar tu día aquí. También querrá asegurarse de que el servidor / invitado de VM / host de VM no se esté ejecutando en modo de energía equilibrada. Esto hace que sus CPU bajen a velocidades innecesariamente bajas, y no vuelven inmediatamente a la velocidad máxima.
¿Cómo se unen? Con 4 CPU tiene 512 hilos de trabajo. Tenga en cuenta que tenía la misma cantidad con una sola CPU, pero ahora que sus consultas pueden ir en paralelo, pueden consumir muchos más subprocesos de trabajo. En su caso, 4 hilos por rama paralela de una consulta paralela.
¿Qué va paralelo? Lo más probable es que todo. El umbral de costo predeterminado para el paralelismo es 5. Ese número se convirtió en el predeterminado en algún momento a fines de los años 90 trabajando en un escritorio que se parecía a esto .
De acuerdo, su hardware es más pequeño que la mayoría de las computadoras portátiles, pero todavía está un poco por delante de eso.
Cuando se inician muchas consultas paralelas, se está quedando sin esos subprocesos de trabajo. Cuando eso sucede, las consultas simplemente se quedan esperando que los hilos se pongan en marcha. Ahí también es donde SOS_SCHEDULER_YIELD
entra. Las consultas están saliendo de las CPU y no vuelven a funcionar durante mucho tiempo. No veo ninguna espera de bloqueo, por lo que lo más probable es que esté lleno de esperas de paralelismo intraconsulta.
¿Qué puedes hacer?
- Asegúrese de que nada esté en modo de energía equilibrada
- Cambiar MAXDOP a 2
- Cambiar el umbral de costo para paralelismo a 50
- Siga el artículo anterior de Jon K. para validar el estado de VM
- Use el script llamado
sp_BlitzIndex
para buscar cualquier solicitud de índice faltante.
Para una resolución de problemas más exhaustiva, consulte el documento técnico que escribí para Google sobre el tamaño del hardware en la nube.
¡Espero que esto ayude!