¿Cómo afecta CXPACKET en SQL Server?

Usualmente ves un contador de CXPACKET en sistemas de monitoreo de SQL Server. O tal vez alguna vez consultaste la vista sys.dm_os_wait_stats. Lo importante es ver qué cómo afecta el Wait Type CXPACKET en SQL Server y cómo reaccionar ante su aparición.

A lo largo de los lugares y servidores que he visitado, he visto que una gran mayoría mantiene las configuraciones por defecto de SQL Server. No necesariamente quiere decir que esto sea desastroso, pese a no ser una buena práctica. Sin embargo, algo en común que veo entre ellos es el uso de CXPACKET como parte del top de Wait Stats del servidor.

¿Qué es CXPACKET?

CXPACKET es un Wait Type de SQL Server que sucede en los planes de ejecución con paralelismo cuando se sincroniza el Query Processor Exchange Iterator y cuando se producen y consumen las filas de un Result Set.

Un momento….¿Qué?

Entiendo. A veces es complicado de leerlo más aún por los nombres que son muy difícil de traducirlos. De todas maneras lo que quiero decirte en pocas palabras, es que CXPACKET está estrechamente relacionado con las operaciones en paralelo que realiza nuestro SQL Server.

¿Pero cuándo se generan las operaciones en paralelo?

Cuando SQL Server a través de la generación de un plan de ejecución, considera que repartir la carga de trabajo entre varios threads (paralelismo) será más rápido que trabajar con un solo hilo.

El tiempo que SQL Server se toma para distribuir la carga de trabajo y para nuevamente centralizar el resultado de este trabajo, podemos considerar como el tiempo que se contabiliza dentro del Wait Type CXPACKET.

¿Cómo afecta CXPACKET en SQL Server?

Ya hemos visto que esta realación no se puede romper. Cuando encontramos waits de CXPACKET no hay duda que se trata de Paralelismo. Lo que quiero que esté claro en este escenario es que no debemos pensar que mientras más se distribuya el trabajo (más paralelismo), más rápidas las respuestas.

Parecería que tiene lógica que mientras más distribuida la carga de trabajo, más rápido será concluida. En este caso, NO es una regla. Si bien existen lugares en los que trabajar con múltiples cores puede ser beneficioso, existen otros en los que puede suceder todo lo contrario.

Muchas veces puede suceder que cuando tu ejecutas algo en ambiente de Desarrollo, el comportamiento es diferente cuando lo ejecutas en ambiente de Producción (más detalle en el artículo Desarrollo vs Producción). Uno de los factores que influencia esta diferencia puede ser debido a los niveles de paralelismo que decide SQL Server.

Concluyamos un poco

• El nivel de paralelismo puede tener un efecto positivo o negativo, usualmente dependiendo de dos configuraciones importantes del servidor. El Max Degree of Parallelism y el Cost Threshold for Parallelism.
• El primer valor está pensado para definir hasta cuántos hilos se distribuye la carga. El segundo define a partir de qué costo de operación se considera el paralelismo.
• Lo más importante siempre es tener en cuenta el testing necesario. Comparar cómo cambia el comportamiento cambiando los dos parámetros mencionados.
• Existen inhibidores de paralelismo, a veces por más que configuramos al servidor para utilizar varios hilos, hay factores que evitan esta distribución.
• Pronto tendremos nuevamente la Webinar «Cómo funciona el paralelismo en SQL Server». Regístrate al boletín de noticias para mantenerte informado de los próximos eventos.