工作负荷组

  • 项目

工作负荷组允许根据共同的特征将一组管理命令和查询归组到一起，并应用策略来控制每个组中每个请求的限制和请求速率限制。

工作负荷组与工作负荷组策略一起充当群集传入请求的资源调控系统。 请求在发起之后被分类到工作负荷组中。 根据在请求分类策略中定义的用户定义函数进行分类。 请求遵循在整个执行过程中分配给指定工作负荷组的策略。

工作负荷组在群集级别定义，除了三个内置工作负荷组之外，最多还可以定义 10 个自定义组。

注意

如果请求不是查询或管理命令（如流式处理引入请求），那么这些请求不包括在工作负荷组的范围内。

自定义工作负荷组的用例

以下列表涵盖创建自定义工作负荷组的一些常见用例：

  • 防范失控查询：创建一个具有请求限制策略的工作负荷组，以设置查询执行期间的资源使用情况和并行度限制。 例如，此策略可以调节结果集大小、每个迭代器内存、每个节点内存、执行时间和 CPU 资源使用情况。

  • 控制请求速率：创建一个具有请求速率限制策略的工作负荷组，以管理来自特定主体或应用程序的并发请求的行为。 此策略可以限制并发请求数、一段时间内的请求计数以及每个时间段的总 CPU 秒数。 虽然群集具有默认限制（例如查询限制），但你可以根据要求灵活地调整这些限制。

  • 创建共享环境： 假设有 3 个不同的客户团队在共享群集上运行查询和命令，甚至可能访问共享数据库。 如果要根据这些团队的资源使用情况对团队进行计费，可以创建三个不同的工作负荷组，每个组都有独特的限制。 通过这些工作负荷组可以有效地管理和监视每个客户团队的资源使用情况。

  • 监视资源利用率：工作负荷组可帮助你创建有关给定主体或应用程序资源使用量的定期报告。 例如，如果这些主体表示不同的客户端，则此类报告有助于准确计费。 有关详细信息，请参阅按工作负荷组监视请求。

创建和管理工作负荷组

使用以下命令管理工作负荷组及其策略：

工作负荷组策略

可以为每个工作负荷组定义以下策略：

内置工作负荷组

预定义的工作负荷组有：

默认工作负荷组

下列条件下，请求会分类到 default 组中：

  • 没有用于对请求进行分类的标准。
  • 曾经尝试将请求分类到不存在的组。
  • 发生了常规性的分类错误。

可以执行以下操作：

  • 更改用于路由这些请求的条件。
  • 更改适用于 default 工作负荷组的策略。
  • 将请求分类到 default 工作负荷组。

若要监视被分类到 default 工作负荷组的内容，请参阅按工作负荷组监视请求。

注意

某些群集可能具有最大并发查询限制，该限制通过弃用的查询限制策略来定义。 在此类群集中，该限制自动应用于 default 工作负荷组的请求速率限制策略。 虽然旧限制仅影响查询，但新限制适用于所有请求，包括查询和管理命令。

内部工作负荷组

internal 工作负荷组中填入的是仅供内部使用的请求。

你无法：

  • 更改用于路由这些请求的条件。
  • 更改适用于 internal 工作负荷组的策略。
  • 将请求分类到 internal 工作负荷组。

若要监视被分类到 internal 工作负荷组的内容，请参阅按工作负荷组监视请求。

具体化视图工作负荷组

$materialized-views 工作负荷组适用于具体化视图的具体化过程。 有关具体化视图工作原理的详细信息，请参阅具体化视图概述。

可以在工作负荷组的请求限制策略中更改以下值：

  • MaxMemoryPerQueryPerNode
  • MaxMemoryPerIterator
  • MaxFanoutThreadsPercentage
  • MaxFanoutNodesPercentage

注意

你无法更改用于路由这些请求的条件。

按工作负荷组监视请求

系统命令指示请求被分类到的工作负荷组。 可以使用这些命令按工作负荷组对已完成的请求聚合资源利用率。

也可以在 Azure Monitor 见解中查看和分析相同的信息。

相关内容