Fabric 限制策略
当租户的容量消耗比购买的容量资源更多时，就会发生限制。 过多限制可能会导致最终用户体验下降。 Microsoft Fabric 租户可以创建多个容量，并将工作区分配给特定容量以进行计费和大小调整。
限制是在容量级别应用的，这意味着，尽管一个容量或一组工作区可能会因过载而降低性能，但其他容量可能会正常运行。 如果 OneLake 项目等功能在一个容量中产生并被另一个容量消耗，则消耗容量的限制状态决定了对项目的调用是否受到限制。
性能和可靠性之间的平衡
Fabric 旨在通过允许操作访问比分配给容量更多容量单位 (CU) 资源来为客户提供闪电般的性能。 在其他平台上可能需要几分钟才能完成的任务在 Fabric 上只需几秒钟即可完成。 为了避免在操作负载激增时惩罚用户，Fabric 在至少五分钟内平滑或平均操作的 CU 使用量，对于 CU 使用量较高但运行时间较短的请求，甚至更长。 此行为可确保在不遇到限制的情况下获得一致的快速性能。
对于运行时间长且消耗大量 CU 负载的后台操作，Fabric 会在 24 小时内平滑其 CU 使用量。 有了平滑，数据科学家和数据库管理员不需要花时间创建作业计划来在一天中分散 CU 负载，以便防止帐户冻结。 通过 24 小时的 CU 平滑处理，计划作业都可以同时运行，而不会在一天中的任何时间造成任何峰值，并且你可以享受一致的快速性能，而无需浪费时间管理作业计划。
未限制正在进行的操作
当容量进入限制状态时，它只会影响容量开始限制后请求的操作。 允许所有操作（包括在限制开始之前提交的长时间运行的操作）运行直至完成。 这种行为可以确保操作已完成，即使在 CU 使用量激增期间也是如此。
限制触发器和限制阶段
经过平滑处理后，某些帐户在高峰报告时间可能仍会出现 CU 使用量激增的情况。 为了帮助管理这些高峰，管理员可以设置电子邮件警报，以在容量消耗其预配 CU 资源的 100% 时收到通知。 这种模式表明容量可能受益于负载均衡，管理员应考虑增加 SKU 大小。 请务必注意，对于 F SKU，可以随时在管理员设置中手动增加和减少它们。 但是，即使某个容量在充分发挥 CU 潜力的情况下运行，Fabric 也不会应用限制。 此行为可确保用户始终保持快速性能，而不会遇到任何中断。
当容量在接下来的 10 分钟内消耗其所有可用 CU 资源时，将开始第一阶段的限制。 例如，如果购买了 10 个容量单位，然后每分钟消耗 50 个单位，则会创建每分钟 40 个单位的结转。 两分半钟后，将累积 100 个单位的结转（从未来的时段借来）。 此时，如果所有容量在接下来的 10 分钟内已经耗尽，Fabric 将启动其第一级限制，所有新的交互式操作在提交后将延迟 20 秒。 如果结转达到一个完整的小时，则交互请求将被拒绝，但计划的后台操作将继续运行。 如果容量累积了整整 24 小时的结转，则整个容量将被冻结，直到结转付清。
未来的平滑消耗
注意
Microsoft 尝试提高客户使用服务的灵活性，同时平衡管理客户容量使用的需求。 因此，Microsoft 可能会更改或更新 Fabric 限制策略。
| 使用情况 | 策略限制 | 平台策略体验影响 |
|---|---|---|
| 使用 <= 10 分钟 | 超额保护 | 作业可以消耗 10 分钟的未来容量使用，而无需限制。 |
| 10 分钟 < 使用 <= 60 分钟 | 交互式延迟 | 提交时，用户请求的交互式作业延迟 20 秒。 |
| 60 分钟 < 使用 <= 24 小时 | 交互式拒绝 | 用户请求的交互式作业被拒绝。 |
| 使用 > 24 小时 | 后台拒绝 | 所有请求均被拒绝。 |
结转容量使用减少
每当容量具有空闲容量时，系统就会即时交付结转水平。
如果有 100 CU 分钟以及 200 CU 分钟结转，并且没有任何正在运行的操作，则需要两分钟才能还清结转。 在此示例中，系统不受限制，因为有 2 分钟结转。 直到累积结转 10 分钟，限制延迟才会开始。
如果需要更快地支付结转，则可以暂时增加 SKU 大小，以生成应用于结转的更多空闲容量。
限制行为特定于 Fabric
虽然大多数 Fabric 产品遵循前面提到的限制规则，但有一些例外。
例如，Fabric 事件流有许多操作可以在启动后运行数年。 限制新的事件流操作是没有意义的，因此，分配给保持流打开的 CU 资源数量会减少，直到容量再次处于良好状态。
另一个例外是实时智能，如果操作延迟 20 秒，它就不是实时。 因此，实时智能忽略了在 10 分钟结转时延迟 20 秒的第一阶段限制，并等待直到 60 分钟结转的拒绝阶段才开始限制。 此行为可确保用户即使在高需求期间也能继续享受实时性能。
同样，仓库类别中的几乎所有操作都会被报告为后台，以利用 24 小时的活动平滑，从而实现最灵活的使用模式。 将所有数据仓库分类为“后台”可防止 CU 利用率峰值太快触发限制。 某些请求可能会触发一系列以不同方式限制的操作。 这可能会使后台操作作为交互式操作受到限制。
用于限制和平滑的交互式和后台分类
Microsoft Fabric 将操作分为两种类型：交互式和后台。 可以在 Fabric 操作中找到这些操作的说明及其区别。
一些管理员可能会注意到，操作有时被归类为交互式操作，并作为后台平滑处理，反之亦然。 之所以发生这种区别，是因为 Fabric 的限制系统必须在请求开始运行之前应用限制规则。 在作业开始运行并且可以测量 CU 消耗之后，将进行平滑处理。
限制系统尝试在提交时准确对操作进行分类，但有时应用限制后，操作的分类可能会更改。 当操作开始运行时，有关请求的更多详细信息将变为可用。 在模棱两可的情况下，限制系统试图将操作分类为后台，这符合用户的最大利益。
跟踪超额和拒绝的操作
可以通过查看 Microsoft Fabric 容量指标应用中的利用率图表来查看容量是否重载。 超过线的峰值表示重载。 若要进一步调查重载，请钻取到时间点页。 然后，可以查看交互式操作和后台操作，并查看哪些操作负责重载容量。 还可以确定重载事件发生的时间。
由于利用率超过 100% 并不意味着自动限制，因此在评估超额时需要使用限制图表。 从那里，可以打开一个显示燃尽分钟数的表，其是一个包含添加、燃尽和累积百分比等的图表。
若要查看任何过度利用容量的视觉历史记录（包括结转、累积和燃尽利用率数据），请转到“超额”选项卡。可以更改超额视觉比例以显示 10 分钟、60 分钟和 24 小时。 结转只考虑可计费操作。
Microsoft Fabric 容量指标应用向下钻取允许管理员查看在限制事件期间被拒绝的操作。 有关这些操作的信息有限，因为它们从未被允许启动。 管理员可以查看提交请求的产品、用户、操作 ID 和时间。 当请求被拒绝时，最终用户会收到一条错误消息，要求他们稍后再试。
可用于从重载情况恢复的操作
当容量受到限制而处于冻结状态时，如果用户的操作涉及 Fabric 计算资源，则会收到错误消息。 例如，该错误消息可能指示“由于达到容量限制，无法加载模型”。 在这种情况下，可以使用以下策略从冻结状态恢复容量。
- 等到重载状态结束后再发出新请求。
- 升级 F 容量的 SKU。
- 暂停/恢复 F 容量。
- 自动缩放 P 容量。
- 将优先级较低或过度消耗的工作区移出容量。
相关内容
- 安装 Microsoft Fabric 容量指标应用以监视 Fabric 容量。