查询交叉

  • 项目

适用于： SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

查询交错是一种表格模式系统配置，可在高并发方案中提高查询性能。 默认情况下，Analysis Services 表格引擎在 CPU 方面采用先入先出 (FIFO) 方式工作。 例如，使用 FIFO 时，如果收到一个资源昂贵且可能速度缓慢的存储引擎查询，然后是两个其他快速查询，则快速查询可能会被阻止，等待成本高昂的查询完成。 下图显示了此行为，其中显示了 Q1、Q2 和 Q3 作为相应的查询、其持续时间和 CPU 时间。

先进先出

具有 短查询偏差的查询 交错允许并发查询共享 CPU 资源，这意味着速度缓慢的查询后面不会阻止快速查询。 完成所有三个查询所需的时间大致相同，但在示例中，Q2 和 Q3 直到结束才会被阻止。 短查询偏差意味着快速查询（由每个查询在给定时间点已消耗的 CPU 量定义）可以分配比长时间运行的查询更高的资源比例。 在下图中，第 2 季度和 Q3 查询被视为 快速 查询，分配的 CPU 比第 1 季度多。

短查询偏差

查询交错旨在对单独运行的查询产生很少或根本没有性能影响;单个查询仍可使用与 FIFO 模型一样多的 CPU。

重要注意事项

在确定查询交错是否适合你的方案之前，请记住以下事项：

  • 查询交错仅适用于导入模型。 它不会影响 DirectQuery 模型。
  • 查询交错仅考虑 VertiPaq 存储引擎查询消耗的 CPU。 它不适用于公式引擎操作。
  • 单个 DAX 查询可能会导致多个 VertiPaq 存储引擎查询。 DAX 查询根据存储引擎查询消耗的 CPU 被视为 快 或 慢 。 DAX 查询是度量单位。
  • 默认情况下，刷新操作不受查询交错保护。 长时间运行的刷新操作的分类与长时间运行的查询不同。

配置

若要配置查询交错，请设置 Threadpool\SchedulingBehavior 属性。 可以使用以下值指定此属性：

