Estamos comenzando a aprovisionar un conjunto de servidores físicos para un clúster virtual de nodos de SQL Server 2016 dentro de VMware. Utilizaremos licencias de Enterprise Edition.
Planeamos configurar 6 nodos, pero hay un poco de debate sobre cuál es la forma ideal de aprovisionar los servidores físicos con respecto a la velocidad del reloj de la CPU versus el conteo de núcleos de la CPU.
Sé que esto depende en gran medida del volumen de transacciones y el número de bases de datos almacenadas entre otros factores específicos del software, pero ¿se recomienda una regla general?
Por ejemplo, ¿es un servidor físico dual de 8 núcleos y 3,2 GHz (16 núcleos) más preferencial que un servidor dual de 16 núcleos y 2,6 GHz (32 núcleos)?
¿Alguien ha encontrado un libro blanco que profundiza en este tipo de tema?
fuente
Respuestas:
La regla general es mantener el conteo del núcleo lo más bajo posible y la velocidad del procesador lo más alta posible. La matemática de licencias en eso demuestra el punto en ~ $ 7,500 USD por núcleo para la Edición Costosa.
Comprar el hardware correcto puede pagarse a sí mismo en costos de licencia reducidos. Consulte Selección de procesador para SQL Server por Glenn Berry. Es un gran recurso sobre cómo elegir un procesador para SQL Server.
Una vez que tenga en cuenta la estructura de licencias por núcleo de SQL Server, tiene sentido ir siempre con la velocidad de procesador más rápida disponible, independientemente del tipo de carga de trabajo, ya sea OLTP o análisis. Tener la velocidad central más rápida posible nunca será un problema. Aumente el recuento de núcleos según sea necesario, pero nunca lo haga reduciendo la velocidad del núcleo.
En otras palabras, no piense que los procesadores de 16 x 2.2Ghz son lo mismo que los procesadores de 8 x 4.5Ghz. Es probable que el ahorro de costos de usar los procesadores de 2.2Ghz sobre los procesadores de 4.5Ghz sea de un máximo de aproximadamente $ 10,000 USD (para una máquina típica de dos procesadores basada en Xeon). Saltar de 8 núcleos a 16 núcleos con SQL Server Enterprise Edition probablemente costará más de $ 60,000 USD en tarifas de licencia. En otras palabras, puede ahorrar $ 10,000 en costos de hardware, pero perderá $ 50,000 adicionales en licencias.
Si decide que necesita una gran cantidad de músculo de procesamiento paralelo, y decide que necesita 32 núcleos para la tarea en cuestión, ir con los núcleos más rápidos pagará dividendos en un tiempo de procesamiento reducido. Nadie te culpará por eso.
Habiendo dicho todo eso, si la elección es una CPU o más de una CPU, elija siempre más de una . Ejecutar SQL Server (o cualquier DBMS) en una sola CPU puede causar todo tipo de problemas, ya que la capacidad para operaciones concurrentes es muy limitada.
fuente
Espera, espera, espera
Si bien los aspectos de rendimiento y licencia son interesantes, no son el único aspecto de una carga de trabajo a tener en cuenta.
Una cosa que puede tener un impacto en la elección del procesador son los hilos de trabajo.
Hilos de trabajadores?
¡Sí compinche! Son las cosas que su SQL Server usará para ejecutar sus consultas y hacer todas las cosas de fondo que necesita hacer para mantener las cosas en forma.
Cuando te quedas sin hilos de trabajo, golpeas THREADPOOL espera
THREADPOOL?
THREADPOOL. Esta es una de las esperas más desagradables que puede tener en su servidor, junto con RESOURCE_SEMAPHORE y RESOURCE_SEMAPHORE_QUERY_COMPILE . Pero esas son esperas de memoria, y esta es una pregunta de CPU.
Volvamos a por qué esto es Wiggity Wack.
Así es como SQL Server calcula los hilos de trabajo :
Observe cómo duplicar los recuentos de núcleos no duplica Max Worker Threads, y obtiene el mismo número con 1 núcleo que con 4 núcleos. La ecuación es:
512 + ((logical CPUs - 4) * 16)Es una pena, porque cuando los recuentos de núcleos aumentan, la velocidad del reloj generalmente cae en picado una o dos generaciones atrás.
Echar un vistazo a cualquier línea reciente de chips Intel mostrará una tendencia similar.
¿Cómo sé cuántos hilos necesito?
Esto dependerá mucho de:
Si no te estás quedando sin ellos hoy, probablemente estés bien.
¿Pero cómo sabes si lo eres?
Hay buenas preguntas, y hay buenas preguntas, y déjame decirte algo, esa es una GRAN PREGUNTA .
THREADPOOL puede manifestarse como problemas de conexión , y es posible que vea mensajes en el registro de errores acerca de no poder generar un hilo .
También puede ver las estadísticas de espera de su servidor utilizando una herramienta gratuita como sp_Blitz o sp_BlitzFirst (divulgación completa, contribuyo a este proyecto).
EXEC sp_BlitzEXEC sp_BlitzFirst @SinceStartup = 1¿No puedo simplemente aumentar Max Worker Threads?
El aumento de MWT puede conducir a mayores
SOS_SCHEDULER_YIELDesperasEse no es el fin del mundo, pero piense en ello como agregar un buncha gritando a los niños a la clase de un maestro.
De repente, será más difícil para cada niño llamar la atención.
Cuando un proceso agota su cuántica de 4 ms , potencialmente habrá más subprocesos por delante esperando para entrar en la CPU.
El rendimiento puede sentirse casi igual.
¿Cómo puedo usar menos hilos de trabajo?
¡Eres cruel [sustantivo] de un [sustantivo], esos son trabajadores con familias que mantener! Hipotecas! ¡Sueños!
Pero bien, tengo que respetar el resultado final. Tú eres el jefe.
El lugar más fácil para comenzar es cambiar la configuración como MAXDOP y Umbral de costo para paralelismo de los valores predeterminados.
Si tiene preguntas sobre cómo configurarlas, diríjase aquí:
Algoritmo de configuración MAXDOP para SQL Server
Por qué el umbral de costo para el paralelismo no debe establecerse en 5
Después de eso, su trabajo se vuelve mucho más difícil. Tienes que descubrir qué está usando todos esos hilos. A veces puedes hacerlo mirando tus estadísticas de espera.
Más específicamente, si tiene altas esperas en el paralelismo (
CXPACKET) Y altas esperas en los bloqueos (LCK_), entonces es posible que se encuentre con largas cadenas de bloqueo que involucran consultas paralelas.¿Sabes qué apesta? Si bien todas esas consultas paralelas esperan obtener sus bloqueos, no devuelven sus hilos asignados.
Casi puede escuchar esa VM de cuatro núcleos que su administrador le aseguró que era más que suficiente para cualquier carga de trabajo que contenía aire, ¿eh?
Desafortunadamente, el tipo de consulta y ajuste de índice que tiene que hacer para resolver esas cosas está más allá del alcance de la pregunta.
¡Espero que esto ayude!
fuente
Respuesta wiki comunitaria :
En resumen, la mayoría de las cargas de trabajo para SQL Server son OLTP, lo que se beneficia de velocidades de reloj más altas porque es una operación en serie.
A menos que esté diseñando específicamente para un sistema paralelo masivo, las velocidades de reloj siempre ganarán. Existen casos extremos, pero esa es la respuesta del 95% del tiempo. El hecho de que termine costando menos también es algo bueno.
fuente
La respuesta se reduce a esto: depende de su caso de uso.
Por ejemplo, tengo una computadora de cuatro núcleos, pero el compilador ESP8266 solo usa el 25% de mi CPU porque solo está diseñado para usar un núcleo. Si tuviera 1 núcleo rápido, entonces sería más óptimo.
fuente