Servidor SQL de un solo núcleo en VM

7

Recientemente, nuestro distrito escolar ha actualizado varios servidores de la versión 2005 a 2016 y de servidores físicos a servidores VM.

Nuestro equipo de infraestructura presentó los servidores VM para la instalación de SQL Server con un solo núcleo.

Estoy tratando de explicarle al jefe de ese departamento que SQL Server 'odia' estar en un solo núcleo y quiere ver 'prueba'. Ninguno de los datos que he presentado ha satisfecho su necesidad de pruebas, por lo que ha pedido algunos artículos sobre por qué un VM SQL Server no funcionará de manera eficiente en un solo núcleo.

¿Qué artículos usas para esto?

¡Se agradecería cualquier ayuda para mi caso!

sql-server sql-server-2016 vmware

— Debutante
fuente

77

Cuando licencia SQL en una VM, de todas formas paga dos paquetes de licencias. Estás arrojando dinero al no darle al menos dos núcleos, incluso si obtienes un descuento educativo.

— Erik Darling

44

Puede consultar el artículo de Glenn Barry (más de 10 años de Microsoft MVP) de 2015 que enumera las CPU recomendadas para SQL 2014, de las cuales la más pequeña tiene seis núcleos.

— LowlyDBA

2

Además, hace un tiempo escribí un documento técnico para Google sobre el tamaño de las máquinas virtuales en la nube. Puede aplicar eso también en las instalaciones.

— Erik Darling,

Ampliando el comentario de @sp_BlitzErik, las licencias básicas mínimas que se pueden aplicar a un único servidor SQL, ya sea VM o físico, son 4 licencias (consulte la Guía de licencias ). La alternativa es licenciar los núcleos físicos del host. Según ese modelo, puede ejecutar tantas máquinas virtuales con tantos vCores como desee.

— Mark Storey-Smith

11

Cualquier proceso que no sea de SQL Server que consuma CPU puede causar que todo el SQL Server quede completamente inutilizable.

Como ejemplo, Windows Update detendrá SQL Server mientras desempaqueta ensamblados .Net.

Cualquier proceso de Anti-Virus, incluso si está configurado para excluir archivos y carpetas de datos de SQL Server, puede hacer que SQL Server deje de responder mientras analiza archivos y desempaqueta archivos de definición de virus actualizados.

Si tiene instalado un software de gestión, como IBM Tivoli Server Monitor, y decide utilizar el 100% de un núcleo, probablemente no podrá hacer nada más que apagar la máquina en frío. No me preguntes por qué estoy mencionando eso.

Podría continuar, pero basta decir que cualquier servidor con un solo núcleo simplemente está pidiendo problemas con el rendimiento y la capacidad de administración. Verifique que cualquier computadora con un solo núcleo se considere inutilizable hoy en día. Diablos, mi teléfono tiene 8 núcleos.

Mientras lo hace, convenza al tipo de virtualización para que otorgue a cada servidor SQL una reserva de memoria razonable que garantice que la memoria del servidor SQL no salga de la memoria principal del host al disco.

Para los servidores SQL serios alojados en VMware, debe configurar VMware de acuerdo con la Guía de mejores prácticas de arquitectura de SQL Server en VMware .

Realmente se reduce a una máquina virtual de un solo núcleo que solo puede ejecutar un solo subproceso en un momento dado. La virtualización no es una bala de plata para esa situación de un núcleo por hilo.

Los puntos anteriores tienen en cuenta que Windows NT (la base de código de 1993 en la que se basan todas las versiones modernas de Windows) utiliza tareas múltiples preventivas. La multitarea preventiva permite que la O / S imponga la multitarea al forzar el cambio de contexto en horarios regulares. Incluso con la multitarea preventiva, un servidor con un solo núcleo sufrirá un rendimiento muy bajo si una sola tarea decide usar la mayor cantidad de CPU posible, ya que el O / S le dará a esa tarea el mayor tiempo de CPU posible sin dejar de permitir que se ejecuten tareas de mayor prioridad, lo que obliga a la CPU al 100%. Si SQL Server se está ejecutando en el momento en que la CPU alcanza el 100%, la cantidad de CPU de SQL Server se reducirá tanto que se volverá muy notable. En los escenarios anteriores que he descrito, yo nodigamos, la máquina (o incluso SQL Server) se "detendrá" o "morirá" por completo; eso simplemente sería falso. Sin embargo, la máquina puede estar tan ocupada que, para todos los efectos, la máquina queda inutilizable. Agregar un segundo núcleo, aunque ciertamente no es una panacea, reduce la probabilidad de que la máquina deje de responder por completo. Cada núcleo adicional significa que otro subproceso puede ejecutarse al 100% de la CPU sin que la máquina quede inutilizable.

— Max Vernon
fuente

¿El servidor de Windows no tiene (y siempre tuvo) multitarea preventiva? A menos que me equivoque, lo que está describiendo es una multitarea cooperativa, procesos que se rinden entre sí cuando han realizado su tarea de alto nivel. La disputa segura podría retrasar una respuesta, pero no debería detener por completo las cosas. Estoy de acuerdo en que mutli-core es una buena idea, si no la mejor práctica, pero el escenario del día del juicio final que presenta no parece correcto.

— Mâtt Frëëman

