Solución:
Apuesto a que ha configurado las CPU virtuales de manera que algunos de los nodos de la CPU y / o nodos de memoria estén fuera de línea.
Descargue sp_Blitz (descargo de responsabilidad: soy uno de los autores de ese script de código abierto gratuito) y ejecútelo:
sp_Blitz @CheckServerInfo = 1;
Busque advertencias acerca de que la CPU y / o los nodos de memoria estén fuera de línea. SQL Server Standard Edition solo ve los primeros 4 sockets de CPU, y es posible que haya configurado la VM como algo así como 6 CPU de doble núcleo. Terminará teniendo un problema similar a cómo los límites de 20 núcleos de Enterprise Edition limitan la cantidad de memoria que puede ver.
Si desea compartir el resultado de sp_Blitz aquí, puede ejecutarlo así para enviarlo a Markdown, que luego puede copiar / pegar en su pregunta:
sp_Blitz @OutputType="markdown", @CheckServerInfo = 1;
Actualización 16/04/2018 – confirmada. Adjuntó la salida sp_Blitz (¡gracias por eso!) Y de hecho muestra que tiene CPU y nodos de memoria fuera de línea. Quien construyó la máquina virtual la configuró como 12 CPU de un solo núcleo, por lo que SQL Server Standard Edition solo ve los primeros 4 sockets (núcleos) y la memoria adjunta a ellos.
Para solucionarlo, apague la máquina virtual, configúrela como una máquina virtual de 2 sockets y 6 núcleos, y luego SQL Server Standard Edition verá todos los núcleos y la memoria. Esto también reducirá sus esperas SOS_SCHEDULER_YIELD también; en este momento, su servidor SQL está martillando los primeros 4 núcleos, pero eso es todo. Después de esta corrección, podrá funcionar en los 12 núcleos.
Como anexo al plan de acción de Brent Ozar, quería compartir los resultados. Como señaló Brent, dentro de VMware habíamos configurado la máquina virtual de manera incorrecta con 12 CPU de un solo núcleo. Esto dio lugar a que SQL Server no pudiera acceder a los 8 núcleos restantes y, como resultado, provocó el problema de memoria descrito en mi pregunta original. Anoche pusimos nuestros servicios en modo de mantenimiento para reconfigurar la VM de manera adecuada. No solo estamos viendo que la memoria aumenta de manera normal, sino que, como Brent también insinuó, el número de esperas disminuyó exponencialmente y nuestro rendimiento general de SQL Server se disparó. Las configuraciones de vNUMA ahora son pequeños componentes felices que están atravesando nuestras cargas de trabajo.
Para aquellos que puedan estar utilizando VMware vSphere 6.5, los pasos breves para completar el elemento de acción descrito por Brent son los siguientes.
- Inicie sesión en vSphere Web Client para su clúster de VMware y busque la máquina virtual que aloja SQL Server. Su máquina virtual debe estar fuera de línea para poder ajustar las configuraciones de la CPU y la memoria.
-
Dentro del panel principal, vaya a
Configure > VM hardware, haga clic en elEditen la esquina superior derecha. Abrirá un menú contextual que tieneEdit Settings. Como referencia, la siguiente imagen es la incorrecto configuración. Tenga en cuenta que tengoCores per Socketajustado a1. Dadas las limitaciones de SQL Server Standard Edition, esta es una mala configuración.
-
La solución es tan simple como ajustar el
Cores per Socketvalor. En nuestro caso, lo configuramos en6para que tengamos2 Sockets. Esto permite que SQL Server utilice los 12 procesadores.
Una nota importante: no establezca el valor donde el Number of Cores o la Sockets sería un número impar. A NUMA le encanta el equilibrio y, por regla general, debe ser divisible entre 2. Por ejemplo, una configuración de 4 núcleos en 3 enchufes estaría desequilibrada. De hecho, si tuvieras que correr sp_Blitz con este tipo de configuración, arrojaría una advertencia sobre esto.
La sección 3.3 en Arquitectura de Microsoft SQL Server en VMware vSphere (advertencia en PDF) describe esto en detalle. Las prácticas descritas en el documento técnico son aplicables a la mayoría de la virtualización local de SQL Server.
Aquí hay algunos recursos más que he recopilado a través de mi investigación después de la publicación de Brent:
-
Virtualización de grandes bases de datos: planificación de la capacidad de la CPU de VMware
-
Dimensionamiento de vCPU y vNUMA de máquina virtual: reglas generales
-
Desacoplamiento de núcleos por socket de la topología NUMA virtual en vSphere 6.5
Terminaré con una captura de RedGate SQL Monitor durante las últimas 24 horas. El punto principal a tener en cuenta es la utilización de la CPU y la cantidad de esperas: durante nuestras horas pico de ayer, estábamos experimentando un uso intensivo de la CPU y conflictos de espera. Después de esta simple solución, hemos mejorado nuestro rendimiento diez veces. Incluso nuestra E / S de disco se ha reducido significativamente. Esta es una configuración que aparentemente se pasa por alto y que puede mejorar el rendimiento virtual en un orden de magnitud. Al menos, nuestros ingenieros lo pasaron por alto y una completa d’oh momento.
