Intercalación de consultas
Se aplica a: 
SQL Server Analysis Services
Azure Analysis Services
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, Analysis Services motor tabular funciona primero en salir (FIFO) con respecto a la CPU. Esto significa, por ejemplo, si se recibe una consulta de motor de almacenamiento costosa y posiblemente lenta y, a continuación, seguida de dos consultas rápidas, las consultas rápidas pueden bloquearse a la espera de que se complete la consulta costosa. Esto 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 un sesgo de consulta corto permite que las consultas simultáneas compartan recursos de CPU. Esto significa que las consultas rápidas no se bloquean detrás de consultas lentas. El tiempo necesario para completar las tres consultas sigue siendo aproximadamente el mismo, pero en nuestro ejemplo Q2 y Q3 no se bloquean hasta el final. El sesgo de consultas cortas significa que las consultas rápidas, definidas por la cantidad de CPU que ya ha consumido cada consulta en un momento dado, se pueden asignar una proporción mayor de recursos que las consultas de ejecución larga. En el diagrama siguiente, las consultas Q2 y Q3 se consideran rápidas y se les asigna 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 puede seguir consumiendo 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 tiene en cuenta la CPU consumida por las consultas del motor de almacenamiento de 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 ejecución larga se clasifican de forma diferente a las consultas de ejecución larga.
Habilitación de la intercalación de consultas
Para habilitar la intercalación de consultas, establezca la propiedad SchedulingBehavior. Esta propiedad se puede especificar con los valores siguientes:
| Value | Descripción |
|---|---|
| -1 | Automático. El motor elegirá el tipo de cola. |
| 0 (valor predeterminado) | Primero en, primero en salir (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 consultas rápidas. |
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 de forma eficaz.
Propiedades adicionales
En la mayoría de los casos, SchedulingBehavior es la única propiedad que debe establecer. Las siguientes propiedades adicionales tienen valores predeterminados que deben funcionar en la mayoría de los escenarios con un sesgo de consulta corto, 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 degradan porque han usado una determinada cantidad de CPU. ReservedComputeForFastQueries es un entero comprendido entre 0 y 100. El valor predeterminado es 75.
La unidad de medida de 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 redondea al número entero de núcleos más cercano. Se recomienda no establecer este valor de propiedad por debajo de 50. Esto se debe a que las consultas rápidas podrían estar privadas y es contrario 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 descierte. Si el sistema está bajo presión de CPU, las consultas decadencia se limitan a los núcleos restantes no reservados para consultas rápidas. El valor predeterminado es 60 000. Esto representa 1 minuto de tiempo de CPU, no tiempo de 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 comprendido 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 pueden degradar.
Aunque no se realiza ninguna operación 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 decadencia a continuación, los 4 núcleos restantes (no reservados para consultas rápidas o operaciones de procesamiento) se seguirán utilizando 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 decadencia
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 ha decaido o no.
Cada consulta puede requerir muchos trabajos del motor de almacenamiento. Cuando haya disponible un núcleo en el grupo para consultas decadencia, el programador comprobará la consulta en ejecución más antigua en función del tiempo de calendario transcurrido para ver si ya ha usado su derecho máximo de núcleo (MCE). Si no es así, se ejecuta su siguiente trabajo. En caso afirmativo, se evalúa la siguiente consulta más antigua. El MCE de consulta viene determinado por el número de intervalos de decadencia que ya ha usado. Para cada intervalo de decadencia usado, el MCE se reduce en función del algoritmo que se muestra en la tabla siguiente. Esto continúa hasta que se completa la consulta, se ha completado 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 del 60 (60 %).
- 20 núcleos (19,2 redondeados al día) está reservado para consultas rápidas.
- Los 12 núcleos restantes se asignan para consultas decadencia.
El valor de DecayIntervalCPUTime es 60 000 (1 minuto de tiempo de CPU).
El ciclo de vida de una consulta puede ser el siguiente, siempre y cuando no se agote el tiempo de espera o se complete:
| Fase | Status | Ejecución y programación | MCE |
|---|---|---|---|
| 0 | Fast (rápido) | El MCE tiene 20 núcleos (reservados para consultas rápidas). La consulta se ejecuta de forma FIFO con respecto a otras consultas rápidas en los 20 núcleos reservados. Se ha usado el intervalo de decadencia de 1 minuto de tiempo de CPU. |
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. Se ha usado el intervalo de decadencia de 1 minuto de tiempo de CPU. |
12 = MIN(32/2˄1, 12) |
| 2 | Decaído | El MCE se establece en 8 núcleos (trimestre de 32 núcleos en total). Los trabajos se ejecutan en función de la disponibilidad hasta MCE. Se ha usado el intervalo de decadencia de 1 minuto de tiempo de CPU. |
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. Se ha usado el intervalo de decadencia de 1 minuto de tiempo de CPU. |
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. Se ha usado el intervalo de decadencia de 1 minuto de tiempo de CPU. |
2 = MIN(32/2˄4, 12) |
| 5 | Decaído | McE se establece en 1 núcleo. Los trabajos se ejecutan en función de la disponibilidad hasta MCE. El intervalo de decadencia no se aplica porque la consulta ha llegado a la parte inferior. No hay más decadencia, 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 todas las consultas usan actualmente todos los núcleos dentro de sus respectivos MCE, otras consultas esperarán hasta que los núcleos estén disponibles. A medida que los núcleos están disponibles, se selecciona la consulta con derecho más antigua en función de su tiempo natural transcurrido. El MCE es un límite bajo presión; no garantiza ese número de núcleos en ningún momento.