Tengo un servidor físico que ejecuta una instancia de SQL Server.
Noto que con bastante frecuencia este servidor se ejecuta al 100% de uso de la CPU.
Mi equipo de TI no está contento con esto y sugirió que reservemos 2 de los 32 núcleos para el sistema operativo.
Esto funciona muy bien, ahora el pico de uso máximo es inferior al 90%. Además, ya no se informa la recuperación lenta de datos de varios usuarios.
¿Hay alguna razón para NO usar WSRM (Administrador de recursos del sistema de Windows) de esta manera, en lugar del Gobernador de recursos SQL?
sql-server
configuration
windows
resource-governor
ManInMoon
fuente
fuente
Respuestas:
¿Hay alguna razón para NO usar el enfoque que ha definido? Absolutamente.
Imagine que ha comprado un automóvil, un automóvil que cuando alcanza los 50MPH el motor comienza a sobrecalentarse. ¿Su reacción ante esta situación sería limitar artificialmente el automóvil a 49 MPH, o averiguar cuál es la falla del motor?
¿Por qué debería limitar su automóvil a 49 MPH? El fabricante declaró que podría conducir tan rápido como 80 MPH, le gusta conducir su automóvil rápido, por lo que desea llegar a esta velocidad, si no fuera por ese maldito problema de sobrecalentamiento.
El auto que compraste también era muy, muy caro. ¡Cada cilindro del motor debe utilizarse al máximo para que no desperdicie ese dinero!
Al limitar artificialmente el acceso de los servidores SQL a la CPU, está perdiendo rendimiento. Es posible que haya resuelto temporalmente los problemas de rendimiento al asegurarse de que la CPU esté disponible para que la use el sistema operativo, pero no ha respondido la pregunta real: ¿POR QUÉ SQL Server está utilizando el 100% de la CPU?
Mi consejo es el siguiente:
Descubre cuál es el verdadero problema y arréglalo. No cubra el problema con lo que efectivamente es un error. La cuestión SE reaparecer y golpear en la cara abajo de la línea cuando la carga de trabajo del servidor aumenta de forma natural con el crecimiento.
Como solución temporal , el regulador de recursos puede usarse para reducir la CPU utilizada, HASTA ENCONTRAR EL PROBLEMA REAL.
fuente
Erik Darling mencionó la mayor razón práctica para no usar WSRM en un comentario sobre su pregunta:
Si esto funciona para usted, entonces quédese con él: todos estamos ocupados y solo puede pasar tanto tiempo en cualquier problema. La solución ideal sería solucionar las consultas / problemas subyacentes que están llevando a la CPU al punto de problemas notables por el usuario (que George cubre en su excelente respuesta ).
Erik continúa diciendo
Desde el punto de vista comercial, esta es probablemente la peor parte del acuerdo WSRM: está pagando licencias por núcleo para 2 núcleos que explícitamente no se están utilizando. Al momento de escribir este artículo, quedan $ 3k o $ 14k en la mesa (dependiendo de Standard vs Enterprise).
fuente