A veces también hay una buena razón para seguir siendo un solo núcleo, si anteriormente era un solo núcleo físico y las aplicaciones que hablan con su instancia de un solo núcleo rompieron las mejores prácticas, como no especificar un orden de clasificación, y consideraron que el pedido era implícitamente estable en ausencia de tal luego, cambiar a varios núcleos puede mostrar errores que previamente fueron suprimidos por la naturaleza de un solo núcleo. Si no tiene el presupuesto para volver a QA estas aplicaciones o poca fe en los desarrolladores o tal vez ya se han ido, hacer coincidir los servidores físicos existentes en términos de núcleos expuestos a veces puede ser una apuesta segura

— Mâtt Frëëman

Hola, @ MâttFrëëman: agregué una sección a mi respuesta que trata sobre la multitarea preventiva. Me recordó cuánto mejor se compara la base de código NT con la multitarea cooperativa basada en DOS utilizada por la base de código original de Windows, incluido Windows ME.

— Max Vernon

Estoy de acuerdo con su gran parte de sus comentarios sobre permanecer en un solo núcleo a veces es un mal necesario. Mi respuesta supone que las máquinas físicas que se han virtualizado probablemente eran servidores de varios núcleos, basados en el deseo del OP de tener máquinas virtuales de múltiples núcleos.

— Max Vernon

@MaxVernon Gracias, ¡esto es exactamente lo que necesitábamos!

— Deb

6

He tenido que probar lo mismo antes. Lo que finalmente llegó a nuestro equipo de planificación de capacidad es que nuestras bases de datos eran casi inutilizables durante una copia de seguridad.

Como DBA, su mayor temor debería ser la pérdida de datos. Si no puede ejecutar copias de seguridad con confianza sin tomar o causar una interrupción, es un gran problema. Ejecute algunas pruebas para asegurarse de que el rendimiento se vea afectado mientras se realiza una copia de seguridad, luego explique que con más de un núcleo el problema debería desaparecer.

— Neghtasro
fuente

3

De hecho, cualquier cantidad grave de E / S, ya sea SQL Server o no relacionado con SQL Server, puede causar un problema.

— Max Vernon

3

@MaxVernon Absolutamente: Acabo de mencionar específicamente las copias de seguridad porque es un problema que he tratado antes (a las 3 a.m., natch), es fácil de probar y "¡no podemos hacer copias de seguridad sin una interrupción!" debería ser suficiente para estimular a cualquier administrador de infraestructura razonable para ahorrar un núcleo miserable.

— Neghtasro

2

Para proporcionar una prueba convincente de que su servidor necesita más de una CPU, deberá proporcionar información sobre la carga de trabajo y las consultas que se ejecutan en el servidor. Si solo tiene una base de datos de menos de 100 MB, por ejemplo, y todas las consultas son muy simples y eficientes, es posible que no haya ningún beneficio en tener más núcleos.

Le recomendaría que comience a capturar planes de consulta que van en paralelo y el tiempo que tardan en completarse. Esto demostrará que la carga de trabajo que se ejecuta en el sistema se beneficiará de tener múltiples CPU.

Si ya está en producción en el entorno VM, también debe capturar los datos de rendimiento del uso de la CPU. Si puede demostrar que la CPU se está maximizando al 100% durante largos períodos de tiempo, esto también proporcionaría una buena evidencia de que el sistema necesita más CPU.

— Tony Hinkle
fuente

55

Por supuesto, no habrá planes paralelos en una VM de un solo núcleo. Tendría que capturar esos planes en una caja que tiene más de un núcleo.

— Max Vernon

3

Para agregar al comentario de Max, si observa el plan XML en un servidor con un solo núcleo, verá NonParallelPlanReason="EstimatedDOPIsOne" .

— Erik Darling

@ Tony ya les he proporcionado algunos datos, pero me dijeron que un solo núcleo era una mejor práctica con una máquina VM. de ahí mi necesidad de ayuda!

— Deb

1

@Deb Oh, Dios mío, ¡nunca he oído hablar de esa mejor práctica! Puedo escuchar el triste trombón de Brent Ozar desde aquí. Me preocuparía que alguien que hace declaraciones como esa esté a cargo de una infraestructura de VM.

— Tony Hinkle

@TonyHinkle - Estoy de acuerdo. Una VM de núcleo único nunca es una buena idea, dejar que una sola "mejor práctica". Ok, quizás el 99.999% del tiempo en lugar de "nunca": - /

— Max Vernon

2

Quizás debería preguntarles por qué insisten en que sería una buena idea asignar solo un núcleo por VM de SQL Server.

Luego, dependiendo de su respuesta, puede intentar convencerlos según el ítem 3.3.2 en este enlace:

SqlServer-on-vmware-best-pratices

VMware recomienda que, para el tamaño inicial, el número total de vCPU asignadas a todas las máquinas virtuales no sea más que el número total de núcleos físicos

Si ese elemento no es la razón para que el equipo de infraestructura aprovisione solo 1 núcleo por VM, entonces, posiblemente, el hardware se está desperdiciando.

— Rogerlr
fuente

¿No está seguro de cómo la cita ayuda al caso de más CPU?

— LowlyDBA

Sí, pero no está tan claro por qué el equipo de infraestructura no puso más cpus por VM.

— Rogerlr