Recientemente, Triumph se vio involucrado en la resolución de problemas de una instancia de Rock con un uso general muy elevado de la CPU y del trabajador de la base de datos. El indicador inicial fue la lentitud en el registro de entrada y la imposibilidad de guardar la asistencia al registrarse.
Hicimos todo lo posible y probamos nuestros sospechosos habituales (comprobamos trabajos, vistas de datos e informes, etc.) sin resultados. Después de mucho crujir de dientes y llorar y gemir (también conocido como "investigación" y "solución de problemas") nos encontramos con un ajuste en SQL Server, "Grados máximos de paralelismo" - "MAXDOP".
El paralelismo entra en juego cuando un servidor SQL dispone de más de un núcleo de CPU. Ciertas consultas pueden "ir en paralelo", lo que significa que pueden utilizar más de un núcleo simultáneamente para procesar una consulta. Un ejemplo podría ser la exploración de una tabla en busca de registros dentro de un intervalo de fechas especificado. No hay ninguna razón por la que estos registros deban explorarse secuencialmente, por lo que el procesador de consultas de SQL Server puede dividir la consulta y asignar trozos a distintos núcleos. La ventaja es un aumento potencial de la velocidad de consulta.
En algunos casos, una consulta en paralelo puede agotar todos los núcleos y privar de recursos a otras consultas.
Microsoft publicó un artículo, Configure the max degree of parallelism (MAXDOP) in Azure SQL Database, que explica un poco sobre el paralelismo y la configuración que limita cuántos núcleos puede consumir una consulta.
Curiosamente, este artículo contiene una nota que indica que antes de septiembre de 2020 las bases de datos Azure SQL tenían MAXDOP establecido por defecto en "0", o "ilimitado." Ese mes cambiaron la configuración por defecto a "8". Según Microsoft, "este valor predeterminado ayudó a evitar problemas de rendimiento debidos a un paralelismo excesivo".
El cambio de la configuración MAXDOP de "0" a "8" en nuestra instancia problemática redujo drásticamente el uso de recursos.
A continuación se muestra una captura de pantalla del rendimiento de la base de datos durante el registro del domingo por la mañana antes del cambio:
Y el rendimiento después del cambio:
Esta configuración sólo se aplica a instancias con más de un núcleo. El número de núcleos disponibles para una base de datos Azure de nivel inferior es probable que sea uno o dos y el ajuste tendrá poco o ningún efecto. Las bases de datos de nivel superior pueden tener algunos núcleos y establecer MAXDOP a algo así como la mitad de los núcleos disponibles puede suponer una mejora. Tendrá el mayor efecto en una instancia grande con muchos núcleos. El nuevo valor por defecto de 8, en nuestra experiencia, es probable que esté bien en una instancia grande. Experimentar ayudaría a determinar si una configuración diferente sería beneficiosa.
Esta configuración se realiza en las propiedades de la base de datos, accesibles en SSMS o Azure Data Studio:
