This is an automated email from the ASF dual-hosted git repository.
wangbo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git
The following commit(s) were added to refs/heads/master by this push:
new 7e605831ba2 update 2.1/3.0 document (#1646)
7e605831ba2 is described below
commit 7e605831ba2a04ef2289f1e5ca4098a31b1c7ea6
Author: wangbo <wan...@apache.org>
AuthorDate: Fri Dec 27 18:24:14 2024 +0800
update 2.1/3.0 document (#1646)
## Versions
- [ ] dev
- [x] 3.0
- [x] 2.1
- [ ] 2.0
## Languages
- [x] Chinese
- [ ] English
## Docs Checklist
- [ ] Checked by AI
- [ ] Test Cases Built
---
.../best-practice/group-workload-groups.md | 155 --------
.../best-practice/workload-group-best-practice.md | 436 ---------------------
.../concurrency-control-and-queuing.md | 10 +-
.../workload-management/sql-blocking.md | 55 +--
.../workload-management/workload-group.md | 128 +++---
.../best-practice/group-workload-groups.md | 155 --------
.../best-practice/workload-group-best-practice.md | 436 ---------------------
.../concurrency-control-and-queuing.md | 10 +-
.../workload-management/sql-blocking.md | 87 ++--
.../workload-management/workload-group.md | 128 +++---
10 files changed, 198 insertions(+), 1402 deletions(-)
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/group-workload-groups.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/group-workload-groups.md
deleted file mode 100644
index d36ecc7d41e..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/group-workload-groups.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-{
-"title": "Workload Group 分组功能",
-"language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Workload Group 分组功能常用于当一个 Doris 集群中有多个物理隔离的 BE 集群时，可以将 Workload Group
进行分组，不同分组的 Workload Group 可以绑定到不同的 BE 集群中。
-
-## 推荐用法
-假如目前集群中已有了两个隔离的 BE 子集群，命名为 rg1 和 rg2，且这两个分组之间是完全物理隔离的，数据和计算不会有共享的情况。
-那么比较推荐的配置方式是：
-1. 把 normal group 的资源配置量尽量调小，作为保底的查询分组，比如查询如果不携带任何 Workload Group
信息，那么就会自动使用这个默认的 group，作用是避免查询失败。
-2. 为这两个子集群分别创建对应的 Workload Group，绑定到对应的子集群上。
- 例如，为 rg1 集群创建第一个名为 wg1 的 Workload Group 分组，包含 Workload Group a 和 Workload
Group b 两个 Workload Group。为 rg2 集群创建第二个名为 wg2 的 Workload Group 分组，包含 Workload
Group c 和 Workload Group d。
- 那么最终效果如下：
-
-
-
-操作流程如下：
-
-第一步：把数据副本绑定到 BE 节点，其实也就是完成 rg1 子集群和 rg2
子集群的划分，实现数据副本的隔离，如果集群已经完成了子集群的划分，那么可以跳过这个步骤，直接进入第二步。
-
-1. 把数据副本绑定到 rg1 集群和 rg2 集群
-
- ```sql
- -- 为 rg1 集群建表时需要指定副本分布到 rg1
- create table table1
- (k1 int, k2 int)
- distributed by hash(k1) buckets 1
- properties(
- "replication_allocation"="tag.location.rg1:3"
- )
-
- -- 为 rg2 集群建表时需要指定副本分布到 rg2
- create table table2
- (k1 int, k2 int)
- distributed by hash(k1) buckets 1
- properties(
- "replication_allocation"="tag.location.rg2:3"
- )
- ```
-
-2. 把 BE 节点绑定到 rg1 集群和 rg2 集群
-
- ```sql
- -- 把 be1 和 be2 绑定到 rg1 集群
- alter system modify backend "be1:9050" set ("tag.location" = "rg1");
- alter system modify backend "be2:9050" set ("tag.location" = "rg1");
-
- -- 把 be3 和 be4 绑定到 rg2 集群
- alter system modify backend "be3:9050" set ("tag.location" = "rg2");
- alter system modify backend "be4:9050" set ("tag.location" = "rg2");
- ```
-
-第二步：把 workload group 绑定到 BE 节点
-
-1. 新建 workload group，并把 workload group 分别绑定到 wg1 和 wg2
-
- ```sql
- -- 创建 wg1 分组的 workload group
- create workload group a properties ("memory_limit"="45%","tag"="wg1")
- create workload group b properties ("memory_limit"="45%","tag"="wg1")
-
- -- 创建 wg2 分组的 workload group
- create workload group c properties ("memory_limit"="45%","tag"="wg2")
- create workload group d properties ("memory_limit"="45%","tag"="wg2")
- ```
-
-2. 把 BE 绑定到 wg1 和 wg2，此时 Workload Group a 和 b 只会在 be1 和 be2 上生效。Workload Group
c 和 d 只会在 be3 和 be4 上生效。
- （需要注意的是这里在修改时指定了 tag.location，原因是修改 BE 配置的接口目前暂时不支持增量更新，因此在新加属性时要把存量的属性也携带上）
-
- ```sql
- -- 把 be1 和 be2 绑定到 wg1
- alter system modify backend "be1:9050" set ("tag.location" =
"rg1",tag.workload_group="wg1");
- alter system modify backend "be2:9050" set ("tag.location" =
"rg1",tag.workload_group="wg1");
-
- -- 把 be3 和 be4 绑定到 wg2
- alter system modify backend "be3:9050" set ("tag.location" =
"rg2",tag.workload_group="wg2");
- alter system modify backend "be4:9050" set ("tag.location" =
"rg2",tag.workload_group="wg2");
- ```
-
-3. 调小 normal workload group 的资源用量，作为用户不携带 Workload Group 信息时保底可用的 Workload
Group，可以看到没有为 normal group 指定 tag 属性，因此 normal 可以在所有 BE 生效。
-
- ```sql
- alter workload group normal properties("memory_limit"="1%")
- ```
-
-为了维护更加简单，BE 的 tag.location 和 tag.workload_group 可以使用相同的值，也就是把 rg1 和 wg1
进行合并，rg2 和 wg2 进行合并，统一使用一个名称。比如把 BE 的 tag.workload_group 设置为 rg1，Workload Group
a 和 b 的 tag 也指定为 rg1。
-
-
-## 原理讲解
-### 默认情况
-用户新建了一个 Doris 的集群，集群中只有一个 BE（默认为 default 分组），系统通常默认会创建一个名为 normal 的
group，然后用户又创建了一个 Workload Group A，各自分配 50% 的内存，那么此时集群中 Workload Group 的分布情况如下：
-
-
-
-如果此时添加一个名为 BE2 的新 BE，那么新 BE 中的分布情况如下：
-
-
-
-新增 BE 的 Workload Group 的分布和现有 BE 相同。
-
-### 添加新的 BE 集群
-Doris 支持 BE 物理隔离的功能，当添加新的 BE 节点 (名为 BE3) 并划分到独立的分组时 (新的 BE 分组命名为
vip_group)，Workload Group 的分组如下：
-
-
-
-可以看到默认情况下，系统中的 Workload Group 会在所有的子集群生效，在有些场景下会具有一定的局限性。
-
-### 对 Workload Group 使用分组的功能
-假如集群中有 vip_group 和 default 两个物理隔离的 BE 集群，服务于不同的业务方，这两个业务方对于负载管理可能有不同的诉求。比如
vip_group 可能需要创建更多的 Workload Group，每个 Workload Group 的资源配置和 default 分组的差异也比较大。
-
-此时就需要 Workload Group 分组的功能解决这个问题，比如 vip_group 集群需要创建三个 Workload Group，每个 group
可以获得均等的资源。
-
-
-
-用户新建了三个 workload group，分别名为 vip_wg_1, vip_wg_2, vip_wg_3，并指定 workload group 的
tag 为 vip_wg，含义为这三个 workload group 划分为一个分组，它们的内存资源累加值不能超过 100%。
-同时指定 BE3 的 tag.workload_group 属性为 vip_wg，含义为只有指定了 tag 属性为 vip_wg 的 Workload
Group 才会在 BE3 上生效。
-
-BE1 和 BE2 指定了 tag.workload_group 属性为 default_wg，Workload Group normal 和 A 则指定了
tag 为 default_wg，因此 normal 和 A 只会在 BE1 和 BE2 上生效。
-
-可以简单理解为，BE1 和 BE2 是一个子集群，这个子集群拥有 normal 和 A 两个 Workload Group;BE3
是另一个子集群，这个子集群拥有 vip_wg_1，vip_wg_2 和 vip_wg_3 三个 Workload Group。
-
-:::tip 注意事项
-
-可以注意到上文中 BE 有两个属性，tag.location 和 tag.workload_group，这两个属性没有什么直接的关联。
-tag.location 用于指定 BE 归属于哪个数据副本分组，数据副本也有 location 属性，数据副本会被分发到具有相同 location 属性的
BE，从而完成物理资源的隔离。
-
-tag.workload_group 用于指定 BE 归属于哪个 Workload Group 的分组，Workload Group 也具有 tag
属性用于指定 Workload Group 归属于哪个分组，Workload Group 也只会在具有分组的 BE 上生效。
-Doris 存算一体模式下，数据副本和计算通常是绑定的，因此也比较推荐 BE 的 tag.location 和 tag.workload_group
值是对齐的。
-:::
-
-目前 Workload Group 的 tag 和 Be 的 tag.workload_group 的匹配规则为：
-1. 当 Workload Group 的 tag 为空，那么这个 Workload Group 可以发送给所有的 BE，不管该 BE 是否指定了 tag。
-2. 当 Workload Group 的 tag 不为空，那么 Workload Group 只会发送给具有相同标签的 BE。
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/workload-group-best-practice.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/workload-group-best-practice.md
deleted file mode 100644
index 69317325e7d..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/best-practice/workload-group-best-practice.md
+++ /dev/null
@@ -1,436 +0,0 @@
----
-{
-"title": "Workload Group 最佳实践",
-"language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## 测试内存硬限
-Adhoc 类查询通常输入的 SQL 不确定，使用的内存资源也不确定，因此存在少数查询占用很大内存的风险。
-可以对这类负载可以划分到独立的分组，通过 Workload Group 对内存的硬限的功能，避免突发性的大查询占满所有内存，导致其他查询没有可用内存或者
OOM。
-当这个 Workload Group 的内存使用超过配置的硬限值时，会通过杀死查询的方式释放内存，避免进程内存被打满。
-
-### 测试环境
-1FE，1BE，BE 配置为 96 核，内存大小为 375G。
-
-测试数据集为 clickbench，测试方法为使用 jmeter 起三并发执行 q29。
-
-### 测试不开启 Workload Group 的内存硬限
-
-1. 查看进程使用内存。ps 命令输出第四列代表进程使用的物理内存的用量，单位为 kb，可以看到当前测试负载下，进程的内存使用为 7.7G 左右。
-
- ```sql
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 7896792
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 7929692
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 8101232
- ```
-
-2. 使用 Doris 系统表查看当前 Workload Group 的内存用量，Workload Group 的内存用量为 5.8G 左右。
-
- ```sql
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5797.524360656738 |
- +-------------------+
- 1 row in set (0.01 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5840.246627807617 |
- +-------------------+
- 1 row in set (0.02 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5878.394917488098 |
- +-------------------+
- 1 row in set (0.02 sec)
- ```
-这里可以看到进程的内存使用通常要远大于一个 Workload Group 的内存用量，即使进程内只有一个 Workload Group 在跑，这是因为
Workload Group 只统计了查询和部分导入的内存，进程内的其他组件比如元数据，各种 Cache 的内存是不计算 Workload Group
内的，也不由 Workload Group 管理。
-
-### 测试开启 Workload Group 的内存硬限
-1. 执行 SQL 命令修改内存配置。
-
- ```sql
- alter workload group g2 properties('memory_limit'='0.5%');
- alter workload group g2 properties('enable_memory_overcommit'='false');
- ```
-
-2. 执行同样的测试，查看系统表的内存用量，内存用量为 1.5G 左右。
-
- ```sql
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +--------------------+
- | wg_mem_used_mb |
- +--------------------+
- | 1575.3877239227295 |
- +--------------------+
- 1 row in set (0.02 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +------------------+
- | wg_mem_used_mb |
- +------------------+
- | 1668.77405834198 |
- +------------------+
- 1 row in set (0.01 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +--------------------+
- | wg_mem_used_mb |
- +--------------------+
- | 499.96760272979736 |
- +--------------------+
- 1 row in set (0.01 sec)
- ```
-
-3. 使用 ps 命令查看进程的内存用量，内存用量为 3.8G 左右。
-
- ```sql
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4071364
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4059012
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4057068
- ```
-
-4. 同时客户端会观察到大量由于内存不足导致的查询失败。
-
- ```sql
- 1724074250162,14126,1c_sql,HY000 1105,"java.sql.SQLException: errCode = 2,
detailMessage = (127.0.0.1)[MEM_LIMIT_EXCEEDED]GC wg for hard limit, wg
id:11201, name:g2, used:1.71 GB, limit:1.69 GB, backend:10.16.10.8. cancel top
memory used tracker <Query#Id=4a0689936c444ac8-a0d01a50b944f6e7> consumption
1.71 GB. details:process memory used 3.01 GB exceed soft limit 304.41 GB or sys
available memory 101.16 GB less than warning water mark 12.80 GB., Execute
again after enough memory, det [...]
- ```
-
-这个报错信息中可以看到，Workload Group 使用了 1.7G 的内存，但是 Workload Group 的限制是
1.69G，这里的计算方式是这样的 1.69G = 物理机内存 (375) * mem_limit(be.conf 中的值，默认为 0.9) *
0.5%（Workload Group 的配置）
-也就是说，Workload Group 中配置的内存百分比是基于 Doris 进程可用内存再次进行计算的。
-
-
-### 使用建议
-如上文测试，硬限可以控制 Workload Group
的内存使用，但却是通过杀死查询的方式释放内存，这对用户来说体验会非常不友好，极端情况下可能会导致所有查询都失败。
-因此在生产环境中推荐内存硬限配合查询排队的功能一起使用，可以在限制内存使用的同时保证查询的成功率。
-
-
-
-## CPU 硬限测试
-Doris 的负载大体可以分为三类：
-1. 核心报表查询，通常给公司高层查看报表使用，负载不一定很高，但是对可用性要求较高，这类查询可以划分到一个分组，配置较高优先级的软限，保证 CPU
资源不够时可以获得更多的 CPU 资源。
-2. Adhoc 类查询，这类查询通常偏探索分析，SQL 比较随机，具体的资源用量也比较未知，优先级通常不高。因此可以使用 CPU
硬限进行管理，并配置较低的值，避免占用过多 CPU 资源降低集群可用性。
-3. ETL 类查询，这类查询的 SQL 比较固定，资源用量通常也比较稳定，偶尔会出现上游数据量增长导致资源用量暴涨的情况，因此可以使用 CPU
硬限进行配置。
-
-不同的负载对 CPU 的消耗不一样，用户对响应延时的需求也不一样。当 BE 的 CPU 被用的很满时，可用性会变差，响应延时会变高。比如可能一个 Adhoc
的分析类查询把整个集群的 CPU 打满，导致核心报表的延时变大，影响到了 SLA。所以需要 CPU 隔离机制来对不同的业务进行隔离，保障集群的可用性和 SLA。
-Workload Group 支持 CPU 的软限和硬限，目前比较推荐在线上环境把 Workload Group 配置成硬限。原因是 CPU 的软限通常在
CPU 被打满时才能体现出优先级的作用，但是在 CPU 被用满时，Doris 的内部组件（例如 rpc 组件）以及操作系统可用的 CPU
会减少，此时集群整体的可用性是下降比较严重的，因此生产环境通常需要避免 CPU 资源被打满的情况，当然其他资源也一样，内存资源同理。
-
-
-### 测试环境
-1FE，1BE，96 核机器。
-数据集为 clickbench，测试 sql 为 q29。
-
-### 测试
-1. 使用 jmeter 发起 3 并发查询，把 BE 进程的 CPU 使用压到比较高的使用率，这里测试的机器是 96 核，使用 top 命令看到 BE
进程 CPU 使用率为 7600% 的含义是该进程目前使用中的核数是 76 个。
-
- 
-
-2. 修改使用中的 Workload Group 的 CPU 硬限为 10%。
-
- ```sql
- alter workload group g2 properties('cpu_hard_limit'='10%');
- ```
-
-3. 集群开启硬限模式，此时集群中所有 Group 都会切换为硬限。
-
- ```sql
- ADMIN SET FRONTEND CONFIG ("enable_cpu_hard_limit" = "true");
- ```
-
-4. 重新压测查询负载，可以看到当前进程只能使用 9 到 10 个核，占总核数的 10% 左右。
-
- 
-
-需要注意的是，这里的测试最好使用查询负载会比较能体现出效果，因为如果是高吞吐导入的话，可能会触发 Compaction，使得实际观测的值要比
Workload Group 配置的值大。而 Compaction 的负载目前是没有归入 Workload Group 的管理的。
-
-5. 除了使用 Linux 的系统命令外，还可以通过使用 Doris 的系统表观察 Group 目前的 CPU 使用为 10% 左右。
-
- ```sql
- mysql [information_schema]>select CPU_USAGE_PERCENT from
workload_group_resource_usage where WORKLOAD_GROUP_ID=11201;
- +-------------------+
- | CPU_USAGE_PERCENT |
- +-------------------+
- | 9.57 |
- +-------------------+
- 1 row in set (0.02 sec)
- ```
-
-### 注意事项
-1. 在实际配置的时候，所有 Group 的 CPU 累加值最好不要正好等于
100%，这主要是为了保证低延迟场景的可用性。因为需要让出一部分资源给其他组件使用。当然如果对延迟不是很敏感的场景，期望最高的资源利用率，那么可以考虑所有
Group 的 CPU 累加值配置等于 100%。
-2. 目前 FE 向 BE 同步 Workload Group 元数据的时间间隔为 30 秒，因此对于 Workload Group 的变更最大需要等待
30 秒才能生效。
-
-
-## 测试本地 IO 硬限
-OLAP 系统在做 ETL 或者大的 Adhoc 查询时，需要读取大量的数据，Doris
为了加速数据分析过程，内部会使用多线程并行的方式对多个磁盘文件扫描，会产生巨大的磁盘 IO，就会对其他的查询（比如报表分析）产生影响。
-可以通过 Workload Group 对离线的 ETL 数据处理和在线的报表查询做分组，限制离线数据处理 IO 带宽的方式，降低它对在线报表分析的影响。
-
-### 测试环境
-1FE,1BE, 配置为 96 核。
-
-测试数据集为 clickbench。
-
-### 不开启 IO 硬限测试
-1. 关闭缓存。
-
- ```sql
- // 清空操作系统缓存
- sync; echo 3 > /proc/sys/vm/drop_caches
-
- // 禁用 BE 的 page cache
- disable_storage_page_cache = true
- ```
-
-2. 对 clickbench 的表执行全表扫描，执行单并发查询即可。
-
- ```sql
- set dry_run_query = true;
- select * from hits.hits;
- ```
-
-3. 通过 Doris 的内表查看当前 Group 的最大吞吐为 3GB 每秒。
-
- ```sql
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 1146.6208400726318 |
- +--------------------+
- 1 row in set (0.03 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 3496.2762966156006 |
- +--------------------+
- 1 row in set (0.04 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 2192.7690029144287 |
- +--------------------+
- 1 row in set (0.02 sec)
- ```
-
-4. 使用 pidstat 命令查看进程 IO，图中第一列是进程 id，第二列是读 IO 的吞吐（单位是 kb/s）。可以看到不限制 IO 时，最大吞吐为
2G 每秒。
-
- 
-
-
-### 开启 IO 硬限后测试
-1. 关闭缓存。
-
- ```sql
- // 清空操作系统缓存
- sync; echo 3 > /proc/sys/vm/drop_caches
-
- // 禁用 BE 的 page cache
- disable_storage_page_cache = true
- ```
-
-2. 修改 Workload Group 的配置，限制每秒最大吞吐为 100M。
-
- ```sql
- // 限制当前 Group 的读吞吐为每秒 100M
- alter workload group g2 properties('read_bytes_per_second'='104857600');
- ```
-
-3. 使用 Doris 系统表查看 Workload Group 的最大 IO 吞吐为每秒 98M。
-
- ```sql
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 97.94296646118164 |
- +--------------------+
- 1 row in set (0.03 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 98.37584781646729 |
- +--------------------+
- 1 row in set (0.04 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 98.06641292572021 |
- +--------------------+
- 1 row in set (0.02 sec)
- ```
-
-4. 使用 pid 工具查看进程最大 IO 吞吐为每秒 131M。
-
- 
-
-### 注意事项
-1. 系统表中的 LOCAL_SCAN_BYTES_PER_SECOND 字段代表的是当前 Workload Group 在进程粒度的统计汇总值，比如配置了
12 个文件路径，那么 LOCAL_SCAN_BYTES_PER_SECOND 就是这 12 个文件路径 IO 的最大值，如果期望查看每个文件路径分别的 IO
吞吐，可以在 grafana 上或者 BE 的 bvar 监控查看明细的值。
-
-2. 由于操作系统和 Doris 的 Page Cache 的存在，通过 linux 的 IO 监控脚本看到的 IO 通常要比系统表看到的要小。
-
-
-## 测试远程 IO 限制
-BrokerLoad 和 S3Load 是常用的大批量数据导入方式，用户可以把数据先上传到 HDFS 或者 S3，然后通过 Brokerload 和
S3Load 对数据进行并行导入。Doris 为了加快导入速度，会使用多线程并行的方式从 HDFS/S3 拉取数据，此时会对 HDFS/S3
产生巨大的压力，会导致 HDFS/S3 上运行的别的作业不稳定。
-可以通过 Workload Group 远程 IO 的限制功能来限制导入过程中对 HDFS/S3 的带宽，降低对其他业务的影响。
-
-
-### 测试环境
-1FE，1BE 部署在同一台机器，配置为 16 核 64G 内存。测试数据为 clickbench 数据集，测试前需要把数据集上传到 S3
上。考虑到上传时间的问题，我们只取其中的 1 千万行数据上传，然后使用 tvf 的功能查询 s3 的数据。
-
-上传成功后可以使用命令查看 Schema 信息。
-
- ```sql
- // 查看schema
- DESC FUNCTION s3 (
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-### 测试不限制远程读的 IO
-1. 发起单并发测试，全表扫描 clickbench 表。
-
- ```sql
- // 设置只 scan 数据，不返回结果
- set dry_run_query = true;
-
- // 使用 tvf 查询 s3 的数据
- SELECT * FROM s3(
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-2. 使用系统表查看此时的远程 IO 吞吐。可以看到这个查询的远程 IO 吞吐为 837M 每秒，需要注意的是，这里的实际 IO 吞吐受环境影响较大，如果
BE 所在的机器连接外部存储的带宽比较低，那么可能实际的吞吐会小。
-
- ```sql
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 837 |
- +---------+
- 1 row in set (0.104 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 867 |
- +---------+
- 1 row in set (0.070 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 867 |
- +---------+
- 1 row in set (0.186 sec)
- ```
-
-3. 使用 sar(sar -n DEV 1 3600) 命令查看机器的网络带宽，可以看到机器级别最大网络带宽为 1033M 每秒。
- 输出的第一列为当前机器某个网卡每秒接收的字节数，单位为 KB 每秒。
-
- 
-
-### 测试限制远程读的 IO
-1. 修改 Workload Group 的配置，限制远程读的 IO 吞吐为 100M 每秒。
-
- ```sql
- alter workload group normal
properties('remote_read_bytes_per_second'='104857600');
- ```
-
-2. 发起单并发扫全表的查询。
-
- ```sql
- // 设置只 scan 数据，不返回结果
- set dry_run_query = true;
-
- // 使用 tvf 查询 s3 的数据
- SELECT * FROM s3(
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-3. 使用系统表查看此时的远程读 IO 吞吐，此时的 IO 吞吐在 100M
左右，会有一定的波动，这个波动是受目前算法设计的影响，通常会有一个高峰，但不会持续很长时间，属于正常情况。
-
- ```sql
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 56 |
- +---------+
- 1 row in set (0.010 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 131 |
- +---------+
- 1 row in set (0.009 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 111 |
- +---------+
- 1 row in set (0.009 sec)
- ```
-
-4. 使用 sar 命令（sar -n DEV 1 3600）查看目前的网卡接收流量，第一列为每秒接收的数据量，可以看到最大值变成了 207M 每秒，说明读
IO 的限制是生效的，但是由于 sar 命令看到的是机器级别的流量，因此要比 Doris 统计到的会大一些。
-
- 
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/concurrency-control-and-queuing.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/concurrency-control-and-queuing.md
index 0fb79f00153..c485eff11ce 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/concurrency-control-and-queuing.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/concurrency-control-and-queuing.md
@@ -41,12 +41,12 @@ properties (
**参数说明**
-* max_concurrency：最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到该值时，新来的查询会进入排队的逻辑。
-
-* max_queue_size：查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队，当查询数达到最大时查询会直接失败。
-
-* queue_timeout：查询在排队队列中的超时时间，单位为毫秒，如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
+| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
+|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| max_concurrency | 整型 | 2147483647 | [0, 2147483647] |
可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到最大并发时，新来的查询会进入排队的逻辑。
|
+| max_queue_size | 整型 | 0 | [0, 2147483647] |
可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队。当排队队列已满时，新来的查询会直接失败。
|
+| queue_timeout | 整型 | 0 | [0, 2147483647] |
可选，查询在排队队列中的最大等待时间，单位为毫秒。如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
|
如果集群中目前有1台FE，那么这个配置的含义为，集群中同时运行的查询数最大不超过10个，当最大并发已满时，新来的查询会排队，队列的长度不超过20。查询在队列中排队的时间最长为3s，排队超过3s的查询会直接返回失败给客户端。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/sql-blocking.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/sql-blocking.md
index 8da5b0904d8..a3a0c778ab2 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/sql-blocking.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/sql-blocking.md
@@ -29,14 +29,14 @@ under the License.
在 Doris 内，有两种熔断策略：
- 规划时熔断，即 SQL Block Rule，用于阻止符合特定模式的语句执行。阻止规则对任意的语句生效，包括 DDL 和
DML。通常，阻止规则由数据库管理员（DBA）进行配置，用以提升集群的稳定性。比如，
-
- - 阻止一个查询扫描过多行的数据
-
- - 阻止一个查询扫描过多的分区
-
- - 阻止一个修改全局变量的语句，以防止集群配置被意外的修改。
-
- - 阻止一个通常会占用非常多资源的查询模式
+
+ - 阻止一个查询扫描过多行的数据
+
+ - 阻止一个查询扫描过多的分区
+
+ - 阻止一个修改全局变量的语句，以防止集群配置被意外的修改。
+
+ - 阻止一个通常会占用非常多资源的查询模式
- 运行时熔断，即 Workload Policy，它是在运行时，实时监测查询的执行时间，扫描的数据量，消耗的内存，实现基于规则的查询熔断。
@@ -249,26 +249,31 @@ properties('enabled'='true');
```
在创建 Workload Policy 时需要指定以下内容：
-- Conditions 表示策略触发条件，可以多个 Condition 串联，使用逗号“,”隔开，表示“与”的关系。在上例中 query_time >
1000 表示在查询时间大于 1s 时触发 Policy；
-- Action 表示条件触发时采取的动作，目前一个 Policy 只能定义一个 Action（除
set_session_variable）。在上例中，cancel_query 表示取消查询；
+- Condition 表示策略触发条件，可以多个 Condition 串联，使用逗号“,”隔开，表示“与”的关系。在上例中 query_time >
1000 表示在查询时间大于 1s 时触发 Policy；目前支持的 Conditions 有：
-- Properties，定义了当前 Policy 的属性，包括是否启用和优先级。
+| Conditions | 说明
|
+|-----------------------|---------------------------------------------------------------------|
+| username | 查询携带的用户名，只会在FE触发 set_session_variable Action
|
+| be_scan_rows | 一个 SQL 在单个 BE 进程内 scan 的行数，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值。 |
+| be_scan_bytes | 一个 SQL 在单个 BE 进程内 scan 的字节数，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值，单位是字节。 |
+| query_time | 一个 SQL 在单个 BE 进程上的运行时间，时间单位是毫秒。
|
+| query_be_memory_bytes | 一个 SQL 在单个 BE 进程内使用的内存用量，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值，单位是字节。 |
-一个 Policy 只能指定作用在 FE 或 BE 其中一个组件，无法同时作用在 FE 与 BE 上。这是因为 FE 与 BE 有独立的
Conditions 与 Actions 选项，Policy 不区分 FE 与 BE 组件。下表中列出 Policy 的子句选项：
-
-| 组件 | 子句 | 选项 | 说明 |
-|------|------------|-----|-----|
-| FE | Conditions | username | 当一个查询的 username 为某个值时，就会触发相应的 Action。 |
-| | Actions | set_session_variable | 触发 set session variable 语句。同一个
Policy 可以有多个 set_session_variable 选项。 |
-| BE | Conditions | be_scan_rows | 一个 SQL 在单个 BE 进程内 scan
的行数，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值。
|
-| | | be_scan_bytes | 一个 SQL 在单个 BE 进程内 scan
的字节数，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值，单位是字节。
|
-| | | query_time | 一个 SQL 在单个 BE
进程上的运行时间，时间单位是毫秒。
|
-| | | query_be_memory_bytes | 一个 SQL 在单个 BE
进程内使用的内存用量，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值，单位是字节。
|
-| | Actions | cancel_query | 取消查询。
|
-| FE&BE | properties | enabled | 取值为 true 或
false，默认值为 true，表示当前 Policy 处于启用状态，false 表示当前 Policy 处于禁用状态。
|
-| | | priority | 取值范围为 0 到 100
的正整数，默认值为 0，代表 Policy 的优先级，该值越大，优先级越高。这个属性的主要作用是，当匹配到多个 Policy 时，选择优先级最高的
Policy。
|
-| | | workload_group | 目前一个 Policy
可以绑定一个 workload group，代表这个 Policy 只对某个 workload group 生效。默认为空，代表对所有查询生效。
|
+- Action 表示条件触发时采取的动作，目前一个 Policy 只能定义一个 Action（除
set_session_variable）。在上例中，cancel_query 表示取消查询；目前支持的 Actions 有：
+
+| Actions | 说明
|
+|-----------------------|------------------------------------------------------------------------------------------------------|
+| cancel_query | 取消查询。
|
+| set_session_variable | 触发 set session variable 语句。同一个 policy 可以有多个
set_session_variable 选项，目前只会在 FE 由 username Condition 触发 |
+
+
+- Properties，定义了当前 Policy 的属性，包括是否启用和优先级。
+| Properties | 说明
|
+|-----------------------|----------------------------------------------------------------------------------------------------|
+| enabled | 取值为 true 或 false，默认值为 true，表示当前 Policy 处于启用状态，false
表示当前 Policy 处于禁用状态 |
+| priority | 取值范围为 0 到 100 的正整数，默认值为 0，代表 Policy
的优先级，该值越大，优先级越高。这个属性的主要作用是，当查询匹配到多个 Policy 时，只选择优先级最高的 Policy。 |
+| workload_group | 目前一个 Policy 可以绑定一个 workload group，代表这个 Policy 只对某个
Workload Group 的查询生效。默认为空，代表对所有查询生效。 |
### 将熔断策略绑定 Workload Group
默认情况下，Workload Policy 会对所有支持的查询生效。如果想指定 Policy 只针对与某一个 Workload Group，需要通过
workload_group 选项绑定 Workload Group。语句如下：
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/workload-group.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/workload-group.md
index 015490ed518..419ea650b49 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/workload-group.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-2.1/admin-manual/workload-management/workload-group.md
@@ -46,16 +46,7 @@ Workload Group 是一种进程内实现的对负载进行逻辑隔离的机制
## 配置workload group
### 配置 CGroup 环境
-
-在使用2.1版本的Workload Group功能之前，需要 BE 所在的节点上已经安装好 CGroup 的环境。
-
-用户如果在 2.0 版本使用了 Workload Group 的软限并升级到了 2.1 版本，那么也需要配置 CGroup，否则可能导致CPU软限失效。
-
-目前支持的 CGroup 版本为 CGroup v1 和 CGroup v2。
-
-如果是在容器内使用 CGroup，需要容器具备操作宿主机的权限。
-
-在不配置 CGroup 的情况下，用户可以使用 Workload Group 除 CPU 限制外的所有功能。
+Workload Group 支持对于 CPU ， 内存， IO 资源的管理，其中对于 CPU 的管理依赖 CGroup 组件；如果期望使用
Workload Group 管理CPU资源，那么首先需要进行 CGroup 环境的配置。
以下为CGroup环境配置流程：
@@ -125,7 +116,7 @@ doris_cgroup_cpu_path = /sys/fs/cgroup/doris
1. 建议单台机器上只部署一个 BE 实例，目前的 Workload Group 功能不支持一个机器上部署多个 BE ；
2. 当机器重启之后，CGroup 路径下的所有配置就会清空。如果期望CGroup配置持久化，可以使用 systemd
把操作设置成系统的自定义服务，这样在每次机器重启的时可以自动完成创建和授权操作
3. 如果是在容器内使用 CGroup，需要容器具备操作宿主机的权限。
-:::
+ :::
#### 在容器中使用Workload Group的注意事项
Workload的CPU管理是基于CGroup实现的，如果期望在容器中使用Workload
Group，那么需要以特权模式启动容器，容器内的Doris进程才能具备读写宿主机CGroup文件的权限。
@@ -151,43 +142,68 @@ Query OK, 0 rows affected (0.03 sec)
### Workload Group属性
-* cpu_share: 可选，默认值为 -1。有效值的取值范围是正整数。用于设置 workload group 获取 CPU 时间的多少，可以实现 CPU
资源软隔离。cpu_share 是相对值，表示正在运行的 workload group 可获取 CPU 资源的权重。例如，用户创建了 3 个 workload
group g-a、g-b 和 g-c，cpu_share 分别为 10、30、40，某一时刻 g-a 和 g-b 正在跑任务，而 g-c 没有任务，此时
g-a 可获得 25% (10 / (10 + 30)) 的 CPU 资源，而 g-b 可获得 75% 的 CPU 资源。如果系统只有一个 workload
group 正在运行，则不管其 cpu_share 的值为多少，它都可获取全部的 CPU 资源。
-
-* memory_limit: 可选，默认值 -1，含义为不限制内存使用。有效值的取值范围 1%~100%，用于设置 workload group 可以使用
be 内存的百分比。Workload Group 可用的最大内存，所有 group 的累加值不可以超过 100%，通常与
enable_memory_overcommit 配合使用。如果一个机器的内存为 64G，mem_limit=50%，那么该 group
的实际物理内存=64G * 90%(be conf mem_limit) * 50%= 28.8G，这里的 90% 是 BE 进程级别的 mem_limit
参数，限制整个 BE 进程的内存用量。一个集群中所有 Workload Group 的 memory_limit 的累加值不能超过 100%。
-
-* enable_memory_overcommit: 可选，用于开启 workload group 内存软隔离，默认为 true。如果设置为
false，则该 workload group 为内存硬隔离，系统检测到 workload group 内存使用超出限制后将立即 cancel
组内内存占用最大的若干个任务，以释放超出的内存；如果设置为 true，则该 workload group 为内存软隔离，如果系统有空闲内存资源则该
workload group 在超出 memory_limit 的限制后可继续使用系统内存，在系统总内存紧张时会 cancel
组内内存占用最大的若干个任务，释放部分超出的内存以缓解系统内存压力。建议在有 workload group 开启该配置时，所有 workload group
的 memory_limit 总和低于 100%，剩余部分用于 workload group 内存超发。
-
-* cpu_hard_limit：可选，默认值 -1，含义为不限制CPU上限。取值范围 1%~100%，CPU 硬限制模式下，Workload Group
最大可用的 CPU 百分比，不管当前机器的 CPU 资源是否被用满，Workload Group 的最大 CPU 用量都不能超过 cpu_hard_limit，
- 所有 Workload Group 的 cpu_hard_limit 累加值不能超过 100%。2.1 版本新增属性，2.0版本不支持该功能。
-
-* max_concurrency：可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到该值时，新来的查询会进入排队的逻辑。
-
-* max_queue_size：可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为
0，含义是不排队，当查询数达到最大时查询会直接失败。
-* queue_timeout：可选，查询在排队队列中的超时时间，单位为毫秒，如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
+| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
+|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| cpu_share | 整型 | -1 | [1, 10000] |
可选，CPU软限模式下生效，取值范围和使用的CGroup版本有关，下文有详细描述。cpu_share 代表了 Workload Group
可获得CPU时间的权重，值越大，可获得的CPU时间越多。例如，用户创建了 3 个 Workload Group g-a、g-b 和 g-c，cpu_share
分别为 10、30、40，某一时刻 g-a 和 g-b 正在跑任务，而 g-c 没有任务，此时 g-a 可获得 25% (10 / (10 + 30)) 的
CPU 资源，而 g-b 可获得 75% 的 CPU 资源。如果系统只有一个 Workload Group 正在运行，则不管其 cpu_share
的值为多少，它都可获取全部的 CPU 资源 。 |
+| memory_limit | 浮点 | -1 | (0%, 100%] |
可选，开启内存硬限时代表当前 Workload Group 最大可用内存百分比，默认值代表不限制内存。所有 Workload Group 的
memory_limit 累加值不可以超过 100%，通常与 enable_memory_overcommit 属性配合使用。如果一个机器的内存为
64G，Workload Group 的 memory_limit配置为50%，那么该 group 的实际物理内存=64G * 90% * 50%=
28.8G，这里的90%是 BE 进程可用内存配置的默认值。一个集群中所有 Workload Group 的 memory_limit 的累加值不能超过
100%。 |
+| enable_memory_overcommit | 布尔 | true | true, false |
可选，用于控制当前 Workload Group 的内存限制是硬限还是软限，默认为 true。如果设置为 false，则该 workload group
为内存硬隔离，系统检测到 workload group 内存使用超出限制后将立即 cancel 组内内存占用最大的若干个任务，以释放超出的内存；如果设置为
true，则该 Workload Group 为内存软隔离，如果系统有空闲内存资源则该 Workload Group 在超出 memory_limit
的限制后可继续使用系统内存，在系统总内存紧张时会 cancel 组内内存占用最大的若干个任务，释放部分超出的内存以缓解系统内存压力。建议所有 workload
group 的 memory_limit 总和低于 100%，为BE进程中的其他组件保留一些内存。 |
+| cpu_hard_limit | 整型 | -1 | [1%, 100%] |
可选，CPU 硬限制模式下生效，Workload Group 最大可用 CPU 百分比，不管当前机器的 CPU 资源是否被用满，Workload Group
的最大 CPU 用量都不能超过 cpu_hard_limit，所有 Workload Group 的 cpu_hard_limit 累加值不能超过
100%。2.1 版本新增属性，2.0版本不支持该功能。
|
+| max_concurrency | 整型 | 2147483647 | [0, 2147483647] |
可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到最大并发时，新来的查询会进入排队的逻辑。
|
+| max_queue_size | 整型 | 0 | [0, 2147483647] |
可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队。当排队队列已满时，新来的查询会直接失败。
|
+| queue_timeout | 整型 | 0 | [0, 2147483647] |
可选，查询在排队队列中的最大等待时间，单位为毫秒。如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
|
+| scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，当前 workload group 用于 scan 的线程个数。当该属性为 -1，含义是不生效，此时在BE上的实际取值为 BE
配置中的```doris_scanner_thread_pool_thread_num```。
|
+| max_remote_scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，读外部数据源的scan线程池的最大线程数。当该属性为-1时，实际的线程数由BE自行决定，通常和核数相关。
|
+| min_remote_scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，读外部数据源的scan线程池的最小线程数。当该属性为-1时，实际的线程数由BE自行决定，通常和核数相关。
|
+| tag | 字符串 | 空 | - | 为Workload
Group指定分组标签，相同标签的Workload Group资源累加值不能超过100%；如果期望指定多个值，可以使用英文逗号分隔。
|
+| read_bytes_per_second | 整型 | -1 | [1,
9223372036854775807] |
可选，含义为读Doris内表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。需要注意的是这个值并不绑定磁盘，而是绑定文件夹。比如为Doris配置了2个文件夹用于存放内表数据，那么每个文件夹的最大读IO不会超过该值，如果这2个文件夹都配置到同一块盘上，最大吞吐控制就会变成2倍的read_bytes_per_second。落盘的文件目录也受该值的约束。
|
+| remote_read_bytes_per_second | 整型 | -1 | [1, 9223372036854775807] |
可选，含义为读Doris外表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。
|
-* scan_thread_num：可选，当前 workload group 用于 scan 的线程个数，默认值为 -1，含义是不生效，此时以 be
配置中的 scan 线程数为准。取值为大于 0 的整数。
+:::tip
-*
max_remote_scan_thread_num：可选，读外部数据源的scan线程池的最大线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+1. 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
-*
min_remote_scan_thread_num：可选，读外部数据源的scan线程池的最小线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+2. 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
-* tag：可选，默认为空，为Workload Group指定标签，相同标签的Workload
Group资源累加值不能超过100%，如果期望指定多个值，可以使用英文逗号分隔。
+3. 需要注意 CGroup v1 CGroup v2 版本 CPU 软限默认值是有区别的, CGroup v1 的 CPU
软限默认值为1024，取值范围为2到262144。而 CGroup v2 的 CPU 软限默认值为100，取值范围是1到10000。
+ 如果软限填了一个超出范围的值，这会导致 CPU 软限在BE修改失败。如果在 CGroup v1 的环境上如果按照CGroup
v2的默认值100设置，这可能导致这个workload group的优先级在该机器上是最低的。
+ :::
-*
read_bytes_per_second：可选，含义为读Doris内表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。需要注意的是这个值并不绑定磁盘，而是绑定文件夹。
-
比如为Doris配置了2个文件夹用于存放内表数据，那么每个文件夹的最大读IO不会超过该值，如果这2个文件夹都配置到同一块盘上，最大吞吐控制就会变成2倍的read_bytes_per_second。落盘的文件目录也受该值的约束。
+## 为用户设置Workload Group
+在把用户绑定到某个Workload Group之前，需要先确定该用户是否具有某个 Workload Group 的权限。
+可以使用这个用户查看 information_schema.workload_groups 系统表，返回的结果就是当前用户有权限使用的Workload
Group。
+下面的查询结果代表当前用户可以使用 g1 与 normal Workload Group：
-* remote_read_bytes_per_second：可选，含义为读Doris外表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。
+```sql
+SELECT name FROM information_schema.workload_groups;
++--------+
+| name |
++--------+
+| normal |
+| g1 |
++--------+
+```
-:::tip
+如果无法看到 g1 Workload Group，可以使用ADMIN账户执行 GRANT 语句为用户授权。例如：
+```
+"GRANT USAGE_PRIV ON WORKLOAD GROUP 'g1' TO 'user_1'@'%';"
+```
+这个语句的含义是把名为 g1 的 Workload Group的使用权限授予给名为 user_1 的账户。
+更多授权操作可以参考[grant
语句](../../sql-manual/sql-statements/Account-Management-Statements/GRANT)。
-1. 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
+**两种绑定方式**
+1. 通过设置 user property 将 user 默认绑定到 workload
group，默认为`normal`，需要注意的这里的value不能填空，否则语句会执行失败，如果不知道要设置哪些group，可以设置为`normal`，`normal`为全局默认的group。
+```
+set property 'default_workload_group' = 'g1';
+```
+执行完该语句后，当前用户的查询将默认使用'g1'。
-2. 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
-3. 需要注意 CGroup v1 CGroup v2 版本 CPU 软限默认值是有区别的, CGroup v1 的 CPU
软限默认值为1024，取值范围为2到262144。而 CGroup v2 的 CPU 软限默认值为100，取值范围是1到10000。
- 如果软限填了一个超出范围的值，这会导致 CPU 软限在BE修改失败。是在CGroup v1的环境上如果按照CGroup
v2的默认值100设置，这可能导致这个workload group的优先级在该机器上是最低的。
- :::
+2. 通过 session 变量指定 workload group, 默认为空：
+```
+set workload_group = 'g1';
+```
+当同时使用了两种方式时为用户指定了Workload Group，session 变量的优先级要高于 user property 。
## 查看Workload Group
1. 通过show语句查看
@@ -232,42 +248,6 @@ Query OK, 0 rows affected (0.01 sec)
可以参考：[DROP-WORKLOAD-GROUP](../../sql-manual/sql-statements/Data-Definition-Statements/Drop/DROP-WORKLOAD-GROUP)。
-## 为用户设置Workload Group
-在把用户绑定到某个Workload Group之前，需要先确定该用户是否具有某个 Workload Group 的权限。
-可以使用这个用户查看 information_schema.workload_groups 系统表，返回的结果就是当前用户有权限使用的Workload
Group。
-下面的查询结果代表当前用户可以使用 g1 与 normal Workload Group：
-
-```sql
-SELECT name FROM information_schema.workload_groups;
-+--------+
-| name |
-+--------+
-| normal |
-| g1 |
-+--------+
-```
-
-如果无法看到 g1 Workload Group，可以使用ADMIN账户执行 GRANT 语句为用户授权。例如：
-```
-"GRANT USAGE_PRIV ON WORKLOAD GROUP 'g1' TO 'user_1'@'%';"
-```
-这个语句的含义是把名为 g1 的 Workload Group的使用权限授予给名为 user_1 的账户。
-更多授权操作可以参考[grant
语句](../../sql-manual/sql-statements/Account-Management-Statements/GRANT)。
-
-**两种绑定方式**
-1. 通过设置 user property 将 user 默认绑定到 workload
group，默认为`normal`，需要注意的这里的value不能填空，否则语句会执行失败，如果不知道要设置哪些group，可以设置为`normal`，`normal`为全局默认的group。
-```
-set property 'default_workload_group' = 'g1';
-```
-执行完该语句后，当前用户的查询将默认使用'g1'。
-
-
-2. 通过 session 变量指定 workload group, 默认为空：
-```
-set workload_group = 'g1';
-```
-当同时使用了两种方式时为用户指定了Workload Group，session 变量的优先级要高于 user property 。
-
## CPU 软硬限模式切换的说明
目前 Doris 暂不支持同时运行 CPU 的软限和硬限，一个 Doris 集群在任意时刻只能是 CPU 软限或者 CPU 硬限。
用户可以在两种模式之间进行切换，切换方法如下：
@@ -708,4 +688,4 @@ BrokerLoad 和 S3Load 是常用的大批量数据导入方式，用户可以把
4. 使用 sar 命令（sar -n DEV 1 3600）查看目前的网卡接收流量，第一列为每秒接收的数据量，可以看到最大值变成了 207M 每秒，说明读
IO 的限制是生效的，但是由于 sar 命令看到的是机器级别的流量，因此要比 Doris 统计到的会大一些。
- 
+ 
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/group-workload-groups.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/group-workload-groups.md
deleted file mode 100644
index d36ecc7d41e..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/group-workload-groups.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-{
-"title": "Workload Group 分组功能",
-"language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-Workload Group 分组功能常用于当一个 Doris 集群中有多个物理隔离的 BE 集群时，可以将 Workload Group
进行分组，不同分组的 Workload Group 可以绑定到不同的 BE 集群中。
-
-## 推荐用法
-假如目前集群中已有了两个隔离的 BE 子集群，命名为 rg1 和 rg2，且这两个分组之间是完全物理隔离的，数据和计算不会有共享的情况。
-那么比较推荐的配置方式是：
-1. 把 normal group 的资源配置量尽量调小，作为保底的查询分组，比如查询如果不携带任何 Workload Group
信息，那么就会自动使用这个默认的 group，作用是避免查询失败。
-2. 为这两个子集群分别创建对应的 Workload Group，绑定到对应的子集群上。
- 例如，为 rg1 集群创建第一个名为 wg1 的 Workload Group 分组，包含 Workload Group a 和 Workload
Group b 两个 Workload Group。为 rg2 集群创建第二个名为 wg2 的 Workload Group 分组，包含 Workload
Group c 和 Workload Group d。
- 那么最终效果如下：
-
-
-
-操作流程如下：
-
-第一步：把数据副本绑定到 BE 节点，其实也就是完成 rg1 子集群和 rg2
子集群的划分，实现数据副本的隔离，如果集群已经完成了子集群的划分，那么可以跳过这个步骤，直接进入第二步。
-
-1. 把数据副本绑定到 rg1 集群和 rg2 集群
-
- ```sql
- -- 为 rg1 集群建表时需要指定副本分布到 rg1
- create table table1
- (k1 int, k2 int)
- distributed by hash(k1) buckets 1
- properties(
- "replication_allocation"="tag.location.rg1:3"
- )
-
- -- 为 rg2 集群建表时需要指定副本分布到 rg2
- create table table2
- (k1 int, k2 int)
- distributed by hash(k1) buckets 1
- properties(
- "replication_allocation"="tag.location.rg2:3"
- )
- ```
-
-2. 把 BE 节点绑定到 rg1 集群和 rg2 集群
-
- ```sql
- -- 把 be1 和 be2 绑定到 rg1 集群
- alter system modify backend "be1:9050" set ("tag.location" = "rg1");
- alter system modify backend "be2:9050" set ("tag.location" = "rg1");
-
- -- 把 be3 和 be4 绑定到 rg2 集群
- alter system modify backend "be3:9050" set ("tag.location" = "rg2");
- alter system modify backend "be4:9050" set ("tag.location" = "rg2");
- ```
-
-第二步：把 workload group 绑定到 BE 节点
-
-1. 新建 workload group，并把 workload group 分别绑定到 wg1 和 wg2
-
- ```sql
- -- 创建 wg1 分组的 workload group
- create workload group a properties ("memory_limit"="45%","tag"="wg1")
- create workload group b properties ("memory_limit"="45%","tag"="wg1")
-
- -- 创建 wg2 分组的 workload group
- create workload group c properties ("memory_limit"="45%","tag"="wg2")
- create workload group d properties ("memory_limit"="45%","tag"="wg2")
- ```
-
-2. 把 BE 绑定到 wg1 和 wg2，此时 Workload Group a 和 b 只会在 be1 和 be2 上生效。Workload Group
c 和 d 只会在 be3 和 be4 上生效。
- （需要注意的是这里在修改时指定了 tag.location，原因是修改 BE 配置的接口目前暂时不支持增量更新，因此在新加属性时要把存量的属性也携带上）
-
- ```sql
- -- 把 be1 和 be2 绑定到 wg1
- alter system modify backend "be1:9050" set ("tag.location" =
"rg1",tag.workload_group="wg1");
- alter system modify backend "be2:9050" set ("tag.location" =
"rg1",tag.workload_group="wg1");
-
- -- 把 be3 和 be4 绑定到 wg2
- alter system modify backend "be3:9050" set ("tag.location" =
"rg2",tag.workload_group="wg2");
- alter system modify backend "be4:9050" set ("tag.location" =
"rg2",tag.workload_group="wg2");
- ```
-
-3. 调小 normal workload group 的资源用量，作为用户不携带 Workload Group 信息时保底可用的 Workload
Group，可以看到没有为 normal group 指定 tag 属性，因此 normal 可以在所有 BE 生效。
-
- ```sql
- alter workload group normal properties("memory_limit"="1%")
- ```
-
-为了维护更加简单，BE 的 tag.location 和 tag.workload_group 可以使用相同的值，也就是把 rg1 和 wg1
进行合并，rg2 和 wg2 进行合并，统一使用一个名称。比如把 BE 的 tag.workload_group 设置为 rg1，Workload Group
a 和 b 的 tag 也指定为 rg1。
-
-
-## 原理讲解
-### 默认情况
-用户新建了一个 Doris 的集群，集群中只有一个 BE（默认为 default 分组），系统通常默认会创建一个名为 normal 的
group，然后用户又创建了一个 Workload Group A，各自分配 50% 的内存，那么此时集群中 Workload Group 的分布情况如下：
-
-
-
-如果此时添加一个名为 BE2 的新 BE，那么新 BE 中的分布情况如下：
-
-
-
-新增 BE 的 Workload Group 的分布和现有 BE 相同。
-
-### 添加新的 BE 集群
-Doris 支持 BE 物理隔离的功能，当添加新的 BE 节点 (名为 BE3) 并划分到独立的分组时 (新的 BE 分组命名为
vip_group)，Workload Group 的分组如下：
-
-
-
-可以看到默认情况下，系统中的 Workload Group 会在所有的子集群生效，在有些场景下会具有一定的局限性。
-
-### 对 Workload Group 使用分组的功能
-假如集群中有 vip_group 和 default 两个物理隔离的 BE 集群，服务于不同的业务方，这两个业务方对于负载管理可能有不同的诉求。比如
vip_group 可能需要创建更多的 Workload Group，每个 Workload Group 的资源配置和 default 分组的差异也比较大。
-
-此时就需要 Workload Group 分组的功能解决这个问题，比如 vip_group 集群需要创建三个 Workload Group，每个 group
可以获得均等的资源。
-
-
-
-用户新建了三个 workload group，分别名为 vip_wg_1, vip_wg_2, vip_wg_3，并指定 workload group 的
tag 为 vip_wg，含义为这三个 workload group 划分为一个分组，它们的内存资源累加值不能超过 100%。
-同时指定 BE3 的 tag.workload_group 属性为 vip_wg，含义为只有指定了 tag 属性为 vip_wg 的 Workload
Group 才会在 BE3 上生效。
-
-BE1 和 BE2 指定了 tag.workload_group 属性为 default_wg，Workload Group normal 和 A 则指定了
tag 为 default_wg，因此 normal 和 A 只会在 BE1 和 BE2 上生效。
-
-可以简单理解为，BE1 和 BE2 是一个子集群，这个子集群拥有 normal 和 A 两个 Workload Group;BE3
是另一个子集群，这个子集群拥有 vip_wg_1，vip_wg_2 和 vip_wg_3 三个 Workload Group。
-
-:::tip 注意事项
-
-可以注意到上文中 BE 有两个属性，tag.location 和 tag.workload_group，这两个属性没有什么直接的关联。
-tag.location 用于指定 BE 归属于哪个数据副本分组，数据副本也有 location 属性，数据副本会被分发到具有相同 location 属性的
BE，从而完成物理资源的隔离。
-
-tag.workload_group 用于指定 BE 归属于哪个 Workload Group 的分组，Workload Group 也具有 tag
属性用于指定 Workload Group 归属于哪个分组，Workload Group 也只会在具有分组的 BE 上生效。
-Doris 存算一体模式下，数据副本和计算通常是绑定的，因此也比较推荐 BE 的 tag.location 和 tag.workload_group
值是对齐的。
-:::
-
-目前 Workload Group 的 tag 和 Be 的 tag.workload_group 的匹配规则为：
-1. 当 Workload Group 的 tag 为空，那么这个 Workload Group 可以发送给所有的 BE，不管该 BE 是否指定了 tag。
-2. 当 Workload Group 的 tag 不为空，那么 Workload Group 只会发送给具有相同标签的 BE。
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/workload-group-best-practice.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/workload-group-best-practice.md
deleted file mode 100644
index 69317325e7d..00000000000
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/best-practice/workload-group-best-practice.md
+++ /dev/null
@@ -1,436 +0,0 @@
----
-{
-"title": "Workload Group 最佳实践",
-"language": "zh-CN"
-}
----
-
-<!--
-Licensed to the Apache Software Foundation (ASF) under one
-or more contributor license agreements. See the NOTICE file
-distributed with this work for additional information
-regarding copyright ownership. The ASF licenses this file
-to you under the Apache License, Version 2.0 (the
-"License"); you may not use this file except in compliance
-with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing,
-software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
-KIND, either express or implied. See the License for the
-specific language governing permissions and limitations
-under the License.
--->
-
-## 测试内存硬限
-Adhoc 类查询通常输入的 SQL 不确定，使用的内存资源也不确定，因此存在少数查询占用很大内存的风险。
-可以对这类负载可以划分到独立的分组，通过 Workload Group 对内存的硬限的功能，避免突发性的大查询占满所有内存，导致其他查询没有可用内存或者
OOM。
-当这个 Workload Group 的内存使用超过配置的硬限值时，会通过杀死查询的方式释放内存，避免进程内存被打满。
-
-### 测试环境
-1FE，1BE，BE 配置为 96 核，内存大小为 375G。
-
-测试数据集为 clickbench，测试方法为使用 jmeter 起三并发执行 q29。
-
-### 测试不开启 Workload Group 的内存硬限
-
-1. 查看进程使用内存。ps 命令输出第四列代表进程使用的物理内存的用量，单位为 kb，可以看到当前测试负载下，进程的内存使用为 7.7G 左右。
-
- ```sql
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 7896792
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 7929692
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 2.0 8101232
- ```
-
-2. 使用 Doris 系统表查看当前 Workload Group 的内存用量，Workload Group 的内存用量为 5.8G 左右。
-
- ```sql
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5797.524360656738 |
- +-------------------+
- 1 row in set (0.01 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5840.246627807617 |
- +-------------------+
- 1 row in set (0.02 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +-------------------+
- | wg_mem_used_mb |
- +-------------------+
- | 5878.394917488098 |
- +-------------------+
- 1 row in set (0.02 sec)
- ```
-这里可以看到进程的内存使用通常要远大于一个 Workload Group 的内存用量，即使进程内只有一个 Workload Group 在跑，这是因为
Workload Group 只统计了查询和部分导入的内存，进程内的其他组件比如元数据，各种 Cache 的内存是不计算 Workload Group
内的，也不由 Workload Group 管理。
-
-### 测试开启 Workload Group 的内存硬限
-1. 执行 SQL 命令修改内存配置。
-
- ```sql
- alter workload group g2 properties('memory_limit'='0.5%');
- alter workload group g2 properties('enable_memory_overcommit'='false');
- ```
-
-2. 执行同样的测试，查看系统表的内存用量，内存用量为 1.5G 左右。
-
- ```sql
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +--------------------+
- | wg_mem_used_mb |
- +--------------------+
- | 1575.3877239227295 |
- +--------------------+
- 1 row in set (0.02 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +------------------+
- | wg_mem_used_mb |
- +------------------+
- | 1668.77405834198 |
- +------------------+
- 1 row in set (0.01 sec)
-
- mysql [information_schema]>select MEMORY_USAGE_BYTES / 1024/ 1024 as
wg_mem_used_mb from workload_group_resource_usage where workload_group_id=11201;
- +--------------------+
- | wg_mem_used_mb |
- +--------------------+
- | 499.96760272979736 |
- +--------------------+
- 1 row in set (0.01 sec)
- ```
-
-3. 使用 ps 命令查看进程的内存用量，内存用量为 3.8G 左右。
-
- ```sql
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4071364
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4059012
- [ ~]$ ps -eo pid,comm,%mem,rss | grep 1407481
- 1407481 doris_be 1.0 4057068
- ```
-
-4. 同时客户端会观察到大量由于内存不足导致的查询失败。
-
- ```sql
- 1724074250162,14126,1c_sql,HY000 1105,"java.sql.SQLException: errCode = 2,
detailMessage = (127.0.0.1)[MEM_LIMIT_EXCEEDED]GC wg for hard limit, wg
id:11201, name:g2, used:1.71 GB, limit:1.69 GB, backend:10.16.10.8. cancel top
memory used tracker <Query#Id=4a0689936c444ac8-a0d01a50b944f6e7> consumption
1.71 GB. details:process memory used 3.01 GB exceed soft limit 304.41 GB or sys
available memory 101.16 GB less than warning water mark 12.80 GB., Execute
again after enough memory, det [...]
- ```
-
-这个报错信息中可以看到，Workload Group 使用了 1.7G 的内存，但是 Workload Group 的限制是
1.69G，这里的计算方式是这样的 1.69G = 物理机内存 (375) * mem_limit(be.conf 中的值，默认为 0.9) *
0.5%（Workload Group 的配置）
-也就是说，Workload Group 中配置的内存百分比是基于 Doris 进程可用内存再次进行计算的。
-
-
-### 使用建议
-如上文测试，硬限可以控制 Workload Group
的内存使用，但却是通过杀死查询的方式释放内存，这对用户来说体验会非常不友好，极端情况下可能会导致所有查询都失败。
-因此在生产环境中推荐内存硬限配合查询排队的功能一起使用，可以在限制内存使用的同时保证查询的成功率。
-
-
-
-## CPU 硬限测试
-Doris 的负载大体可以分为三类：
-1. 核心报表查询，通常给公司高层查看报表使用，负载不一定很高，但是对可用性要求较高，这类查询可以划分到一个分组，配置较高优先级的软限，保证 CPU
资源不够时可以获得更多的 CPU 资源。
-2. Adhoc 类查询，这类查询通常偏探索分析，SQL 比较随机，具体的资源用量也比较未知，优先级通常不高。因此可以使用 CPU
硬限进行管理，并配置较低的值，避免占用过多 CPU 资源降低集群可用性。
-3. ETL 类查询，这类查询的 SQL 比较固定，资源用量通常也比较稳定，偶尔会出现上游数据量增长导致资源用量暴涨的情况，因此可以使用 CPU
硬限进行配置。
-
-不同的负载对 CPU 的消耗不一样，用户对响应延时的需求也不一样。当 BE 的 CPU 被用的很满时，可用性会变差，响应延时会变高。比如可能一个 Adhoc
的分析类查询把整个集群的 CPU 打满，导致核心报表的延时变大，影响到了 SLA。所以需要 CPU 隔离机制来对不同的业务进行隔离，保障集群的可用性和 SLA。
-Workload Group 支持 CPU 的软限和硬限，目前比较推荐在线上环境把 Workload Group 配置成硬限。原因是 CPU 的软限通常在
CPU 被打满时才能体现出优先级的作用，但是在 CPU 被用满时，Doris 的内部组件（例如 rpc 组件）以及操作系统可用的 CPU
会减少，此时集群整体的可用性是下降比较严重的，因此生产环境通常需要避免 CPU 资源被打满的情况，当然其他资源也一样，内存资源同理。
-
-
-### 测试环境
-1FE，1BE，96 核机器。
-数据集为 clickbench，测试 sql 为 q29。
-
-### 测试
-1. 使用 jmeter 发起 3 并发查询，把 BE 进程的 CPU 使用压到比较高的使用率，这里测试的机器是 96 核，使用 top 命令看到 BE
进程 CPU 使用率为 7600% 的含义是该进程目前使用中的核数是 76 个。
-
- 
-
-2. 修改使用中的 Workload Group 的 CPU 硬限为 10%。
-
- ```sql
- alter workload group g2 properties('cpu_hard_limit'='10%');
- ```
-
-3. 集群开启硬限模式，此时集群中所有 Group 都会切换为硬限。
-
- ```sql
- ADMIN SET FRONTEND CONFIG ("enable_cpu_hard_limit" = "true");
- ```
-
-4. 重新压测查询负载，可以看到当前进程只能使用 9 到 10 个核，占总核数的 10% 左右。
-
- 
-
-需要注意的是，这里的测试最好使用查询负载会比较能体现出效果，因为如果是高吞吐导入的话，可能会触发 Compaction，使得实际观测的值要比
Workload Group 配置的值大。而 Compaction 的负载目前是没有归入 Workload Group 的管理的。
-
-5. 除了使用 Linux 的系统命令外，还可以通过使用 Doris 的系统表观察 Group 目前的 CPU 使用为 10% 左右。
-
- ```sql
- mysql [information_schema]>select CPU_USAGE_PERCENT from
workload_group_resource_usage where WORKLOAD_GROUP_ID=11201;
- +-------------------+
- | CPU_USAGE_PERCENT |
- +-------------------+
- | 9.57 |
- +-------------------+
- 1 row in set (0.02 sec)
- ```
-
-### 注意事项
-1. 在实际配置的时候，所有 Group 的 CPU 累加值最好不要正好等于
100%，这主要是为了保证低延迟场景的可用性。因为需要让出一部分资源给其他组件使用。当然如果对延迟不是很敏感的场景，期望最高的资源利用率，那么可以考虑所有
Group 的 CPU 累加值配置等于 100%。
-2. 目前 FE 向 BE 同步 Workload Group 元数据的时间间隔为 30 秒，因此对于 Workload Group 的变更最大需要等待
30 秒才能生效。
-
-
-## 测试本地 IO 硬限
-OLAP 系统在做 ETL 或者大的 Adhoc 查询时，需要读取大量的数据，Doris
为了加速数据分析过程，内部会使用多线程并行的方式对多个磁盘文件扫描，会产生巨大的磁盘 IO，就会对其他的查询（比如报表分析）产生影响。
-可以通过 Workload Group 对离线的 ETL 数据处理和在线的报表查询做分组，限制离线数据处理 IO 带宽的方式，降低它对在线报表分析的影响。
-
-### 测试环境
-1FE,1BE, 配置为 96 核。
-
-测试数据集为 clickbench。
-
-### 不开启 IO 硬限测试
-1. 关闭缓存。
-
- ```sql
- // 清空操作系统缓存
- sync; echo 3 > /proc/sys/vm/drop_caches
-
- // 禁用 BE 的 page cache
- disable_storage_page_cache = true
- ```
-
-2. 对 clickbench 的表执行全表扫描，执行单并发查询即可。
-
- ```sql
- set dry_run_query = true;
- select * from hits.hits;
- ```
-
-3. 通过 Doris 的内表查看当前 Group 的最大吞吐为 3GB 每秒。
-
- ```sql
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 1146.6208400726318 |
- +--------------------+
- 1 row in set (0.03 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 3496.2762966156006 |
- +--------------------+
- 1 row in set (0.04 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 2192.7690029144287 |
- +--------------------+
- 1 row in set (0.02 sec)
- ```
-
-4. 使用 pidstat 命令查看进程 IO，图中第一列是进程 id，第二列是读 IO 的吞吐（单位是 kb/s）。可以看到不限制 IO 时，最大吞吐为
2G 每秒。
-
- 
-
-
-### 开启 IO 硬限后测试
-1. 关闭缓存。
-
- ```sql
- // 清空操作系统缓存
- sync; echo 3 > /proc/sys/vm/drop_caches
-
- // 禁用 BE 的 page cache
- disable_storage_page_cache = true
- ```
-
-2. 修改 Workload Group 的配置，限制每秒最大吞吐为 100M。
-
- ```sql
- // 限制当前 Group 的读吞吐为每秒 100M
- alter workload group g2 properties('read_bytes_per_second'='104857600');
- ```
-
-3. 使用 Doris 系统表查看 Workload Group 的最大 IO 吞吐为每秒 98M。
-
- ```sql
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 97.94296646118164 |
- +--------------------+
- 1 row in set (0.03 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 98.37584781646729 |
- +--------------------+
- 1 row in set (0.04 sec)
-
- mysql [information_schema]>select LOCAL_SCAN_BYTES_PER_SECOND / 1024 /
1024 as mb_per_sec from workload_group_resource_usage where
WORKLOAD_GROUP_ID=11201;
- +--------------------+
- | mb_per_sec |
- +--------------------+
- | 98.06641292572021 |
- +--------------------+
- 1 row in set (0.02 sec)
- ```
-
-4. 使用 pid 工具查看进程最大 IO 吞吐为每秒 131M。
-
- 
-
-### 注意事项
-1. 系统表中的 LOCAL_SCAN_BYTES_PER_SECOND 字段代表的是当前 Workload Group 在进程粒度的统计汇总值，比如配置了
12 个文件路径，那么 LOCAL_SCAN_BYTES_PER_SECOND 就是这 12 个文件路径 IO 的最大值，如果期望查看每个文件路径分别的 IO
吞吐，可以在 grafana 上或者 BE 的 bvar 监控查看明细的值。
-
-2. 由于操作系统和 Doris 的 Page Cache 的存在，通过 linux 的 IO 监控脚本看到的 IO 通常要比系统表看到的要小。
-
-
-## 测试远程 IO 限制
-BrokerLoad 和 S3Load 是常用的大批量数据导入方式，用户可以把数据先上传到 HDFS 或者 S3，然后通过 Brokerload 和
S3Load 对数据进行并行导入。Doris 为了加快导入速度，会使用多线程并行的方式从 HDFS/S3 拉取数据，此时会对 HDFS/S3
产生巨大的压力，会导致 HDFS/S3 上运行的别的作业不稳定。
-可以通过 Workload Group 远程 IO 的限制功能来限制导入过程中对 HDFS/S3 的带宽，降低对其他业务的影响。
-
-
-### 测试环境
-1FE，1BE 部署在同一台机器，配置为 16 核 64G 内存。测试数据为 clickbench 数据集，测试前需要把数据集上传到 S3
上。考虑到上传时间的问题，我们只取其中的 1 千万行数据上传，然后使用 tvf 的功能查询 s3 的数据。
-
-上传成功后可以使用命令查看 Schema 信息。
-
- ```sql
- // 查看schema
- DESC FUNCTION s3 (
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-### 测试不限制远程读的 IO
-1. 发起单并发测试，全表扫描 clickbench 表。
-
- ```sql
- // 设置只 scan 数据，不返回结果
- set dry_run_query = true;
-
- // 使用 tvf 查询 s3 的数据
- SELECT * FROM s3(
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-2. 使用系统表查看此时的远程 IO 吞吐。可以看到这个查询的远程 IO 吞吐为 837M 每秒，需要注意的是，这里的实际 IO 吞吐受环境影响较大，如果
BE 所在的机器连接外部存储的带宽比较低，那么可能实际的吞吐会小。
-
- ```sql
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 837 |
- +---------+
- 1 row in set (0.104 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 867 |
- +---------+
- 1 row in set (0.070 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 867 |
- +---------+
- 1 row in set (0.186 sec)
- ```
-
-3. 使用 sar(sar -n DEV 1 3600) 命令查看机器的网络带宽，可以看到机器级别最大网络带宽为 1033M 每秒。
- 输出的第一列为当前机器某个网卡每秒接收的字节数，单位为 KB 每秒。
-
- 
-
-### 测试限制远程读的 IO
-1. 修改 Workload Group 的配置，限制远程读的 IO 吞吐为 100M 每秒。
-
- ```sql
- alter workload group normal
properties('remote_read_bytes_per_second'='104857600');
- ```
-
-2. 发起单并发扫全表的查询。
-
- ```sql
- // 设置只 scan 数据，不返回结果
- set dry_run_query = true;
-
- // 使用 tvf 查询 s3 的数据
- SELECT * FROM s3(
- "URI" = "https://bucketname/1kw.tsv";,
- "s3.access_key"= "ak",
- "s3.secret_key" = "sk",
- "format" = "csv",
- "use_path_style"="true"
- );
- ```
-
-3. 使用系统表查看此时的远程读 IO 吞吐，此时的 IO 吞吐在 100M
左右，会有一定的波动，这个波动是受目前算法设计的影响，通常会有一个高峰，但不会持续很长时间，属于正常情况。
-
- ```sql
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 56 |
- +---------+
- 1 row in set (0.010 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 131 |
- +---------+
- 1 row in set (0.009 sec)
-
- MySQL [(none)]> select cast(REMOTE_SCAN_BYTES_PER_SECOND/1024/1024 as int)
as read_mb from information_schema.workload_group_resource_usage;
- +---------+
- | read_mb |
- +---------+
- | 111 |
- +---------+
- 1 row in set (0.009 sec)
- ```
-
-4. 使用 sar 命令（sar -n DEV 1 3600）查看目前的网卡接收流量，第一列为每秒接收的数据量，可以看到最大值变成了 207M 每秒，说明读
IO 的限制是生效的，但是由于 sar 命令看到的是机器级别的流量，因此要比 Doris 统计到的会大一些。
-
- 
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/concurrency-control-and-queuing.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/concurrency-control-and-queuing.md
index 0fb79f00153..c485eff11ce 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/concurrency-control-and-queuing.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/concurrency-control-and-queuing.md
@@ -41,12 +41,12 @@ properties (
**参数说明**
-* max_concurrency：最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到该值时，新来的查询会进入排队的逻辑。
-
-* max_queue_size：查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队，当查询数达到最大时查询会直接失败。
-
-* queue_timeout：查询在排队队列中的超时时间，单位为毫秒，如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
+| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
+|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| max_concurrency | 整型 | 2147483647 | [0, 2147483647] |
可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到最大并发时，新来的查询会进入排队的逻辑。
|
+| max_queue_size | 整型 | 0 | [0, 2147483647] |
可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队。当排队队列已满时，新来的查询会直接失败。
|
+| queue_timeout | 整型 | 0 | [0, 2147483647] |
可选，查询在排队队列中的最大等待时间，单位为毫秒。如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
|
如果集群中目前有1台FE，那么这个配置的含义为，集群中同时运行的查询数最大不超过10个，当最大并发已满时，新来的查询会排队，队列的长度不超过20。查询在队列中排队的时间最长为3s，排队超过3s的查询会直接返回失败给客户端。
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/sql-blocking.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/sql-blocking.md
index 60a619ef6d3..a3a0c778ab2 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/sql-blocking.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/sql-blocking.md
@@ -18,25 +18,25 @@ with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
-"AS IS" BASIS, WITHOUT WARRANTIES OR ConditionS OF ANY
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
-查询熔断是一种保护机制，用于防止长时间运行或消耗过多资源的查询对系统产生负面影响。当查询超过预设的资源或时间限制时，熔断机制会自动终止该查询，以避免对系统性能、资源使用以及其他查询造成不利影响。这种机制确保了集群在多用户环境下的稳定性，防止单个查询导致系统资源耗尽、响应变慢或发生死锁，从而提高整体的可用性和效率。
+查询熔断是一种保护机制，用于防止长时间运行或消耗过多资源的查询对系统产生负面影响。当查询超过预设的资源或时间限制时，熔断机制会自动终止该查询，以避免对系统性能、资源使用以及其他查询造成不利影响。这种机制确保了集群在多用户环境下的稳定性，防止单个查询导致系统资源耗尽、响应变慢，从而提高整体的可用性和效率。
在 Doris 内，有两种熔断策略：
- 规划时熔断，即 SQL Block Rule，用于阻止符合特定模式的语句执行。阻止规则对任意的语句生效，包括 DDL 和
DML。通常，阻止规则由数据库管理员（DBA）进行配置，用以提升集群的稳定性。比如，
-
- - 阻止一个查询扫描过多行的数据
-
- - 阻止一个查询扫描过多的分区
-
- - 阻止一个修改全局变量的语句，以防止集群配置被意外的修改。
-
- - 阻止一个通常会占用非常多资源的查询模式
+
+ - 阻止一个查询扫描过多行的数据
+
+ - 阻止一个查询扫描过多的分区
+
+ - 阻止一个修改全局变量的语句，以防止集群配置被意外的修改。
+
+ - 阻止一个通常会占用非常多资源的查询模式
- 运行时熔断，即 Workload Policy，它是在运行时，实时监测查询的执行时间，扫描的数据量，消耗的内存，实现基于规则的查询熔断。
@@ -213,20 +213,20 @@ A：可以。修改阻止规则，将其属性中的"enable"改为"false"即可
#### Q：阻止规则中的正则表达式使用哪种规范？
A：阻止规则的正则表达式使用 java 的正则表达式规范。常用表达式可以参考 SQL 语法手册。完整的手册可以参考
https://docs.oracle.com/javase/8/docs/api/java/util/regex/Pattern.html
-## Workload Group Policy
+## Workload Policy
-### 注意事项
-- 同一个 Policy 的 Condition 和 Action 要么都是 FE 的，要么都是 BE 的，比如 set_session_variable
和 cancel_query 无法配置到同一个 Policy 中。Condition be_scan_rows 和 Condition username
无法配置到同一个 Policy 中。
-- 由于目前的 Policy 是异步线程以固定时间间隔执行的，因此策略的生效存在一定的滞后性。比如用户配置了 scan 行数大于 100
万就取消查询的策略，如果此时集群资源比较空闲，那么有可能在取消策略生效之前查询就已经结束了。目前这个时间间隔为
500ms，这意味着运行时间过短的查询可能会绕过策略的检查。
-- 当前支持的负载类型包括 select/insert select/stream load/broker load/routine load。
-- 一个查询可能匹配到多个 Policy，但是只有优先级最高的 Policy 会生效。
-- 目前不支持 Action 和 Condition 的修改，只能通过删除新建的方式修改。
+SQL Block Rule
是一种在规划时进行熔断的配置，但是由于规划中代价的计算可能不准确（尤其是针对一些非常复杂的查询时，更加难以准确估算），所以会导致规则不生效或者误判。Workload
Policy
弥补了这个缺陷，它可以在查询运行时对一些指标进行实时的监测，对运行时状态不符合预期的查询进行熔断，避免不符合预期的大查询占用过多资源从而影响集群的稳定性，常用的运行时监控指标如下：
+
+* 查询执行时间
+* 查询在单BE上的扫描行数
+* 查询在单BE上的扫描行数扫描字节数
+* 查询的在单BE上的内存使用
-### 熔断策略范围
+### 版本说明
自 Doris 2.1 版本起，可以通过 Workload Policy 可以实现大查询的熔断。
-| 版本 | 2.1 |
+| 版本 | 2.1 |
|--------------------|-----|
| select | √ |
| insert into select | √ |
@@ -234,7 +234,7 @@ A：阻止规则的正则表达式使用 java 的正则表达式规范。常用
| stream load | √ |
| routine load | √ |
| backup | X |
-| compAction | X |
+| compaction | X |
### 创建熔断策略
使用 `CREATE WORKLOAD Policy` 命令可以创建资源管理策略。
@@ -249,27 +249,32 @@ properties('enabled'='true');
```
在创建 Workload Policy 时需要指定以下内容：
-- Conditions 表示策略触发条件，可以多个 Condition 串联，使用逗号“,”隔开，表示“与”的关系。在上例中 query_time >
1000 表示在查询时间大于 1s 时触发 Policy；
-- Action 表示条件触发时采取的动作，目前一个 Policy 只能定义一个 Action（除
set_session_variable）。在上例中，cancel_query 表示取消查询；
+- Condition 表示策略触发条件，可以多个 Condition 串联，使用逗号“,”隔开，表示“与”的关系。在上例中 query_time >
1000 表示在查询时间大于 1s 时触发 Policy；目前支持的 Conditions 有：
-- Properties，定义了当前 Policy 的属性，包括是否启用和优先级。
+| Conditions | 说明
|
+|-----------------------|---------------------------------------------------------------------|
+| username | 查询携带的用户名，只会在FE触发 set_session_variable Action
|
+| be_scan_rows | 一个 SQL 在单个 BE 进程内 scan 的行数，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值。 |
+| be_scan_bytes | 一个 SQL 在单个 BE 进程内 scan 的字节数，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值，单位是字节。 |
+| query_time | 一个 SQL 在单个 BE 进程上的运行时间，时间单位是毫秒。
|
+| query_be_memory_bytes | 一个 SQL 在单个 BE 进程内使用的内存用量，如果这个 SQL 在 BE
上是多并发执行，那么就是多个并发的累加值，单位是字节。 |
-一个 Policy 只能指定作用在 FE 或 BE 其中一个组件，无法同时作用在 FE 与 BE 上。这是因为 FE 与 BE 有独立的
Conditions 与 Actions 选项，Policy 不区分 FE 与 BE 组件。下表中列出 Policy 的子句选项：
+- Action 表示条件触发时采取的动作，目前一个 Policy 只能定义一个 Action（除
set_session_variable）。在上例中，cancel_query 表示取消查询；目前支持的 Actions 有：
-| 组件 | 子句 | 选项 | 说明 |
-|------|------------|-----|-----|
-| FE | Conditions | username | 当一个查询的 username 为某个值时，就会触发相应的 Action。 |
-| | Actions | set_session_variable | 触发 set session variable 语句。同一个
Policy 可以有多个 set_session_variable 选项。 |
-| BE | Conditions | be_scan_rows | 一个 SQL 在单个 BE 进程内 scan
的行数，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值。
|
-| | | be_scan_bytes | 一个 SQL 在单个 BE 进程内 scan
的字节数，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值，单位是字节。
|
-| | | query_time | 一个 SQL 在单个 BE
进程上的运行时间，时间单位是毫秒。
|
-| | | query_be_memory_bytes | 一个 SQL 在单个 BE
进程内使用的内存用量，如果这个 SQL 在 BE 上是多并发执行，那么就是多个并发的累加值，单位是字节。
|
-| | Actions | cancel_query | 取消查询。
|
-| FE&BE | properties | enabled | 取值为 true 或
false，默认值为 true，表示当前 Policy 处于启用状态，false 表示当前 Policy 处于禁用状态。
|
-| | | priority | 取值范围为 0 到 100
的正整数，默认值为 0，代表 Policy 的优先级，该值越大，优先级越高。这个属性的主要作用是，当匹配到多个 Policy 时，选择优先级最高的
Policy。
|
-| | | workload_group | 目前一个 Policy
可以绑定一个 workload group，代表这个 Policy 只对某个 workload group 生效。默认为空，代表对所有查询生效。
|
+| Actions | 说明
|
+|-----------------------|------------------------------------------------------------------------------------------------------|
+| cancel_query | 取消查询。
|
+| set_session_variable | 触发 set session variable 语句。同一个 policy 可以有多个
set_session_variable 选项，目前只会在 FE 由 username Condition 触发 |
+- Properties，定义了当前 Policy 的属性，包括是否启用和优先级。
+
+| Properties | 说明
|
+|-----------------------|----------------------------------------------------------------------------------------------------|
+| enabled | 取值为 true 或 false，默认值为 true，表示当前 Policy 处于启用状态，false
表示当前 Policy 处于禁用状态 |
+| priority | 取值范围为 0 到 100 的正整数，默认值为 0，代表 Policy
的优先级，该值越大，优先级越高。这个属性的主要作用是，当查询匹配到多个 Policy 时，只选择优先级最高的 Policy。 |
+| workload_group | 目前一个 Policy 可以绑定一个 workload group，代表这个 Policy 只对某个
Workload Group 的查询生效。默认为空，代表对所有查询生效。 |
+
### 将熔断策略绑定 Workload Group
默认情况下，Workload Policy 会对所有支持的查询生效。如果想指定 Policy 只针对与某一个 Workload Group，需要通过
workload_group 选项绑定 Workload Group。语句如下：
@@ -280,6 +285,13 @@ Actions(cancel_query)
properties('workload_group'='normal')
```
+### 注意事项
+- 同一个 Policy 的 Condition 和 Action 要么都是 FE 的，要么都是 BE 的，比如 set_session_variable
和 cancel_query 无法配置到同一个 Policy 中。Condition be_scan_rows 和 Condition username
无法配置到同一个 Policy 中。
+- 由于目前的 Policy 是异步线程以固定时间间隔执行的，因此策略的生效存在一定的滞后性。比如用户配置了 scan 行数大于 100
万就取消查询的策略，如果此时集群资源比较空闲，那么有可能在取消策略生效之前查询就已经结束了。目前这个时间间隔为
500ms，这意味着运行时间过短的查询可能会绕过策略的检查。
+- 当前支持的负载类型包括 select/insert select/stream load/broker load/routine load。
+- 一个查询可能匹配到多个 Policy，但是只有优先级最高的 Policy 会生效。
+- 目前不支持 Action 和 Condition 的修改，只能通过删除新建的方式修改。
+
### Workload Policy 效果演示
#### 1 session 变量修改测试
@@ -343,5 +355,6 @@ Actions(cancel_query)
再次执行 SQL 可以看到 SQL 执行会直接报错
```sql
mySQL [hits]>SELECT REGEXP_REPLACE(Referer, '^https?://(?:www\.)?([^/]+)/.*$',
'\1') AS k, AVG(length(Referer)) AS l, COUNT(*) AS c, MIN(Referer) FROM hits
WHERE Referer <> '' GROUP BY k HAVING COUNT(*) > 100000 ORDER BY l DESC LIMIT
25;
-ERROR 1105 (HY000): errCode = 2, detailMessage = (10.16.10.8)[CANCELLED]query
cancelled by workload Policy,id:12345
+ERROR 1105 (HY000): errCode = 2, detailMessage = (127.0.0.1)[CANCELLED]query
cancelled by workload Policy,id:12345
```
+
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/workload-group.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/workload-group.md
index 015490ed518..419ea650b49 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/workload-group.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.0/admin-manual/workload-management/workload-group.md
@@ -46,16 +46,7 @@ Workload Group 是一种进程内实现的对负载进行逻辑隔离的机制
## 配置workload group
### 配置 CGroup 环境
-
-在使用2.1版本的Workload Group功能之前，需要 BE 所在的节点上已经安装好 CGroup 的环境。
-
-用户如果在 2.0 版本使用了 Workload Group 的软限并升级到了 2.1 版本，那么也需要配置 CGroup，否则可能导致CPU软限失效。
-
-目前支持的 CGroup 版本为 CGroup v1 和 CGroup v2。
-
-如果是在容器内使用 CGroup，需要容器具备操作宿主机的权限。
-
-在不配置 CGroup 的情况下，用户可以使用 Workload Group 除 CPU 限制外的所有功能。
+Workload Group 支持对于 CPU ， 内存， IO 资源的管理，其中对于 CPU 的管理依赖 CGroup 组件；如果期望使用
Workload Group 管理CPU资源，那么首先需要进行 CGroup 环境的配置。
以下为CGroup环境配置流程：
@@ -125,7 +116,7 @@ doris_cgroup_cpu_path = /sys/fs/cgroup/doris
1. 建议单台机器上只部署一个 BE 实例，目前的 Workload Group 功能不支持一个机器上部署多个 BE ；
2. 当机器重启之后，CGroup 路径下的所有配置就会清空。如果期望CGroup配置持久化，可以使用 systemd
把操作设置成系统的自定义服务，这样在每次机器重启的时可以自动完成创建和授权操作
3. 如果是在容器内使用 CGroup，需要容器具备操作宿主机的权限。
-:::
+ :::
#### 在容器中使用Workload Group的注意事项
Workload的CPU管理是基于CGroup实现的，如果期望在容器中使用Workload
Group，那么需要以特权模式启动容器，容器内的Doris进程才能具备读写宿主机CGroup文件的权限。
@@ -151,43 +142,68 @@ Query OK, 0 rows affected (0.03 sec)
### Workload Group属性
-* cpu_share: 可选，默认值为 -1。有效值的取值范围是正整数。用于设置 workload group 获取 CPU 时间的多少，可以实现 CPU
资源软隔离。cpu_share 是相对值，表示正在运行的 workload group 可获取 CPU 资源的权重。例如，用户创建了 3 个 workload
group g-a、g-b 和 g-c，cpu_share 分别为 10、30、40，某一时刻 g-a 和 g-b 正在跑任务，而 g-c 没有任务，此时
g-a 可获得 25% (10 / (10 + 30)) 的 CPU 资源，而 g-b 可获得 75% 的 CPU 资源。如果系统只有一个 workload
group 正在运行，则不管其 cpu_share 的值为多少，它都可获取全部的 CPU 资源。
-
-* memory_limit: 可选，默认值 -1，含义为不限制内存使用。有效值的取值范围 1%~100%，用于设置 workload group 可以使用
be 内存的百分比。Workload Group 可用的最大内存，所有 group 的累加值不可以超过 100%，通常与
enable_memory_overcommit 配合使用。如果一个机器的内存为 64G，mem_limit=50%，那么该 group
的实际物理内存=64G * 90%(be conf mem_limit) * 50%= 28.8G，这里的 90% 是 BE 进程级别的 mem_limit
参数，限制整个 BE 进程的内存用量。一个集群中所有 Workload Group 的 memory_limit 的累加值不能超过 100%。
-
-* enable_memory_overcommit: 可选，用于开启 workload group 内存软隔离，默认为 true。如果设置为
false，则该 workload group 为内存硬隔离，系统检测到 workload group 内存使用超出限制后将立即 cancel
组内内存占用最大的若干个任务，以释放超出的内存；如果设置为 true，则该 workload group 为内存软隔离，如果系统有空闲内存资源则该
workload group 在超出 memory_limit 的限制后可继续使用系统内存，在系统总内存紧张时会 cancel
组内内存占用最大的若干个任务，释放部分超出的内存以缓解系统内存压力。建议在有 workload group 开启该配置时，所有 workload group
的 memory_limit 总和低于 100%，剩余部分用于 workload group 内存超发。
-
-* cpu_hard_limit：可选，默认值 -1，含义为不限制CPU上限。取值范围 1%~100%，CPU 硬限制模式下，Workload Group
最大可用的 CPU 百分比，不管当前机器的 CPU 资源是否被用满，Workload Group 的最大 CPU 用量都不能超过 cpu_hard_limit，
- 所有 Workload Group 的 cpu_hard_limit 累加值不能超过 100%。2.1 版本新增属性，2.0版本不支持该功能。
-
-* max_concurrency：可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到该值时，新来的查询会进入排队的逻辑。
-
-* max_queue_size：可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为
0，含义是不排队，当查询数达到最大时查询会直接失败。
-* queue_timeout：可选，查询在排队队列中的超时时间，单位为毫秒，如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
+| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
+|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| cpu_share | 整型 | -1 | [1, 10000] |
可选，CPU软限模式下生效，取值范围和使用的CGroup版本有关，下文有详细描述。cpu_share 代表了 Workload Group
可获得CPU时间的权重，值越大，可获得的CPU时间越多。例如，用户创建了 3 个 Workload Group g-a、g-b 和 g-c，cpu_share
分别为 10、30、40，某一时刻 g-a 和 g-b 正在跑任务，而 g-c 没有任务，此时 g-a 可获得 25% (10 / (10 + 30)) 的
CPU 资源，而 g-b 可获得 75% 的 CPU 资源。如果系统只有一个 Workload Group 正在运行，则不管其 cpu_share
的值为多少，它都可获取全部的 CPU 资源 。 |
+| memory_limit | 浮点 | -1 | (0%, 100%] |
可选，开启内存硬限时代表当前 Workload Group 最大可用内存百分比，默认值代表不限制内存。所有 Workload Group 的
memory_limit 累加值不可以超过 100%，通常与 enable_memory_overcommit 属性配合使用。如果一个机器的内存为
64G，Workload Group 的 memory_limit配置为50%，那么该 group 的实际物理内存=64G * 90% * 50%=
28.8G，这里的90%是 BE 进程可用内存配置的默认值。一个集群中所有 Workload Group 的 memory_limit 的累加值不能超过
100%。 |
+| enable_memory_overcommit | 布尔 | true | true, false |
可选，用于控制当前 Workload Group 的内存限制是硬限还是软限，默认为 true。如果设置为 false，则该 workload group
为内存硬隔离，系统检测到 workload group 内存使用超出限制后将立即 cancel 组内内存占用最大的若干个任务，以释放超出的内存；如果设置为
true，则该 Workload Group 为内存软隔离，如果系统有空闲内存资源则该 Workload Group 在超出 memory_limit
的限制后可继续使用系统内存，在系统总内存紧张时会 cancel 组内内存占用最大的若干个任务，释放部分超出的内存以缓解系统内存压力。建议所有 workload
group 的 memory_limit 总和低于 100%，为BE进程中的其他组件保留一些内存。 |
+| cpu_hard_limit | 整型 | -1 | [1%, 100%] |
可选，CPU 硬限制模式下生效，Workload Group 最大可用 CPU 百分比，不管当前机器的 CPU 资源是否被用满，Workload Group
的最大 CPU 用量都不能超过 cpu_hard_limit，所有 Workload Group 的 cpu_hard_limit 累加值不能超过
100%。2.1 版本新增属性，2.0版本不支持该功能。
|
+| max_concurrency | 整型 | 2147483647 | [0, 2147483647] |
可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到最大并发时，新来的查询会进入排队的逻辑。
|
+| max_queue_size | 整型 | 0 | [0, 2147483647] |
可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队。当排队队列已满时，新来的查询会直接失败。
|
+| queue_timeout | 整型 | 0 | [0, 2147483647] |
可选，查询在排队队列中的最大等待时间，单位为毫秒。如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队，查询进入队列后立即返回失败。
|
+| scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，当前 workload group 用于 scan 的线程个数。当该属性为 -1，含义是不生效，此时在BE上的实际取值为 BE
配置中的```doris_scanner_thread_pool_thread_num```。
|
+| max_remote_scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，读外部数据源的scan线程池的最大线程数。当该属性为-1时，实际的线程数由BE自行决定，通常和核数相关。
|
+| min_remote_scan_thread_num | 整型 | -1 | [1, 2147483647] |
可选，读外部数据源的scan线程池的最小线程数。当该属性为-1时，实际的线程数由BE自行决定，通常和核数相关。
|
+| tag | 字符串 | 空 | - | 为Workload
Group指定分组标签，相同标签的Workload Group资源累加值不能超过100%；如果期望指定多个值，可以使用英文逗号分隔。
|
+| read_bytes_per_second | 整型 | -1 | [1,
9223372036854775807] |
可选，含义为读Doris内表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。需要注意的是这个值并不绑定磁盘，而是绑定文件夹。比如为Doris配置了2个文件夹用于存放内表数据，那么每个文件夹的最大读IO不会超过该值，如果这2个文件夹都配置到同一块盘上，最大吞吐控制就会变成2倍的read_bytes_per_second。落盘的文件目录也受该值的约束。
|
+| remote_read_bytes_per_second | 整型 | -1 | [1, 9223372036854775807] |
可选，含义为读Doris外表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。
|
-* scan_thread_num：可选，当前 workload group 用于 scan 的线程个数，默认值为 -1，含义是不生效，此时以 be
配置中的 scan 线程数为准。取值为大于 0 的整数。
+:::tip
-*
max_remote_scan_thread_num：可选，读外部数据源的scan线程池的最大线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+1. 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
-*
min_remote_scan_thread_num：可选，读外部数据源的scan线程池的最小线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+2. 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
-* tag：可选，默认为空，为Workload Group指定标签，相同标签的Workload
Group资源累加值不能超过100%，如果期望指定多个值，可以使用英文逗号分隔。
+3. 需要注意 CGroup v1 CGroup v2 版本 CPU 软限默认值是有区别的, CGroup v1 的 CPU
软限默认值为1024，取值范围为2到262144。而 CGroup v2 的 CPU 软限默认值为100，取值范围是1到10000。
+ 如果软限填了一个超出范围的值，这会导致 CPU 软限在BE修改失败。如果在 CGroup v1 的环境上如果按照CGroup
v2的默认值100设置，这可能导致这个workload group的优先级在该机器上是最低的。
+ :::
-*
read_bytes_per_second：可选，含义为读Doris内表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。需要注意的是这个值并不绑定磁盘，而是绑定文件夹。
-
比如为Doris配置了2个文件夹用于存放内表数据，那么每个文件夹的最大读IO不会超过该值，如果这2个文件夹都配置到同一块盘上，最大吞吐控制就会变成2倍的read_bytes_per_second。落盘的文件目录也受该值的约束。
+## 为用户设置Workload Group
+在把用户绑定到某个Workload Group之前，需要先确定该用户是否具有某个 Workload Group 的权限。
+可以使用这个用户查看 information_schema.workload_groups 系统表，返回的结果就是当前用户有权限使用的Workload
Group。
+下面的查询结果代表当前用户可以使用 g1 与 normal Workload Group：
-* remote_read_bytes_per_second：可选，含义为读Doris外表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。
+```sql
+SELECT name FROM information_schema.workload_groups;
++--------+
+| name |
++--------+
+| normal |
+| g1 |
++--------+
+```
-:::tip
+如果无法看到 g1 Workload Group，可以使用ADMIN账户执行 GRANT 语句为用户授权。例如：
+```
+"GRANT USAGE_PRIV ON WORKLOAD GROUP 'g1' TO 'user_1'@'%';"
+```
+这个语句的含义是把名为 g1 的 Workload Group的使用权限授予给名为 user_1 的账户。
+更多授权操作可以参考[grant
语句](../../sql-manual/sql-statements/Account-Management-Statements/GRANT)。
-1. 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
+**两种绑定方式**
+1. 通过设置 user property 将 user 默认绑定到 workload
group，默认为`normal`，需要注意的这里的value不能填空，否则语句会执行失败，如果不知道要设置哪些group，可以设置为`normal`，`normal`为全局默认的group。
+```
+set property 'default_workload_group' = 'g1';
+```
+执行完该语句后，当前用户的查询将默认使用'g1'。
-2. 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
-3. 需要注意 CGroup v1 CGroup v2 版本 CPU 软限默认值是有区别的, CGroup v1 的 CPU
软限默认值为1024，取值范围为2到262144。而 CGroup v2 的 CPU 软限默认值为100，取值范围是1到10000。
- 如果软限填了一个超出范围的值，这会导致 CPU 软限在BE修改失败。是在CGroup v1的环境上如果按照CGroup
v2的默认值100设置，这可能导致这个workload group的优先级在该机器上是最低的。
- :::
+2. 通过 session 变量指定 workload group, 默认为空：
+```
+set workload_group = 'g1';
+```
+当同时使用了两种方式时为用户指定了Workload Group，session 变量的优先级要高于 user property 。
## 查看Workload Group
1. 通过show语句查看
@@ -232,42 +248,6 @@ Query OK, 0 rows affected (0.01 sec)
可以参考：[DROP-WORKLOAD-GROUP](../../sql-manual/sql-statements/Data-Definition-Statements/Drop/DROP-WORKLOAD-GROUP)。
-## 为用户设置Workload Group
-在把用户绑定到某个Workload Group之前，需要先确定该用户是否具有某个 Workload Group 的权限。
-可以使用这个用户查看 information_schema.workload_groups 系统表，返回的结果就是当前用户有权限使用的Workload
Group。
-下面的查询结果代表当前用户可以使用 g1 与 normal Workload Group：
-
-```sql
-SELECT name FROM information_schema.workload_groups;
-+--------+
-| name |
-+--------+
-| normal |
-| g1 |
-+--------+
-```
-
-如果无法看到 g1 Workload Group，可以使用ADMIN账户执行 GRANT 语句为用户授权。例如：
-```
-"GRANT USAGE_PRIV ON WORKLOAD GROUP 'g1' TO 'user_1'@'%';"
-```
-这个语句的含义是把名为 g1 的 Workload Group的使用权限授予给名为 user_1 的账户。
-更多授权操作可以参考[grant
语句](../../sql-manual/sql-statements/Account-Management-Statements/GRANT)。
-
-**两种绑定方式**
-1. 通过设置 user property 将 user 默认绑定到 workload
group，默认为`normal`，需要注意的这里的value不能填空，否则语句会执行失败，如果不知道要设置哪些group，可以设置为`normal`，`normal`为全局默认的group。
-```
-set property 'default_workload_group' = 'g1';
-```
-执行完该语句后，当前用户的查询将默认使用'g1'。
-
-
-2. 通过 session 变量指定 workload group, 默认为空：
-```
-set workload_group = 'g1';
-```
-当同时使用了两种方式时为用户指定了Workload Group，session 变量的优先级要高于 user property 。
-
## CPU 软硬限模式切换的说明
目前 Doris 暂不支持同时运行 CPU 的软限和硬限，一个 Doris 集群在任意时刻只能是 CPU 软限或者 CPU 硬限。
用户可以在两种模式之间进行切换，切换方法如下：
@@ -708,4 +688,4 @@ BrokerLoad 和 S3Load 是常用的大批量数据导入方式，用户可以把
4. 使用 sar 命令（sar -n DEV 1 3600）查看目前的网卡接收流量，第一列为每秒接收的数据量，可以看到最大值变成了 207M 每秒，说明读
IO 的限制是生效的，但是由于 sar 命令看到的是机器级别的流量，因此要比 Doris 统计到的会大一些。
- 
+ 
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
