Intercalação de consulta

Aplica-se a: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

A intercalação de consulta é uma configuração de sistema de modo tabular que pode melhorar o desempenho da consulta em cenários de alta simultaneidade. Por padrão, o mecanismo tabular do Analysis Services funciona de maneira primeiro a entrar, primeiro a sair (FIFO) em relação à CPU. Com o FIFO, por exemplo, se uma consulta de mecanismo de armazenamento dispendiosa e possivelmente lenta for recebida e seguida por duas consultas rápidas, as consultas rápidas poderão ser bloqueadas aguardando a conclusão da consulta cara. Esse comportamento é mostrado no diagrama a seguir, que mostra o 1º, o 2º e o 3º trimestre como as respectivas consultas, sua duração e o tempo de CPU.

A intercalação de consulta com desvio de consulta curto permite que consultas simultâneas compartilhem recursos de CPU, o que significa que consultas rápidas não são bloqueadas por trás de consultas lentas. O tempo necessário para concluir todas as três consultas ainda é quase o mesmo, mas em nosso exemplo q2 e Q3 não são bloqueados até o final. Desvio de consulta curta significa que consultas rápidas, definidas pela quantidade de CPU que cada consulta já consumiu em um determinado ponto no tempo, podem ser alocadas uma proporção maior de recursos do que as consultas de execução longa. No diagrama a seguir, as consultas do 2º e 3º trimestre são consideradas rápidas e alocadas mais CPU do que o 1º trimestre.

A intercalação de consulta destina-se a ter pouco ou nenhum impacto no desempenho em consultas executadas isoladamente; uma única consulta ainda pode consumir tanta CPU quanto com o modelo FIFO.

Considerações importantes

Antes de determinar se a intercalação de consulta é ideal para seu cenário, tenha o seguinte em mente:

• A intercalação de consulta aplica-se somente a modelos de importação. Ele não afeta os modelos do DirectQuery.
• A intercalação de consulta considera apenas a CPU consumida por consultas do mecanismo de armazenamento VertiPaq. Ele não se aplica a operações do mecanismo de fórmulas.
• Uma única consulta DAX pode resultar em várias consultas do mecanismo de armazenamento VertiPaq. Uma consulta DAX é considerada rápida ou lenta com base na CPU consumida por suas consultas do mecanismo de armazenamento. A consulta DAX é a unidade de medida.
• As operações de atualização são protegidas por padrão contra intercalação de consulta. As operações de atualização de longa execução são categorizadas de forma diferente das consultas de execução longa.

Configurar

Para configurar a intercalação de consulta, defina a propriedade Threadpool\SchedulingBehavior . Essa propriedade pode ser especificada com os seguintes valores:

Valor	Descrição
-1	Automático. O mecanismo escolherá o tipo de fila.
0 (padrão para o SSAS 2019)	Primeiro a entrar, primeiro a sair (FIFO).
1	Desvio de consulta curto. O mecanismo limita gradualmente as consultas de longa execução quando sob pressão em favor de consultas rápidas.
3 (padrão para O AS do Azure, Power BI, SSAS 2022 e posterior)	Desvio de consulta curto com cancelamento rápido. Melhora os tempos de resposta de consulta do usuário em cenários de alta simultaneidade. Aplica-se somente ao Azure AS, Power BI, SSAS 2022 e posterior.

Neste momento, a propriedade SchedulingBehavior só pode ser definida usando XMLA. Em SQL Server Management Studio, o snippet de código XMLA a seguir define a propriedade SchedulingBehavior como 1, desvio de consulta curto.

xmla

<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

Uma reinicialização da instância do servidor é necessária. Em Azure Analysis Services, você deve pausar e retomar o servidor, reiniciando efetivamente.

Propriedades adicionais

Na maioria dos casos, SchedulingBehavior é a única propriedade que você precisa definir. As propriedades adicionais a seguir têm padrões que devem funcionar na maioria dos cenários com viés de consulta curto, no entanto, eles podem ser alterados, se necessário. As propriedades a seguir não têm efeito , a menos que a intercalação de consulta esteja habilitada definindo a propriedade SchedulingBehavior.

ReservedComputeForFastQueries – define o número de núcleos lógicos reservados para consultas rápidas . Todas as consultas são consideradas rápidas até serem decaídas porque usaram uma determinada quantidade de CPU. ReservedComputeForFastQueries é um inteiro entre 0 e 100. O valor padrão é 75.

A unidade de medida para ReservedComputeForFastQueries é o percentual de núcleos. Por exemplo, um valor de 80 em um servidor com 20 núcleos tenta reservar 16 núcleos para consultas rápidas (enquanto nenhuma operação de atualização está sendo executada). ReservedComputeForFastQueries arredonda para cima até o número inteiro mais próximo de núcleos. É recomendável que você não defina esse valor de propriedade abaixo de 50. Isso ocorre porque consultas rápidas podem ser privadas e é contra o design geral do recurso.

DecayIntervalCPUTime - um inteiro que representa o tempo de CPU em milissegundos que uma consulta gasta antes de decair. Se o sistema estiver sob pressão da CPU, as consultas em decomposição serão limitadas aos núcleos restantes não reservados para consultas rápidas. O valor padrão é 60.000. Isso representa 1 minuto de tempo de CPU, não tempo decorrido do calendário.