值 说明
-1 自动。 引擎将选择队列类型。
SSAS 2019) 的默认值为 0 ( 先进先出 (FIFO) 。
1 短查询偏差。 在承受压力时，引擎会逐渐限制长时间运行的查询，以支持快速查询。
3 (Azure AS、Power BI、SSAS 2022 及更高版本的默认值) 快速取消的短查询偏差。 提高高并发方案中的用户查询响应时间。 仅适用于 Azure AS、Power BI、SSAS 2022 及更高版本。

目前，只能使用 XMLA 设置 SchedulingBehavior 属性。 在 SQL Server Management Studio 中，以下 XMLA 代码片段将 SchedulingBehavior 属性设置为 1，即短查询偏差。

<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>

重要

需要重启服务器实例。 在Azure Analysis Services中，必须暂停服务器，然后恢复服务器，然后有效地重启。

其他属性

在大多数情况下，SchedulingBehavior 是唯一需要设置的属性。 以下附加属性的默认值应该适用于大多数具有短查询偏差的场景，但如果需要，可以更改它们。 除非通过设置 SchedulingBehavior 属性启用查询交错，否则以下属性 无效 。

ReservedComputeForFastQueries - 为 快速 查询设置保留的逻辑核心数。 所有查询都被认为是 快速 的，直到它们衰减，因为它们已经用完了一定数量的 CPU。 ReservedComputeForFastQueries 是介于 0 和 100 之间的整数。 默认值为 75。

ReservedComputeForFastQueries 的度量单位是核心的百分比。 例如，在具有 20 个核心的服务器上，如果值为 80，则尝试保留 16 个核心，以便 (快速查询，同时不会) 执行刷新操作。 ReservedComputeForFastQueries 向上舍入到最接近的整数核心。 建议不要将此属性值设置为低于 50。 这是因为快速查询可能会被剥夺，这与功能的整体设计相悖。

DecayIntervalCPUTime - 一个整数，表示查询在衰减之前花费的 CPU 时间（以毫秒为单位）。 如果系统处于 CPU 压力之下，则衰减的查询仅限于不为快速查询保留的剩余核心。 默认值为 60,000。 这表示 1 分钟的 CPU 时间，而不是经过的日历时间。

ReservedComputeForProcessing - 设置每个处理 (数据刷新) 操作的保留逻辑核心数。 属性值是介于 0 和 100 之间的整数，默认值为 75 表示。 该值表示由 ReservedComputeForFastQueries 属性确定的核心百分比。 值为 0 (零) 表示处理操作与查询遵循相同的查询交错逻辑，因此可能会衰减。

虽然未执行任何处理操作，但 ReservedComputeForProcessing 不起作用。 例如，如果值为 80，则具有 20 个核心的服务器上的 ReservedComputeForFastQueries 保留 16 个核心以便快速查询。 如果值为 75，则 ReservedComputeForProcessing 将保留 16 个核心中的 12 个用于刷新操作，在处理操作正在运行且占用 CPU 时，保留 4 个用于快速查询。 如下面的 衰减查询 部分所述，其余 4 个核心 (不保留用于快速查询或处理操作，) 仍将用于快速查询和空闲时进行处理。

这些附加属性位于 ResourceGovernance 属性节点下。 在 SQL Server Management Studio中，以下示例 XMLA 代码片段将 DecayIntervalCPUTime 属性设置为低于默认值的值：

<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>

衰减的查询

仅当系统处于 CPU 压力之下时，本部分所述的约束才适用。 例如，如果单个查询是在给定时间在系统中运行的唯一查询，则可以使用所有可用核心，而不管它是否已衰减。

每个查询可能需要许多存储引擎作业。 当池中用于衰减查询的核心可用时，计划程序将基于已用日历时间检查最早的运行查询，以查看它是否已用完其最大核心权利 (MCE) 。 如果没有，则执行其下一个作业。 如果是，则计算下一个最早的查询。 查询 MCE 由它已使用的衰减间隔数决定。 对于使用的每个衰减间隔，MCE 会根据下表中显示的算法进行缩减。 这一过程一直持续到查询完成、超时或 MCE 缩减为单个核心。

在以下示例中，系统具有 32 个核心，并且系统的 CPU 面临压力。

ReservedComputeForFastQueries 为 60 (60%) 。

  • 20 个核心 (19.2 舍入) 保留用于快速查询。
  • 其余 12 个核心分配给衰减的查询。

DecayIntervalCPUTime 为 60,000 (1 分钟的 CPU 时间) 。

查询的生命周期可能如下所示，只要它未超时或完成：

阶段 状态 执行/计划 MCE
0 Fast MCE 是 20 个核心， (保留用于快速查询) 。
对于跨 20 个保留核心的其他 快速 查询，查询以 FIFO 方式执行。
CPU 时间的 1 分钟衰减间隔已用空。		 20 =
MIN (32/2˄0,20)
1 腐烂 MCE 设置为 12 个核心 (12 个未保留用于快速查询) 的剩余核心。
作业根据 MCE 的可用性执行。
1 分钟的 CPU 时间的衰减间隔已用空。		 12 =
MIN (32/2˄1,12)
2 腐烂 MCE 在) 总共 32 个核心 (季度设置为 8 个核心。
作业根据 MCE 的可用性执行。
1 分钟的 CPU 时间的衰减间隔已用空。		 8 =
MIN (32/2˄2,12)
3 腐烂 MCE 设置为 4 个核心。
作业根据 MCE 的可用性执行。
1 分钟的 CPU 时间的衰减间隔已用空。		 4 =
MIN (32/2˄3,12)
4 腐烂 MCE 设置为 2 个核心。
作业根据 MCE 的可用性执行。
1 分钟的 CPU 时间的衰减间隔已用空。		 2 =
MIN (32/2˄4,12)
5 腐烂 MCE 设置为 1 核。
作业根据 MCE 的可用性执行。
衰减间隔不适用，因为查询已触底。
没有进一步衰减，因为已达到至少 1 个核心。		 1 =
MIN (32/2˄5,12)

如果系统受到 CPU 压力，则为每个查询分配的内核不超过其 MCE。 如果所有核心当前都由其各自的 MCE 中的查询使用，则其他查询将等待核心可用。 当核心可用时，会根据已用日历时间选取最早的授权查询。 MCE 是承受压力的上限：它不保证任何时间点的核心数。

另请参阅

Analysis Services 中的服务器属性