Umbrales de optimización:agrupación y agregación de datos, parte 4

Aquí, el costo del plan en serie [forzado] es mayor o igual que el umbral de costo para el paralelismo, y el costo del plan en paralelo es menor que el costo del plan en serie, por lo que SQL Server eligió el plan en paralelo de forma predeterminada.

Considere las siguientes consultas (las llamaremos Consulta 10 y Consulta 11):

-- Query 10: Serial
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000;
 
-- Query 11: Forced parallel
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

Los planes para estas consultas se muestran en la Figura 5.

Figura 5:Costo serial>=umbral de costo para paralelismo, costo paralelo>=costo serial

Aquí, el costo del plan en serie es mayor o igual que el umbral de costo para el paralelismo; sin embargo, el costo del plan en serie es más bajo que el costo del plan paralelo [forzado], por lo tanto, SQL Server eligió el plan en serie de forma predeterminada.

Hay otra cosa que debe saber acerca de intentar maximizar el paralelismo con la sugerencia ENABLE_PARALLEL_PLAN_PREFERENCE. Para que SQL Server incluso pueda usar un plan paralelo, tiene que haber algún activador de paralelismo como un predicado residual, una ordenación, un agregado, etc. Un plan que aplica solo un escaneo de índice o una búsqueda de índice sin un predicado residual y sin ningún otro habilitador de paralelismo, se procesará con un plan en serie. Considere las siguientes consultas como ejemplo (las llamaremos Consulta 12 y Consulta 13):

-- Query 12
 
SELECT *
FROM dbo.Orders
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));
 
-- Query 13
 
SELECT *
FROM dbo.Orders
WHERE orderid >= 100000
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

Los planes para estas consultas se muestran en la Figura 6.

Figura 6:Habilitador de paralelismo

La consulta 12 obtiene un plan en serie a pesar de la sugerencia, ya que no hay habilitador de paralelismo. La consulta 13 obtiene un plan paralelo ya que hay un predicado residual involucrado.

Computación y prueba de DOP para costos

Microsoft tuvo que calibrar las fórmulas de costos en un intento de tener un costo de plan paralelo más bajo que el costo del plan en serie reflejando un tiempo de ejecución más bajo y viceversa. Una idea potencial era tomar el costo de CPU del operador en serie y simplemente dividirlo por la cantidad de CPU lógicas en la máquina para producir el costo de CPU del operador en paralelo. El número lógico de CPU en la máquina es el factor principal que determina el grado de paralelismo de la consulta, o DOP en resumen (el número de subprocesos que se pueden usar en una zona paralela en el plan). El pensamiento simplista aquí es que si un operador tarda T unidades de tiempo en completarse cuando usa un subproceso, y el grado de paralelismo de la consulta es D, el operador tardaría T/D en completarse cuando usa D subprocesos. En la práctica, las cosas no son tan simples. Por ejemplo, normalmente tiene varias consultas ejecutándose simultáneamente y no solo una, en cuyo caso una sola consulta no obtendrá todos los recursos de la CPU de la máquina. Entonces, a Microsoft se le ocurrió la idea del grado de paralelismo para el cálculo de costos (DOP por costeo, en fin). Esta medida suele ser menor que la cantidad de CPU lógicas en la máquina y es el factor por el cual se divide el costo de CPU del operador en serie para calcular el costo de CPU del operador en paralelo.

Normalmente, el DOP para el cálculo de costos se calcula como el número de CPU lógicas dividido por 2, utilizando la división de enteros. Sin embargo, hay excepciones. Cuando la cantidad de CPU es 2 o 3, el DOP para el cálculo de costos se establece en 2. Con 4 o más CPU, el DOP para el cálculo de costos se establece en #CPU / 2, nuevamente, utilizando la división de enteros. Eso es hasta cierto máximo, que depende de la cantidad de memoria disponible para la máquina. En una máquina con hasta 4.096 MB de memoria el DOP máximo para costear es 8; con más de 4.096 MB, el DOP máximo para costear es 32.

Para probar esta lógica, ya sabe cómo emular una cantidad deseada de CPU lógicas utilizando DBCC OPTIMIZER_WHATIF, con la opción de CPU, así:

DBCC OPTIMIZER_WHATIF(CPUs, 8);

Usando el mismo comando con la opción MemoryMBs, puede emular una cantidad deseada de memoria en MB, así:

DBCC OPTIMIZER_WHATIF(MemoryMBs, 16384);

Use el siguiente código para verificar el estado existente de las opciones emuladas:

DBCC TRACEON(3604);
 
DBCC OPTIMIZER_WHATIF(Status);
 
DBCC TRACEOFF(3604);

Utilice el siguiente código para restablecer todas las opciones:

