Después de instalar SQL Server Enterprise 2012 con el modelo de licencia Server + Cal, en una computadora con 2 procesadores cada uno con 16 núcleos (y sin hyperthreading involucrado) y poner el servidor bajo una carga extremadamente pesada, los 16 núcleos en el primer procesador estaban muy subutilizados, los primeros 4 núcleos en la segunda CPU se utilizaron en gran medida, y los últimos 12 núcleos no se utilizaron en absoluto (debido al límite de 20 núcleos para esta versión de servidor sql). La utilización total de la CPU se mostró alrededor del 25%. Desafortunadamente, el servidor sufrió un rendimiento extremadamente pobre, aunque si las tareas se distribuyeran uniformemente en los 20 núcleos, no habría sido tan malo.
Windows Server se estaba ejecutando en una imagen virtual VMWare en ESX Server, pero toda la CPU se asignó al servidor de Windows.
Intentamos cambiar la configuración de afinidad (por ejemplo, asignar la mayoría de los núcleos a la CPU y los demás a E / S), pero eso no ayudó a resolver los problemas de rendimiento.
La actualización de la edición del producto a SQL Server Enterprise Core 2012 no solo permitió que SQL Server utilizara los 12 núcleos no utilizados anteriormente en el segundo procesador, sino que también resultó en una distribución mucho más uniforme de las tareas en todos los procesadores. Para superar la acumulación de solicitudes, la utilización de cpU aumentó a alrededor del 90%, y luego se redujo a alrededor del 33% una vez que se puso al día, pero el rendimiento mejoró drásticamente ya que fallamos en la versión recién actualizada Y los problemas de rendimiento desaparecieron.
Me preguntaba si alguien sabe qué podría causar que SQL Server distribuya la carga de manera desigual, confiando casi exclusivamente en los primeros 4 núcleos del segundo procesador que tenían 12 núcleos inactivos, y asigne solo unas pocas tareas a cada uno de los 16 núcleos en el primer procesador. Además, ¿hay alguna forma en que podríamos haber distribuido la carga de manera más uniforme en los 20 núcleos que se estaban utilizando sin la actualización de la edición del producto?
La otra cara de esa pregunta es: ¿qué hizo la actualización del producto que provocó que SQL Server comenzara a distribuir la carga de manera uniforme en todos los núcleos que reconoció?
Gracias a cualquier idea para responder estas preguntas y / o enlaces que podrían ayudarme a comprender mejor cómo entender lo que estaba sucediendo.
fuente
Respuestas:
El rendimiento desigual probablemente fue una combinación del límite de 20 núcleos combinado con la forma en que el servidor sql programa subprocesos en máquinas NUMA. Desafortunadamente, SQL Server 2012 no utiliza ninguna inteligencia para decidir qué 20 núcleos utilizar, lo que resulta en un número desequilibrado de núcleos por nodo NUMA. Con 32 núcleos distribuidos en 2 nodos NUMA, es probable que termines con una división de 16/4. Esto es problemático porque SQL tratará de equilibrar la actividad por igual en todos los nodos NUMA de forma circular (suponiendo que no esté forzando afinidad con el regulador de recursos).
En su caso, la mitad de la carga se asigna a 4 núcleos y 1/2 a 16 núcleos. El cuello de botella en el nodo de 4 núcleos actúa efectivamente como un acelerador, limitando la capacidad de la máquina a 2x 4 núcleos = 8 núcleos = 25% de uso de CPU.
Una vez que actualizó a la edición core, sql utilizó los 32 núcleos en 2 nodos numa (división 16/16). Rendimiento mejorado, etc.
Una opción que podría haber mejorado su rendimiento habría sido utilizar el regulador de recursos del servidor sql para afinar la mayor parte de su carga de trabajo a un nodo numa. Por ejemplo, podría crear un grupo de recursos WEB_APP y afinitarlo para que solo se ejecute en el nodo numa de 16 núcleos. La carga asignada al grupo WEB_APP podría utilizar el 50% de la capacidad del servidor, más el 12.5% restante del nodo de 4 núcleos.
La otra opción sería limitar los núcleos disponibles para el servidor sql a solo 10 de cada nodo numa.
fuente