Hola usuario de nuestro sitio web, tenemos la solución a lo que buscabas, desplázate y la encontrarás un poco más abajo.
Solución:
Están sucediendo muchas cosas aquí, y la mayor parte es bastante amplia y vaga.
-
2008R2 RTM salió el 21 de abril de 2010. Está totalmente fuera de soporte. Querrá priorizar la obtención del último Service Pack, que salió hace aproximadamente 3 años. De esa manera, estará cubierto si tiene un error extraño o algo así. Dirígete aquí para averiguar qué necesitas descargar.
-
Dado que agregó CPU virtuales (de 1 a 4) y no cambió ninguna configuración, sus consultas ahora pueden ir en paralelo. Sé que esto suena a 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.
-
Averigüe a qué está esperando su servidor. Un proyecto de código abierto en el que trabajo proporciona scripts gratuitos para ayudarlo a medir su SQL Server. Dirígete aquí si quieres probarlos.
Querrá tomar sp_BlitzFirst para ver las estadísticas de espera de su servidor. Puede ejecutarlo de dos maneras.
Esto le mostrará qué ha estado esperando su servidor 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 averigüe 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 ves esperando CXPACKET, eso significa que sus consultas van en paralelo, y tal vez se pisoteen entre sí. Si llega a esto, probablemente desee considerar aumentar el Umbral de costo para el paralelismo hasta 50, y tal vez reducir el MAXDOP a 2.
Después de este paso es cuando desea usar algo como sp_WhoIsActive o sp_BlitzWho (este último está en el repositorio de GitHub de antes) para comenzar a capturar planes de consulta. Aparte de las estadísticas de espera, son una de las cosas más importantes que puede observar para averiguar qué está fallando.
También puede consultar este artículo de Jonathan Kehayias sobre los contadores VMWare para consultar en relación con SQL Server.
Actualizar
Revisando las estadísticas de espera y vaya si son raras. Definitivamente pasa algo con las CPU. Su servidor está mayormente aburrido, pero cuando las cosas se calientan, las cosas se ponen mal. Intentaré desglosar esto fácilmente.
-
Estás golpeando un veneno, espera llamado
THREADPOOL. No tiene mucho, pero tiene sentido porque su servidor no está terriblemente activo. Explicaré por qué en un minuto. -
Tienes esperas promedio realmente largas
SOS_SCHEDULER_YIELDyCXPACKET. Estás en una máquina virtual, así que querrás asegurarte de que SQL Server tenga reservas o de que el cuadro no esté terriblemente suscrito en exceso. Un vecino ruidoso puede arruinarte el día aquí. También querrá asegurarse de que el servidor / invitado de VM / host de VM no se esté ejecutando en el modo de energía equilibrada. Esto hace que las CPU giren a velocidades innecesariamente bajas y no vuelvan a girar inmediatamente a la velocidad máxima. -
¿Cómo se relacionan? Con 4 CPU, tiene 512 subprocesos 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 subprocesos por rama paralela de una consulta paralela.
¿Qué va en paralelo? Probablemente todo. El umbral de costo predeterminado para el paralelismo es 5. Ese número se convirtió en el predeterminado en algún momento a finales de los 90 al trabajar en un escritorio que se veía así.
Por supuesto, 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án quedando sin esos subprocesos de trabajo. Cuando eso sucede, las consultas simplemente se quedan esperando a que los hilos se pongan en marcha. Ahí es también donde SOS_SCHEDULER_YIELD entra. Las consultas están saliendo de las CPU y no regresan durante mucho tiempo. No veo ninguna espera de bloqueo, por lo que lo más probable es que esté completamente atiborrado de esperas de paralelismo intraconsulta.
¿Qué puedes hacer?
- Asegúrese de que no haya nada en el modo de energía equilibrada
- Cambie MAXDOP a 2
- Cambiar el umbral de costo para el paralelismo a 50
- Siga el artículo de Jon K. anterior para validar el estado de la máquina virtual
- Utilice el script llamado
sp_BlitzIndexpara buscar cualquier solicitud de índice que falte.
Para una solución de problemas más completa, consulte el documento técnico que escribí para Google sobre el tamaño del hardware en la nube.
¡Espero que esto ayude!
¡Sí! He experimentado este tipo de situación en las máquinas virtuales de SQL Server en nuestra granja de servidores. Mire el tiempo de preparación de la CPU del host de la máquina virtual y los contadores del controlador del globo de memoria. TIEMPO DE PREPARACIÓN DE LA CPU: BLOG PARTE I y comprensión de VMware Ballooning Trabajar con mi administrador de sistemas fue key, pero no fue fácil …
Una cosa que no vi señalada es que agregar vCPU a una máquina virtual a menudo puede ralentizarla debido a la programación.
La idea básica es que si una máquina virtual tiene 4 vCPU, el hipervisor debe esperar a que haya 4 núcleos físicos disponibles para poder programar todas las vCPU, incluso si 3 de ellas están inactivas.
Si no tiene muchos núcleos en su host y sus otras cargas de trabajo están ocupadas, esto puede resultar en una espera adicional y una caída significativa en el rendimiento.
En VMware ESXi puede verlo en los gráficos avanzados a través de CPU Ready.
Aquí hay uno de los muchos artículos con un ejemplo del mundo real de que esto sucedió y cómo se diagnosticó.
Agregar más RAM también puede causar una caída repentina del rendimiento si la asignación de RAM de la VM es mayor que la de un nodo NUMA.
Además, la configuración de sus vCPU (vSockets frente a vCores) puede afectar a algunas aplicaciones como el servidor SQL. Esto se debe a que el servidor SQL es consciente de NUMA (para evitar el mismo tipo de caída del rendimiento que abarca NUMA) y porque VMware puede presentar los nodos NUMA virtuales de manera diferente.
Esto se trata en una publicación de blog en el propio sitio de VMware.
Dicho esto, me alegra que resolviera los problemas con la ayuda de Erik, pero es posible que también desee examinar y considerar estas cosas.