CPU

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!

El paralelismo es una característica de SQL Server que permite dividir una consulta en varias tareas y ejecutarlas simultáneamente en diferentes procesadores o núcleos. Esto 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.

En este artículo, vamos a explicarte qué es el paralelismo en SQL Server, y por qué es importante para el rendimiento de tus consultas. En un próximo artículo veremos cómo configurarlo, qué opciones tienes a tu disposición y qué factores debes tener en cuenta. Sin embargo, hoy nos vamos a centrar en esa teoría, a mi parecer imprescindible conocer antes de empezar a cambiar configuraciones. Tampoco vamos a hablar hoy de problemas de rendimiento, si quieres saber más sobre los problemas de uso excesivo de CPU en SQL Server, te recomiendo que leas nuestro anterior artículo al respecto.

¿Qué es el paralelismo en SQL Server?

El paralelismo en SQL Server es la capacidad de ejecutar una consulta en varios hilos o procesos paralelos, cada uno de los cuales se asigna a un procesador o núcleo diferente. Esto nos permite aprovechar la potencia de los sistemas multiprocesador de hoy en día y reducir el tiempo de ejecución de las consultas que implican grandes volúmenes de datos o que realizan operaciones costosas, como joins, ordenaciones o agregados.

El paralelismo se activa cuando el optimizador de consultas de SQL Server estima que el coste de ejecutar una consulta en paralelo es menor que el de ejecutarla en serie. El coste se mide en unidades de tiempo y depende de varios factores, como el tamaño de los datos, el tipo de operación, el índice utilizado, la estadística disponible, etc. El optimizador de consultas genera un plan de ejecución que indica cómo se va a ejecutar la consulta, qué operadores se van a utilizar y cuántos hilos se van a emplear.

Coste de los planes de ejecución, la clave del paralelismo

Hemos hablado de que el motor de SQL Server calcula el coste de ejecución de una consulta y en base a eso decide si usar o no un plan de varios hilos. ¿Pero qué es el coste de ejecución de una consulta? El coste de ejecución de una consulta es una medida que indica el esfuerzo que tiene que hacer SQL Server para ejecutar una consulta. El coste de ejecución se expresa en unidades arbitrarias que no tienen un significado absoluto, sino relativo. Es decir, el coste de ejecución sirve para comparar el rendimiento de diferentes consultas o de diferentes planes de ejecución para la misma consulta.

Para ver el coste de ejecución de una consulta, podemos usar los planes de ejecución, que son representaciones gráficas de cómo SQL Server ejecuta una consulta. Los planes de ejecución se pueden mostrar de forma estimada o real. Un plan de ejecución estimado se genera sin ejecutar la consulta, basándose en las estadísticas y los índices disponibles. Un plan de ejecución real se genera después de ejecutar la consulta, basándose en los datos reales y los recursos consumidos. Los planes de ejecución se pueden mostrar usando el menú de SQL Server Management Studio, las opciones SET SHOWPLAN o las vistas de gestión dinámica.

El coste de ejecución de una consulta es una herramienta útil para optimizar el rendimiento de las consultas en SQL Server. Al comparar el coste de ejecución de diferentes consultas o de diferentes planes de ejecución para la misma consulta, podemos identificar los operadores más costosos y buscar formas de reducir su coste. Por ejemplo, podemos crear o modificar índices, simplificar las consultas, usar funciones o variables adecuadas, cambiar el nivel de aislamiento, etc.

Los planes de ejecución

Los planes de ejecución se componen de varios operadores, que son las acciones que realiza el motor de SQL Server para ejecutar una consulta. Cada operador tiene un coste asociado, que se muestra como un porcentaje del coste total de la consulta. El coste total de la consulta se muestra en la raíz del plan de ejecución. Cada operador tendrá un coste que dependerá de la complejidad del mismo, del número de filas que procesa, del tamaño de las filas, del uso de índices, de la memoria, del disco, etc. El coste de cada operador se puede ver al pasar el cursor sobre el icono del mismo o al ver las propiedades del mismo.

