Limite el uso máximo de CPU de SQL SERVER con WSRM


10

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?


¿De verdad quieres usar toda la CPU? Guardar un par de núcleos para el sistema operativo parece prudente, ¿no? En mi estación de trabajo, si uso todos los núcleos para algunos números, mi máquina se detiene. Siempre mantengo algunos núcleos libres. ¿No sería una buena práctica también en una máquina dedicada a SQL Server?
ManInMoon

¿Qué tipo de carga se está ejecutando en este servidor? ¿Qué tipo de proceso está utilizando el 100% de la CPU? ¿Es esto OLTP o análisis o gráfico o?
Max Vernon

@Forrest Cuando dice ajuste, ¿se refiere al SQL Server en sí mismo o a la estructura de consultas / tablas? Si te refieres a SQL Server, por favor dame un enlace a qué mirar. Si hay consultas / tablas, las optimizo cuando puedo, ¡pero algunos usuarios son menos conscientes del diseño!
ManInMoon

Respuestas:


14

¿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.


11

Erik Darling mencionó la mayor razón práctica para no usar WSRM en un comentario sobre su pregunta:

... no hay limitación recíproca del uso de la CPU en otros procesos. SQL Server puede no usar esos dos núcleos, pero otras cosas pueden usar los otros 30 que SQL Server está usando. Es una porquería, de verdad.

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

Además, está pagando licencias de SQL Server por ellos.

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).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.