Intercalación de consultas
Se aplica a:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
La intercalación de consultas es una configuración del sistema en modo tabular que puede mejorar el rendimiento de las consultas en escenarios de alta simultaneidad. De forma predeterminada, el motor tabular de Analysis Services funciona de forma inicial, primero en salir (FIFO) con respecto a la CPU. Con FIFO, por ejemplo, si se recibe una consulta de motor de almacenamiento costosa y posiblemente lenta y, después, seguida de dos consultas rápidas, las consultas rápidas pueden bloquearse potencialmente esperando a que se complete la consulta costosa. Este comportamiento se muestra en el diagrama siguiente, que muestra Q1, Q2 y Q3 como las consultas respectivas, su duración y tiempo de CPU.
La intercalación de consultas con sesgo corto de consulta permite que las consultas simultáneas compartan recursos de CPU, lo que significa que las consultas rápidas no se bloquean detrás de consultas lentas. El tiempo necesario para completar las tres consultas sigue siendo el mismo, pero en nuestro ejemplo Q2 y Q3 no se bloquean hasta el final. El sesgo de consulta corta significa que las consultas rápidas, definidas por la cantidad de CPU que cada consulta ya ha consumido en un momento dado, se puede asignar una proporción mayor de recursos que las consultas de larga duración. En el diagrama siguiente, las consultas Q2 y Q3 se consideran rápidas y se asignan más CPU que Q1.
La intercalación de consultas está pensada para tener poco o ningún impacto en el rendimiento en las consultas que se ejecutan de forma aislada; Una sola consulta todavía puede consumir tanta CPU como lo hace con el modelo FIFO.
Consideraciones importantes
Antes de determinar si la intercalación de consultas es adecuada para su escenario, tenga en cuenta lo siguiente:
- La intercalación de consultas solo se aplica a los modelos de importación. No afecta a los modelos de DirectQuery.
- La intercalación de consultas solo considera la CPU consumida por las consultas del motor de almacenamiento VertiPaq. No se aplica a las operaciones del motor de fórmulas.
- Una sola consulta DAX puede dar lugar a varias consultas del motor de almacenamiento VertiPaq. Una consulta DAX se considera rápida o lenta en función de la CPU consumida por sus consultas del motor de almacenamiento. La consulta DAX es la unidad de medida.
- Las operaciones de actualización están protegidas de forma predeterminada frente a la intercalación de consultas. Las operaciones de actualización de larga duración se clasifican de forma diferente a las consultas de larga duración.
Configurar
Para configurar la intercalación de consultas, establezca la propiedad Threadpool\SchedulingBehavior . Esta propiedad se puede especificar con los siguientes valores:
| Valor | Descripción |
|---|---|
| -1 | Automático. El motor elegirá el tipo de cola. |
| 0 (valor predeterminado para SSAS 2019) | En primer lugar, primero fuera (FIFO). |
| 1 | Sesgo de consulta corto. El motor limita gradualmente las consultas de larga duración cuando están bajo presión en favor de las consultas rápidas. |
| 3 (valor predeterminado para Azure AS, Power BI, SSAS 2022 y versiones posteriores) | Sesgo de consulta corto con cancelación rápida. Mejora los tiempos de respuesta de las consultas de usuario en escenarios de alta simultaneidad. Solo se aplica a Azure AS, Power BI, SSAS 2022 y versiones posteriores. |
En este momento, la propiedad SchedulingBehavior solo se puede establecer mediante XMLA. En SQL Server Management Studio, el siguiente fragmento de código XMLA establece la propiedad SchedulingBehavior en 1, sesgo de consulta corto.
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ThreadPool\SchedulingBehavior</Name>
<Value>1</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
Importante
Se requiere un reinicio de la instancia del servidor. En Azure Analysis Services, debe pausar y reanudar el servidor, reiniciando eficazmente.
Propiedades adicionales
En la mayoría de los casos, SchedulingBehavior es la única propiedad que necesita establecer. Las siguientes propiedades adicionales tienen valores predeterminados que deben funcionar en la mayoría de los escenarios con sesgos de consulta cortos, pero se pueden cambiar si es necesario. Las siguientes propiedades no tienen ningún efecto a menos que la intercalación de consultas esté habilitada estableciendo la propiedad SchedulingBehavior.
ReservedComputeForFastQueries : establece el número de núcleos lógicos reservados para consultas rápidas . Todas las consultas se consideran rápidas hasta que se desintegran porque han usado una cierta cantidad de CPU. ReservedComputeForFastQueries es un entero entre 0 y 100. El valor predeterminado es 75.
La unidad de medida para ReservedComputeForFastQueries es el porcentaje de núcleos. Por ejemplo, un valor de 80 en un servidor con 20 núcleos intenta reservar 16 núcleos para consultas rápidas (mientras no se realizan operaciones de actualización). ReservedComputeForFastQueries se redondea hasta el número entero más cercano de núcleos. Se recomienda no establecer este valor de propiedad por debajo de 50. Esto se debe a que las consultas rápidas se podrían privar y es contraria al diseño general de la característica.
DecayIntervalCPUTime : entero que representa el tiempo de CPU en milisegundos que pasa una consulta antes de que se desintegra. Si el sistema está bajo presión de CPU, las consultas desintegradas se limitan a los núcleos restantes no reservados para las consultas rápidas. El valor predeterminado es 60 000. Esto representa 1 minuto de tiempo de CPU, no la hora del calendario transcurrido.
ReservedComputeForProcessing : establece el número de núcleos lógicos reservados para cada operación de procesamiento (actualización de datos). El valor de propiedad es un entero entre 0 y 100, con un valor predeterminado de 75 expresado. El valor representa un porcentaje de los núcleos determinados por la propiedad ReservedComputeForFastQueries. Un valor de 0 (cero) significa que las operaciones de procesamiento están sujetas a la misma lógica de intercalación de consultas que las consultas, por lo que se puede descaer.
Aunque no se realizan operaciones de procesamiento, ReservedComputeForProcessing no tiene ningún efecto. Por ejemplo, con un valor de 80, ReservedComputeForFastQueries en un servidor con 20 núcleos reserva 16 núcleos para consultas rápidas. Con un valor de 75, ReservedComputeForProcessing reservará 12 de los 16 núcleos para las operaciones de actualización, dejando 4 para consultas rápidas mientras las operaciones de procesamiento se ejecutan y consumen CPU. Como se describe en la sección Consultas desintegradas a continuación, los cuatro núcleos restantes (no reservados para consultas rápidas o operaciones de procesamiento) se seguirán usando para consultas rápidas y procesamiento si están inactivos.
Estas propiedades adicionales se encuentran en el nodo Propiedades de ResourceGovernance . En SQL Server Management Studio, el siguiente fragmento de código XMLA de ejemplo establece la propiedad DecayIntervalCPUTime en un valor inferior al predeterminado:
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ResourceGovernance\DecayIntervalCPUTime</Name>
<Value>15000</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
Consultas desintegradas
Las restricciones descritas en esta sección solo se aplican si el sistema está bajo presión de CPU. Por ejemplo, una sola consulta, si es la única que se ejecuta en el sistema en un momento dado, puede consumir todos los núcleos disponibles independientemente de si se ha degradado o no.
Cada consulta puede requerir muchos trabajos del motor de almacenamiento. Cuando un núcleo del grupo de consultas desintegradas esté disponible, el programador comprobará la consulta en ejecución más antigua en función de la hora del calendario transcurrido para ver si ya ha usado su derecho máximo de núcleo (MCE). Si no, se ejecuta su siguiente trabajo. Si es así, se evalúa la siguiente consulta más antigua. El MCE de consulta viene determinado por cuántos intervalos de descomposición ya ha usado. Para cada intervalo de descomposición usado, el MCE se reduce en función del algoritmo que se muestra en la tabla siguiente. Esto continúa hasta que la consulta se completa, agota el tiempo de espera o el MCE se reduce a un único núcleo.
En el ejemplo siguiente, el sistema tiene 32 núcleos y la CPU del sistema está bajo presión.
ReservedComputeForFastQueries es 60 (60%).
- 20 núcleos (19.2 redondeado hacia arriba) está reservado para consultas rápidas.
- Los 12 núcleos restantes se asignan para las consultas con descomposición.
DecayIntervalCPUTime es de 60 000 (1 minuto de tiempo de CPU).
El ciclo de vida de una consulta puede ser el siguiente, siempre y cuando no se complete el tiempo de espera:
| Fase | Estado | Ejecución y programación | MCE |
|---|---|---|---|
| 0 | Fast (rápido) | El MCE es de 20 núcleos (reservado para consultas rápidas). La consulta se ejecuta de forma FIFO con respecto a otras consultas rápidas en los 20 núcleos reservados. El intervalo de descomposición de 1 minuto de tiempo de CPU se usa. |
20 = MIN(32/2˄0, 20) |
| 1 | Decaído | El MCE se establece en 12 núcleos (12 núcleos restantes no reservados para consultas rápidas). Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de descomposición de 1 minuto de tiempo de CPU se usa. |
12 = MIN(32/2˄1, 12) |
| 2 | Decaído | El MCE se establece en 8 núcleos (trimestre de 32 núcleos totales). Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de descomposición de 1 minuto de tiempo de CPU se usa. |
8 = MIN(32/2˄2, 12) |
| 3 | Decaído | El MCE se establece en 4 núcleos. Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de descomposición de 1 minuto de tiempo de CPU se usa. |
4 = MIN(32/2˄3, 12) |
| 4 | Decaído | El MCE se establece en 2 núcleos. Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de descomposición de 1 minuto de tiempo de CPU se usa. |
2 = MIN(32/2˄4, 12) |
| 5 | Decaído | El MCE se establece en 1 núcleo. Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de descomposición no se aplica, ya que la consulta ha bajado. No hay más descomposición, ya que se alcanza el mínimo de 1 núcleo. |
1 = MIN(32/2˄5, 12) |
Si el sistema está bajo presión de CPU, a cada consulta no se le asignarán más núcleos que su MCE. Si actualmente todas las consultas usan todos los núcleos dentro de sus respectivos MCE, otras consultas esperan hasta que los núcleos estén disponibles. A medida que los núcleos están disponibles, se recoge la consulta con derecho más antigua en función de su tiempo de calendario transcurrido. El MCE es un tapón bajo presión; no garantiza el número de núcleos en ningún momento dado.