En este artículo, vamos a explicar cómo configurar el paralelismo en SQL Server, qué opciones tienes a tu disposición y qué factores debes tener en cuenta para optimizar el rendimiento de tus consultas. Para poder hacer esto es muy importante tener las bases teóricas sobre el paralelismo, coste de consultas y planes paralelos que vimos en el pasado artículo. Si aún no lo has leído, te recomiendo encarecidamente que pares aquí, vayas a leerlo y luego continúes con este.
Configuración del paralelismo en SQL Server
Ahora que ya todos estamos en el mismo punto y entremos en materia. SQL Server dispone de varios parámetros que nos permiten controlar el comportamiento del paralelismo. Estos parámetros se pueden establecer a nivel de servidor, de base de datos o de consulta. Estos parámetros son principalmente dos, el nivel de coste y el máximo grado de paralelismo.
Cost Threshold for Parallelism
Este parámetro define el umbral de coste estimado a partir del cual SQL Server considera usar el paralelismo para ejecutar una consulta. El coste estimado es una medida relativa que depende de varios factores, como el tamaño de los datos, el tipo de operación, el índice utilizado, etc. El valor por defecto de este parámetro es 5, lo que significa que SQL Server usará el paralelismo para las consultas que tengan un coste estimado mayor o igual a 5.
Este valor se puede modificar a nivel de servidor con el comando sp_configure o con el asistente de configuración de SQL Server. Un valor demasiado bajo puede provocar que SQL Server use el paralelismo para consultas que no lo necesitan, consumiendo recursos innecesariamente. Un valor demasiado alto puede provocar que SQL Server no use el paralelismo para consultas que podrían beneficiarse de él, perdiendo rendimiento. Por eso, es recomendable ajustar este valor según el tipo de consultas que se ejecuten en el servidor y el rendimiento que se quiera obtener.
Max Degree of Parallelism
Este parámetro define el número máximo de procesadores o núcleos que SQL Server puede usar para ejecutar una consulta en paralelo. El valor por defecto de este parámetro es 0, lo que significa que SQL Server puede usar todos los procesadores o núcleos disponibles en el servidor. Este valor se puede modificar a nivel de servidor con el comando sp_configure o con el asistente de configuración de SQL Server. También se puede modificar a nivel de base de datos con el comando ALTER DATABASE o a nivel de consulta con la opción MAXDOP.
Hay que mencionar aquí que el paralelismo en SQL Server es si o no, si una consulta cumple con los requisitos del umbral de paralelismo usará todos los núcleos configurados para paralelizar. No hay opción intermedia. Un valor demasiado alto puede provocar que SQL Server use más procesadores o núcleos de los necesarios, generando una sobrecarga de coordinación y reduciendo el rendimiento. Un valor demasiado bajo puede provocar que SQL Server use menos procesadores o núcleos de los disponibles, desaprovechando los recursos y limitando el rendimiento. Por eso, es recomendable ajustar este valor según la capacidad del servidor y la complejidad de las consultas que normalmente se ejecutan.
¿Cómo configurar el paralelismo en SQL Server?
Como ya hemos comentado, el paralelismo en SQL Server se puede configurar a varios niveles: a nivel de servidor, a nivel de base de datos y a nivel de consulta. Cada nivel tiene sus propias opciones y parámetros que afectan al comportamiento del paralelismo. A continuación, te explicamos cada uno de ellos y cómo puedes modificarlos.
MAXDOP a nivel de servidor
Para configurar MAXDOP a nivel de servidor, tenemos las dos opciones que hemos visto antes para controlar el paralelismo: el grado máximo de paralelismo (MAXDOP del inglés MAX Degree Of Parallelism) y el umbral de coste para el paralelismo (cost threshold for parallelism).
Podemos modificar el valor del MAXDOP y el umbral de coste de paralismo mediante el comando sp_configure o mediante las opciones disponibles en las configuraciones de la instancia en SSMS.
MAXDOP a nivel de base de datos
A nivel de base de datos, hay una opción que puedes configurar para controlar el paralelismo: el grado máximo de paralelismo (MAXDOP) por base de datos. Esta opción te permite especificar un valor diferente del MAXDOP para cada base de datos, lo que te da más flexibilidad para adaptar el paralelismo a las características de cada base de datos. El valor por defecto es 0, lo que significa que se utiliza el valor del MAXDOP a nivel de servidor. Puedes modificar el valor del MAXDOP por base de datos mediante el comando ALTER DATABASE o mediante las opciones en las propiedades de la base de base de datos en SSMS.
MAXDOP a nivel de consulta
A nivel de consulta, podemos usar la opción de consulta OPTION (MAXDOP) para controlar el paralelismo. La opción de consulta OPTION (MAXDOP) te permite especificar un valor diferente del MAXDOP para cada consulta, lo que te da más control para optimizar el rendimiento de cada consulta. El valor por defecto es 0, lo que significa que se utiliza el valor del MAXDOP a nivel de base de datos o a nivel de servidor. Puedes modificar el valor de la opción de consulta OPTION (MAXDOP) mediante la cláusula OPTION al final de la consulta.
Otras formas de modificar el MAXDOP
Existen otros métodos además de los principales que hemos comentado para controlar el nivel de paralelismo como vamos a ver a continuación:
- Establecer un umbral de coste de paralelismo demasiado alto: de esta manera nos garantizamos de que casi ninguna consulta se va a paralelizar.
- Traza 8649 tanto a nivel de consulta como de servidor: Porque en ningún momento os había dicho que estas formas eran buenas ideas, podemos usar esta traza para que TODAS las consultas (que se pueda) se ejecuten con un plan de ejecución paralelo.
- Usar inhibidores de paralelismo: Ya vimos en el anterior artículo que hay varias razones por las que una consulta no va a paralelizar.
- Usar inhibidores en columnas calculadas: Si nuestra tabla tiene una columna calculada que usa una función escalar, como es un inhibidor de paralelismo ninguna consulta sobre esa tabla se paralelizará. Ni siquiera los chequeos de integridad o las reconstrucciones de índices.
- Opcion MAXDOP en indices: A la hora de crear, reorganizar o reconstruir un índice podremos usar el hint MAXDOP para establecer un nivel de paralelismo diferente al del servidor.
- Resource Governor: Con resource governor podremos establecer distintas configuraciones de MAXDOP para cada grupo de cargas de trabajo.
Evaluación del impacto del paralelismo en el rendimiento de las consultas
El paralelismo es una característica de SQL Server que puede mejorar el rendimiento de las consultas que involucran grandes cantidades de datos o que requieren operaciones complejas. Sin embargo, el paralelismo también tiene sus inconvenientes, como el consumo de recursos, la sobrecarga de coordinación y la posibilidad de generar bloqueos o esperas. Por eso, es importante configurar el paralelismo de forma adecuada para cada escenario y evitar los problemas que puede causar.
Aun así, evaluar el impacto de los cambios de configuración es de vital importancia. No será la primera vez que una configuración que, a priori, creemos beneficiosa empeore el comportamiento final del servidor. Para saber si el paralelismo está ayudando o perjudicando al rendimiento de nuestras consultas, podemos usar varias herramientas y métodos, como consultar los planes de ejecución de las consultas, consultar las gráficas del monitor de actividad de nuestro SSMS, usar las vistas de administración dinámica (como las que vimos aquí) o el monitor de rendimiento de windows (perfmon).
Conclusión
En este artículo, hemos explicado cómo configurar el paralelismo en SQL Server, qué parámetros debemos tener en cuenta y cómo evaluar el impacto del paralelismo en el rendimiento de nuestras consultas.
Espero que este artículo te haya sido útil y que te ayude a optimizar el rendimiento de tus consultas en SQL Server. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn al que te puedes unir. ¡Hasta la próxima!
