Brent Ozar, Microsoft Certified Master, discutió recientemente el paralelismo en SQL Server, específicamente los tipos de espera CXPACKET y CXCONSUMER en su última entrega de la serie de otoño de los días de capacitación en bases de datos de Quest. Con su estilo humorístico y accesible habitual, Brent desmitificó los conceptos de paralelismo y explicó cómo manejarlo cuando ve demasiadas estadísticas de espera de CXPACKET y CXCONSUMER.
Primero, ¿qué es el paralelismo y por qué SQL Server hace que las consultas se ejecuten en paralelo?
En pocas palabras, SQL Server reconoce automáticamente que una consulta en particular tiene una gran carga de trabajo y determina que el trabajo se puede realizar de manera más eficiente en varios procesadores que con uno solo. Por lo general, esta es una decisión inteligente, pero puede generar problemas cuando SQL Server no equilibra la carga entre los subprocesos que realizan la tarea.
Comprensión de los tipos de espera CXPACKET y CXCONSUMER
CXPACKET y CXCONSUMER son tipos de espera que indican que el trabajo no está igualmente equilibrado. Cuando vea estas estadísticas de espera en su servidor, sabrá que SQL Server está ejecutando consultas en paralelo, pero no está haciendo un buen trabajo distribuyéndolas entre los procesadores disponibles.
Todos los profesionales de bases de datos están familiarizados con el concepto de "costo" para expresar cuán costosa es ejecutar una consulta en términos de consumo de recursos. Estos "dólares de consulta" son una medida aproximada de trabajo y una señal importante sobre si la consulta se ejecutará en paralelo o no. Una consulta económica no necesitará ejecutarse en paralelo, pero una costosa sí lo hará. El objetivo es ejecutar la consulta de la manera más rápida y eficiente posible para que pueda comenzar la siguiente en línea. SQL Server designa un subproceso como programador, y este subproceso, que Brent consideró el "señor supremo del robot", asignará partes de la carga de trabajo paralela a los subprocesos de trabajo, o los "súbditos del robot".
Paralelismo y el señor supremo del robot
Brent se sumergió en una demostración para mostrar cómo funciona esto. Usando la base de datos Stack Overflow, creó una búsqueda de base de datos de bajo costo que fue muy rápida debido a la presencia de un índice. El plan de ejecución era bastante sencillo y no requería paralelismo para ejecutarse.
Pero, cuando introdujo una búsqueda de algo que no estaba en el índice, las cosas cambiaron al forzar una búsqueda clave para cada fila en el índice agrupado de la tabla. SQL Server reconoció que esto supondría mucho trabajo, por lo que introdujo el paralelismo y lo indicó con un icono en el plan de ejecución. Si el plan de ejecución fuera tridimensional, podría ver los múltiples subprocesos apilados, pero como no es así, debe ver las estadísticas para ver información como las lecturas lógicas realizadas por cada subproceso de la CPU.
Sin embargo, SQL Server solo asignó esta tarea a algunos subprocesos, no a todos. Brent explicó que todo lo que sucede más allá del ícono paralelo ocurre solo en los procesadores asignados. Entonces, los subprocesos que realizaron las lecturas iniciales ahora son los únicos que también realizan las búsquedas clave. El señor supremo de los robots solo pidió a unos pocos minions que realizaran la tarea completa en lugar de pedirles a todos los minions que colaboraran.
Continuó explicando que SQL Server tiene que dar cuenta de lo que están haciendo los subprocesos, así como rastrear lo que está haciendo el señor supremo del robot. En los primeros días, todo este trabajo estaba representado por una estadística de espera, pero esto no tenía sentido porque, pase lo que pase, el señor supremo todavía tiene que esperar mientras todos los subprocesos funcionan. Por lo tanto, se introdujo un nuevo tipo de espera: CXCONSUMER y realiza un seguimiento de lo que está haciendo el subproceso del planificador/jefe supremo, mientras CXPACKET registra lo que están haciendo los subprocesos de trabajador/subordinado.
Brent volvió a la consulta para hacerla aún más compleja agregando una ordenación. Ahora, se vuelve aún más claro que el paralelismo está causando un problema en lugar de hacer que la operación sea más eficiente. El trabajo se ha vuelto aún más desequilibrado entre los pocos subprocesos de trabajo, y algunos se están quedando sin memoria y se están derramando en el disco. Agregó una unión, sobrecargando aún más los núcleos de trabajo que no reciben ninguna ayuda de los que no funcionan. Las estadísticas de CXPACKET continuaron aumentando.
¿Qué puedes hacer en esta situación? La decisión de paralelismo se produce a nivel de servidor y no a nivel de consulta, por lo que se necesitarán algunos cambios de configuración.
Evaluación de configuraciones clave
Ya aprendimos que si el costo de la consulta es superior a cierto nivel, hace que SQL Server se paralelice. Las consultas pequeñas se restringen a un solo hilo. Pero, ¿qué controla el umbral? Es una propiedad llamada Cost Threshold for Parallelism (CTFP). De forma predeterminada, si el plan de ejecución determina que el costo es superior a 5 dólares de consulta, la consulta se paralelizará. Si bien no existe una guía sobre cómo configurar esto, Brent recomienda un número superior a 50. Esto eliminará el paralelismo de las consultas triviales.
Otra configuración es el grado máximo de paralelismo (MAXDOP), que describe la cantidad de subprocesos que SQL Server asignará a la consulta. El valor predeterminado aquí es cero, lo que significa que SQL Server puede usar todos los procesadores disponibles, hasta 64, para ejecutar la consulta. Establecer la opción MAXDOP en 1 limita a SQL Server a usar solo un procesador; de hecho, obliga a un plan en serie a ejecutar la consulta. SQL Server recomendará un valor MAXDOP en función de la cantidad de núcleos de servidor que tenga, pero, en general, tiene sentido un MAXDOP más bajo, ya que no habrá muchas ocasiones en las que se necesiten todos los núcleos.
Brent hizo ajustes a estas dos configuraciones y ejecutó su consulta nuevamente. Esta vez, pudimos ver que más núcleos estaban involucrados en la operación paralela. Las estadísticas de espera de CXPACKET eran más bajas, lo que significaba que la carga estaba más equilibrada en más núcleos que antes.
Consejos para combatir las estadísticas de espera de CXPACKET y CXCONSUMER
Brent recomienda los siguientes pasos si ve demasiadas estadísticas de espera de CXPACKET y CXCONSUMER:
- Establezca CTFP y MAXDOP según las mejores prácticas de la industria y luego deje que esas configuraciones se horneen durante unos días. Esto borra la memoria caché del plan y obliga a SQL Server a reconstruir planes de ejecución de consultas (reevaluar el costo).
- Realice mejoras en el índice que reducirán los tiempos en que las consultas van en paralelo para realizar exploraciones y clasificaciones. Deje que los nuevos índices se horneen y luego busque consultas que todavía están haciendo mucho trabajo.
- Ajuste esas consultas y déjelas hornear durante unos días.
- Finalmente, si el paralelismo sigue siendo un problema grave, comience a buscar las consultas específicas con problemas de paralelismo.
Para obtener aún más información, puede ver la sesión de capacitación completa de Brent en CXPACKET y las estadísticas de espera de CXCONSUMER a pedido a continuación.
