你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
工作负荷组
工作负载组允许你根据共享特征将管理命令和查询集组合在一起,并应用策略来控制每个组的按请求限制和请求速率限制。
工作负载 组与工作负载组策略一起充当资源管理系统,用于传入群集的请求。 启动请求时,它将分类为工作负荷组。 分类基于用户定义的函数,该函数定义为 请求分类策略的一部分。 请求在执行过程中遵循分配给指定工作负荷组的策略。
工作负荷组在群集级别定义,除了三个 内置工作负荷组外,还可以定义最多 10 个自定义组。
注意
不是查询或管理命令的请求(如流式引入请求)不包括在工作负荷组的范围内。
自定义工作负荷组的用例
以下列表介绍了创建自定义工作负荷组的一些常见用例:
防止失控查询: 使用 请求限制策略 创建工作负荷组,以在查询执行期间设置资源使用和并行度限制。 例如,此策略可以调节结果集大小、每个迭代器的内存、每个节点的内存、执行时间和 CPU 资源使用情况。
控制请求速率: 使用 请求速率限制策略 创建工作负荷组,以管理来自特定主体或应用程序的并发请求的行为。 此策略可以限制并发请求数、一段时间内的请求计数以及每个时间段的总 CPU 秒数。 虽然群集具有默认限制(例如 查询限制),但可以根据要求灵活调整这些限制。
创建共享环境: 假设有 3 个不同的客户团队在共享群集上运行查询和命令,甚至可能访问共享数据库。 如果要根据这些团队的资源使用情况为其计费,则可以创建三个不同的工作负荷组,每个组都有唯一的限制。 这些工作负荷组可让你有效地管理和监视每个客户团队的资源使用情况。
监视资源利用率: 工作负荷组可帮助你创建有关给定主体或应用程序资源消耗情况的定期报告。 例如,如果这些主体代表不同的客户端,则此类报告有助于准确计费。 有关详细信息,请参阅 按工作负荷组监视请求。
创建和管理工作负荷组
使用以下命令管理工作负荷组及其策略:
- .alter-merge workload_group
- .create-or-alter workload_group
- .drop workload_group
- .show workload_group
工作负荷组策略
可以为每个工作负荷组定义以下策略:
内置工作负荷组
预定义的工作负荷组有:
默认工作负荷组
在以下情况下, default
请求被分类到组中:
- 没有用于对请求进行分类的标准。
- 曾经尝试将请求分类到不存在的组。
- 发生了常规性的分类错误。
可以执行以下操作:
- 更改用于路由这些请求的条件。
- 更改适用于
default
工作负荷组的策略。 - 将请求分类到
default
工作负荷组。
若要监视分类到 default
工作负荷组的内容,请参阅 按工作负荷组监视请求。
注意
某些群集可能具有通过已弃用的查询限制策略定义的最大并发 查询限制。 在此类群集中,此限制自动应用于 default
工作负荷组 的请求速率限制策略。 虽然旧限制仅影响查询,但新限制适用于所有请求,包括查询和管理命令。
内部工作负荷组
internal
工作负荷组中填入的是仅供内部使用的请求。
你无法:
- 更改用于路由这些请求的条件。
- 更改适用于
internal
工作负荷组的策略。 - 将请求分类到
internal
工作负荷组。
若要监视分类到 internal
工作负荷组的内容,请参阅 按工作负荷组监视请求。
具体化视图工作负荷组
$materialized-views
工作负荷组适用于具体化视图的具体化过程。 有关具体化视图工作原理的详细信息,请参阅 具体化视图概述。
可以在工作负荷组的请求限制策略中更改以下值:
- MaxMemoryPerQueryPerNode
- MaxMemoryPerIterator
- MaxFanoutThreadsPercentage
- MaxFanoutNodesPercentage
注意
你无法更改用于路由这些请求的条件。
按工作负荷组监视请求
系统命令 指示请求分类到的工作负荷组。 可以使用这些命令按工作负荷组聚合已完成请求的资源利用率。
也可以在 Azure Monitor 见解中查看和分析相同的信息。
相关内容
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