Por otro lado, los planes de ejecución se dividen en dos partes: el plan serial y el plan paralelo. El plan serial contiene las operaciones que se ejecutan en un solo hilo, como las lecturas o las escrituras de datos. El plan paralelo contiene las operaciones que se ejecutan en varios hilos, como los joins, las ordenaciones o los agregados. 

Fases de los planes de ejecución paralelos

Tenemos que pensar en estos planes paralelos como cuando hacíamos un trabajo de grupo en clase. En esos casos, nos repartíamos las tareas, cada uno hacía su parte y, al final, lo poníamos en conjunto y salía un trabajo final excelente. Los planes paralelos hacen exactamente lo mismo y para ello se componen de tres fases: la distribución, la ejecución y la recolección.

Fase de distribución

En esta primera fase se reparten los datos entre los hilos que van a ejecutar el plan paralelo. Para ello, se utiliza un operador llamado exchange, que puede ser de dos tipos: repartition o redistribute. El operador repartition divide los datos en fragmentos iguales y los asigna a los hilos de forma aleatoria. El operador redistribute divide los datos en función de una clave de partición y los asigna a los hilos de forma que cada uno reciba los datos que corresponden a una o varias particiones.

Fase de ejecución 

Durante esta fase se realizan las operaciones sobre los datos distribuidos de manera paralela en varios hilos. Cada hilo ejecuta el mismo plan paralelo sobre los datos que le han sido asignados. Los operadores que se utilizan en esta fase son los mismos que se utilizan en el plan serial, pero con la diferencia de que se ejecutan en paralelo.

Fase de recolección 

Para finalizar, en esta última fase, se juntan los resultados de los hilos que han ejecutado el plan paralelo. Para ello, se utiliza otro operador exchange, que puede ser de dos tipos: concat o gather streams. El operador concat concatena los resultados de los hilos sin ordenarlos ni agruparlos. El operador gather streams, sin embargo, ordena o agrupa los resultados de los hilos según el criterio especificado.

Inhibidores de paralelismo

No todas las consultas que ejecutamos en SQL Server son candidatas a usar un plan de ejecución paralelo. Existen una serie de factores que pueden impedir o limitar el uso del paralelismo por parte de SQL Server. A estos factores los llamamos inhibidores de paralelismo. Algunos de estos factores son:

• El nivel de aislamiento de la transacción: si el nivel de aislamiento es SERIALIZABLE o REPEATABLE READ, SQL Server no usará el paralelismo para evitar problemas de consistencia de los datos.
• El uso de cursores: si una consulta usa un cursor, SQL Server no usará el paralelismo para mantener el orden de las filas devueltas por el cursor.
• El uso de funciones escalares o tabulares: si una consulta usa una función escalar o tabular definida por el usuario, SQL Server no usará el paralelismo para ejecutar la función, lo que puede afectar al rendimiento de la consulta.
• El uso de tablas temporales o variables: si una consulta usa una tabla temporal o una variable de tabla, SQL Server no usará el paralelismo para acceder a dicha tabla o variable, lo que puede afectar al rendimiento de la consulta.

Conclusión

Muchos estabais esperando leer cómo configurar el nivel de paralelismo y qué tener en cuenta. Eso lo veremos en el próximo artículo mañana. En este artículo, hemos explicado a fondo el paralelismo en SQL Server y lo que implica, hemos explicado qué es el coste de ejecución de una consulta y cómo se calcula.

También hemos visto cómo mostrar el coste de ejecución de una consulta usando los planes de ejecución. 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 como ya comentamos en el pasado artículo sobre problemas de uso excesivo de CPU en SQL Server.

Esperamos que este artículo os haya sido útil y os animamos a seguir aprendiendo sobre SQL Server con nosotros. 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!