DBCC OPTIMIZER_WHATIF(ResetAll);

Aquí hay una consulta T-SQL que puede usar para calcular DOP para el cálculo de costos en función de una cantidad de CPU lógicas de entrada y una cantidad de memoria:

DECLARE @NumCPUs AS INT = 8, @MemoryMBs AS INT = 16384;
 
SELECT
  CASE
    WHEN @NumCPUs  = 1 THEN 1
    WHEN @NumCPUs <= 3 THEN 2
    WHEN @NumCPUs >= 4 THEN
      (SELECT MIN(n)
       FROM ( VALUES(@NumCPUs / 2), (MaxDOP4C ) ) AS D2(n))
  END AS DOP4C
FROM ( VALUES( CASE WHEN @MemoryMBs <= 4096 THEN 8 ELSE 32 END ) ) AS D1(MaxDOP4C);

Con los valores de entrada especificados, esta consulta devuelve 4.

La Tabla 1 detalla el DOP para el costo que obtiene en función de la cantidad lógica de CPU y la cantidad de memoria en su máquina.

Tabla 1:DOP para costeo

Como ejemplo, revisemos la Consulta 1 y la Consulta 2 mostradas anteriormente:

-- Query 1: Forced serial
 
SELECT custid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY custid
OPTION(MAXDOP 1);
 
-- Query 2: Naturally parallel
 
SELECT custid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY custid;

Los planes para estas consultas se muestran en la Figura 7.

Figura 7:DOP para costos

La Consulta 1 fuerza un plan en serie, mientras que la Consulta 2 obtiene un plan paralelo en mi entorno (emula 8 CPU lógicas y 16 384 MB de memoria). Esto significa que el costo de DOP en mi entorno es 4. Como se mencionó, el costo de la CPU de un operador paralelo se calcula como el costo de la CPU del operador en serie dividido por el costo de DOP. Puede ver que ese es el caso en nuestro plan paralelo con los operadores Index Seek y Hash Aggregate que se ejecutan en paralelo.

En cuanto a los costos de los operadores de intercambio, están compuestos por un costo de inicio y un costo constante por fila, que puede aplicar ingeniería inversa fácilmente.

Observe que en la estrategia de agrupación y agregación en paralelo simple, que es la que se usa aquí, las estimaciones de cardinalidad en los planes en serie y en paralelo son las mismas. Eso es porque solo se emplea un operador agregado. Más adelante verá que las cosas son diferentes cuando se utiliza la estrategia local/global.

Las siguientes consultas ayudan a ilustrar el efecto de la cantidad de CPU lógicas y la cantidad de filas involucradas en el costo de la consulta (10 consultas, con incrementos de 100 000 filas):

SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 900001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 800001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 700001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 600001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 500001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 400001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 200001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 100001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 000001
GROUP BY empid;

La Figura 8 muestra los resultados.

Figura 8:Costo de consulta con respecto a #CPU y #filas

La línea verde representa los costos de las diferentes consultas (con los diferentes números de filas) usando un plan serial. Las demás líneas representan los costos de los planes paralelos con diferente número de UCPs lógicas, y su respectivo DOP para costeo. La línea roja representa el punto donde el costo de la consulta en serie es 5, el umbral de costo predeterminado para la configuración de paralelismo. A la izquierda de este punto (menos filas para agrupar y agregar), normalmente, el optimizador no considerará un plan paralelo. Para poder investigar los costos de los planes paralelos por debajo del umbral de costo para el paralelismo, puede hacer una de dos cosas. Una opción es usar la sugerencia de consulta ENABLE_PARALLEL_PLAN_PREFERENCE, pero como recordatorio, esta opción maximiza el paralelismo en lugar de simplemente forzarlo. Si ese no es el efecto deseado, simplemente puede deshabilitar el umbral de costo para el paralelismo, así:

EXEC sp_configure 'show advanced options', 1;  
RECONFIGURE;
 
EXEC sp_configure 'cost threshold for parallelism', 0;  
 
EXEC sp_configure 'show advanced options', 0;  
RECONFIGURE;

Obviamente, ese no es un movimiento inteligente en un sistema de producción, pero es perfectamente útil para fines de investigación. Eso es lo que hice para generar la información para el gráfico de la Figura 8.

Comenzando con filas de 100 000 y agregando incrementos de 100 000, todos los gráficos parecen implicar que tener un umbral de costo para el paralelismo no era un factor, siempre se hubiera preferido un plan paralelo. De hecho, ese es el caso con nuestras consultas y la cantidad de filas involucradas. Sin embargo, pruebe con un número menor de filas, comenzando con 10 000 y aumentando en incrementos de 10 000 utilizando las siguientes cinco consultas (nuevamente, mantenga el umbral de costo para el paralelismo deshabilitado por ahora):

SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 990001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 980001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 970001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 960001
GROUP BY empid;
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 950001
GROUP BY empid;

La Figura 9 muestra los costos de consulta con planes paralelos y en serie (emulando 4 CPU, DOP para el costo de 2).

Figura 9:Serie / umbral del plan paralelo

Como puede ver, hay un umbral de optimización hasta el cual se prefiere el plan en serie y por encima del cual se prefiere el plan paralelo. Como se mencionó, en un sistema normal en el que mantiene el umbral de costo para la configuración de paralelismo en el valor predeterminado de 5 o superior, el umbral efectivo es de todos modos más alto que en este gráfico.

Anteriormente mencioné que cuando SQL Server elige la estrategia de paralelismo de agregación y agrupación simple, las estimaciones de cardinalidad de los planes en serie y en paralelo son las mismas. La pregunta es, ¿cómo maneja SQL Server las estimaciones de cardinalidad para la estrategia de paralelismo local/global?

Para resolver esto, usaré la Consulta 3 y la Consulta 4 de nuestros ejemplos anteriores:

-- Query 3: Local parallel global parallel
 
SELECT empid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY empid;
 
-- Query 4: Local parallel global serial
 
SELECT shipperid, COUNT(*) AS numorders
FROM dbo.Orders
WHERE orderid >= 300001
GROUP BY shipperid;

En un sistema con 8 CPU lógicas y un DOP efectivo para el valor de costeo de 4, obtuve los planes que se muestran en la Figura 10.

Figura 10:Estimación de cardinalidad

La consulta 3 agrupa los pedidos por empid. Se esperan 500 grupos distintos de empleados eventualmente.

La consulta 4 agrupa los pedidos por shipperid. Se esperan 5 grupos distintos de cargadores eventualmente.

Curiosamente, parece que la cardinalidad estimada para el número de grupos producidos por el agregado local es {número de grupos distintos esperados por cada subproceso} * {DOP para costeo}. En la práctica, se da cuenta de que el número suele ser el doble, ya que lo que cuenta es el DOP para la ejecución (también conocido como DOP), que se basa principalmente en el número de CPU lógicas. Esta parte es un poco complicada de emular con fines de investigación, ya que el comando DBCC OPTIMIZER_WHATIF con la opción de CPU afecta el cálculo del DOP para el cálculo de costos, pero el DOP para la ejecución no será mayor que la cantidad real de CPU lógicas que ve su instancia de SQL Server. Este número se basa esencialmente en el número de planificadores con los que comienza SQL Server. Tu puedes controle la cantidad de programadores que SQL Server comienza con el uso del parámetro de inicio -P{ #schedulers }, pero esa es una herramienta de investigación un poco más agresiva en comparación con una opción de sesión.

En cualquier caso, sin emular ningún recurso, mi máquina de prueba tiene 4 CPU lógicas, lo que da como resultado DOP por coste 2 y DOP por ejecución 4. En mi entorno, el agregado local en el plan para la consulta 3 muestra una estimación de 1000 grupos de resultados (500 x 2), y un real de 2.000 (500 x 4). De manera similar, el agregado local en el plan para la Consulta 4 muestra una estimación de 10 grupos de resultados (5 x 2) y un real de 20 (5 x 4).

Cuando haya terminado de experimentar, ejecute el siguiente código para la limpieza:

-- Set cost threshold for parallelism to default
 
EXEC sp_configure 'show advanced options', 1;  
RECONFIGURE;
 
EXEC sp_configure 'cost threshold for parallelism', 5;  
 
EXEC sp_configure 'show advanced options', 0;  
RECONFIGURE;
GO
 
-- Reset OPTIMIZER_WHATIF options
 
DBCC OPTIMIZER_WHATIF(ResetAll);
 
-- Drop indexes
 
DROP INDEX idx_oid_i_sid ON dbo.Orders;
DROP INDEX idx_oid_i_eid ON dbo.Orders;
DROP INDEX idx_oid_i_cid ON dbo.Orders;

Conclusión

En este artículo, describí una serie de estrategias de paralelismo que usa SQL Server para manejar la agrupación y la agregación. Un concepto importante a comprender en la optimización de consultas con planes paralelos es el grado de paralelismo (DOP) para el cálculo de costos. Mostré una serie de umbrales de optimización, incluido un umbral entre planes en serie y paralelos, y el umbral de costo de configuración para el paralelismo. La mayoría de los conceptos que describí aquí no son exclusivos de la agrupación y la agregación, sino que son igualmente aplicables a las consideraciones de planes paralelos en SQL Server en general. El próximo mes continuaré la serie discutiendo la optimización con reescrituras de consultas.