ReservedComputeForProcessing – define o número de núcleos lógicos reservados para cada operação de processamento (atualização de dados). O valor da propriedade é um inteiro entre 0 e 100, com um valor padrão de 75 expresso. O valor representa um percentual dos núcleos determinados pela propriedade ReservedComputeForFastQueries. Um valor de 0 (zero) significa que as operações de processamento estão sujeitas à mesma lógica de intercalação de consulta que as consultas, portanto, podem ser decaídas.

Embora nenhuma operação de processamento esteja sendo executada, ReservedComputeForProcessing não tem efeito. Por exemplo, com um valor de 80, ReservedComputeForFastQueries em um servidor com 20 núcleos reserva 16 núcleos para consultas rápidas. Com um valor de 75, ReservedComputeForProcessing reservará 12 dos 16 núcleos para operações de atualização, deixando 4 para consultas rápidas enquanto as operações de processamento estão em execução e consumindo a CPU. Conforme descrito na seção Consultas decaídas abaixo, os quatro núcleos restantes (não reservados para consultas rápidas ou operações de processamento) ainda serão usados para consultas rápidas e processamento se estiverem ociosos.

Essas propriedades adicionais estão localizadas no nó propriedades ResourceGovernance . Em SQL Server Management Studio, o snippet de exemplo XMLA a seguir define a propriedade DecayIntervalCPUTime como um valor menor que o padrão:

xmla

<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 decaídas

As restrições descritas nesta seção se aplicam somente se o sistema estiver sob pressão da CPU. Por exemplo, uma única consulta, se for a única em execução no sistema em um determinado momento, poderá consumir todos os núcleos disponíveis, independentemente de ter decaido ou não.

Cada consulta pode exigir muitos trabalhos do mecanismo de armazenamento. Quando um núcleo no pool para consultas em decomposição ficar disponível, o agendador marcar a consulta em execução mais antiga com base no tempo decorrido do calendário para ver se ele já usou seu MCE (Direito Máximo Principal). Se não, seu próximo trabalho será executado. Em caso afirmativo, a próxima consulta mais antiga será avaliada. O MCE da consulta é determinado por quantos intervalos de decaimento ele já usou. Para cada intervalo de decaimento usado, o MCE é reduzido com base no algoritmo mostrado na tabela abaixo. Isso continua até que a consulta seja concluída, o tempo limite ou o MCE seja reduzido a um único núcleo.

No exemplo a seguir, o sistema tem 32 núcleos e a CPU do sistema está sob pressão.

ReservedComputeForFastQueries é 60 (60%).

• 20 núcleos (19,2 arredondados para cima) são reservados para consultas rápidas.
• Os 12 núcleos restantes são alocados para consultas em decomposição.

DecayIntervalCPUTime é 60.000 (1 minuto de tempo de CPU).

O ciclo de vida de uma consulta pode ser o seguinte, desde que não tenha tempo limite ou seja concluído:

Estágio	Status	Execução/agendamento	MCE
0	Rápido	O MCE tem 20 núcleos (reservados para consultas rápidas). A consulta é executada de forma FIFO em relação a outras consultas rápidas nos 20 núcleos reservados. O intervalo de decaimento de 1 minuto de tempo de CPU é usado.	20 = MIN(32/2˄0, 20)
1	Deteriorado	O MCE é definido como 12 núcleos (12 núcleos restantes não reservados para consultas rápidas). Os trabalhos são executados com base na disponibilidade até o MCE. O intervalo de decaimento de 1 minuto de tempo de CPU é usado.	12 = MIN(32/2˄1, 12)
2	Deteriorado	O MCE é definido como 8 núcleos (trimestre de 32 núcleos totais). Os trabalhos são executados com base na disponibilidade até o MCE. O intervalo de decaimento de 1 minuto de tempo de CPU é usado.	8 = MIN(32/2˄2, 12)
3	Deteriorado	O MCE é definido como 4 núcleos. Os trabalhos são executados com base na disponibilidade até o MCE. O intervalo de decaimento de 1 minuto de tempo de CPU é usado.	4 = MIN(32/2˄3, 12)
4	Deteriorado	O MCE é definido como 2 núcleos. Os trabalhos são executados com base na disponibilidade até o MCE. O intervalo de decaimento de 1 minuto de tempo de CPU é usado.	2 = MIN(32/2˄4, 12)
5	Deteriorado	O MCE é definido como 1 núcleo. Os trabalhos são executados com base na disponibilidade até o MCE. O intervalo de decaimento não se aplica, pois a consulta foi inferior. Nenhuma decaimento adicional, pois o mínimo de 1 núcleo é atingido.	1 = MIN(32/2˄5, 12)

Se o sistema estiver sob pressão da CPU, cada consulta não receberá mais núcleos do que seu MCE. Se todos os núcleos forem usados atualmente por consultas em seus respectivos MCEs, outras consultas aguardarão até que os núcleos fiquem disponíveis. À medida que os núcleos ficam disponíveis, a consulta com direito mais antiga com base no tempo decorrido do calendário é selecionada. O MCE é um limite sob pressão; não garante esse número de núcleos em nenhum momento.

Confira também

Propriedades do servidor no Analysis Services