This is an automated email from the ASF dual-hosted git repository.
yiguolei 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 c1766744eb update workload group doc (#1016)
c1766744eb is described below
commit c1766744eb8d4f61fbef51daa57a2f993078a2cf
Author: wangbo <wan...@apache.org>
AuthorDate: Sat Aug 17 17:00:44 2024 +0800
update workload group doc (#1016)
---
.../admin-manual/resource-admin/workload-group.md | 49 +++++++++++++++++++++-
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-group.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-group.md
index 016d69a262..7b83354794 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-group.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-group.md
@@ -25,8 +25,15 @@ under the License.
-->
# WORKLOAD GROUP
+你可以使用Workload Group管理Doris集群中查询和导入负载所使用的CPU/内存/IO资源用量，控制集群中查询的最大并发。Workload
Group的使用权限可以授予给特定的角色和用户。
-workload group 可限制组内任务在单个 be 节点上的计算资源和内存资源的使用。当前支持 query 绑定到 workload group。
+在以下场景使用Workload Group通常会取得不错的效果：
+1. 偏好性能稳定性的场景，不要求查询负载可以占满集群所有的资源，但是期望查询的延迟比较稳定，那么可以尝试把Workload
Group的CPU/IO配置成硬限。
+2.
当集群整体负载过高导致可用性下降时，此时可以通过对集群中资源占用过高的WorkloadGroup进行降级处理来恢复集群的可用性，例如降低Workload
Group的最大查询并发和IO吞吐。
+
+通常使用硬限对资源进行管理可以获得更好的稳定性和性能，例如配置FE的最大并发以及CPU的硬限。
+因为CPU的软限通常只有在CPU在用满时才能体现效果，而此时Doris内部的其他组件（RPC）以及操作系统可用的CPU资源会受到挤压，系统整体的延迟就会增加。
+对Doris的查询负载配置硬限能有效缓解这个问题。同时配置最大并发和排队，可以缓解高峰时持续不断地新查询进来耗尽集群中的所有可用资源的情况。
## 版本说明
Workload Group 是从 2.0 版本开始支持的功能，Workload Group 在 2.0 版本和 2.1 版本的主要区别在于，2.0 版本的
Workload Group 不依赖 CGroup，而 2.1 版本的 Workload Group 依赖 CGroup，因此使用 2.1 版本的
Workload Group 时要配置 CGroup 的环境。
@@ -52,11 +59,17 @@ Workload Group 是从 2.0 版本开始支持的功能，Workload Group 在 2.0
* 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%，不限制。取值范围 1%~100%，CPU 硬限制模式下，Workload Group 最大可用的
CPU 百分比，不管当前机器的 CPU 资源是否被用满，Workload Group 的最大 CPU 用量都不能超过 cpu_hard_limit，
- 所有 Workload Group 的 cpu_hard_limit 累加值不能超过 100%。2.1 版本新增属性
+ 所有 Workload Group 的 cpu_hard_limit 累加值不能超过 100%。2.1 版本新增属性，2.0版本不支持该功能。
* max_concurrency：可选，最大查询并发数，默认值为整型最大值，也就是不做并发的限制。运行中的查询数量达到该值时，新来的查询会进入排队的逻辑。
* max_queue_size：可选，查询排队队列的长度，当排队队列已满时，新来的查询会被拒绝。默认值为 0，含义是不排队。
* queue_timeout：可选，查询在排队队列中的超时时间，单位为毫秒，如果查询在队列中的排队时间超过这个值，那么就会直接抛出异常给客户端。默认值为
0，含义是不排队。
* scan_thread_num：可选，当前 workload group 用于 scan 的线程个数，默认值为 -1，含义是不生效，此时以 be
配置中的 scan 线程数为准。取值为大于 0 的整数。
+*
max_remote_scan_thread_num：可选，读外部数据源的scan线程池的最大线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+*
min_remote_scan_thread_num：可选，读外部数据源的scan线程池的最小线程数，默认值为-1，当该值为-1时，实际的线程数由BE自行决定，通常和核数相关。
+* tag：可选，默认为空，为Workload Group指定标签，相同标签的Workload
Group资源累加值不能超过100%，如果期望指定多个值，可以使用英文逗号分隔，关于打标功能下文会有详细描述。
+*
read_bytes_per_second：可选，含义为读Doris内表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。需要注意的是这个值并不绑定磁盘，而是绑定文件夹。
+比如为Doris配置了2个文件夹用于存放内表数据，那么每个文件夹的最大读IO不会超过该值，如果这2个文件夹都配置到同一块盘上，最大吞吐控制就会变成2倍的read_bytes_per_second。落盘的文件目录也受该值的约束。
+* remote_read_bytes_per_second：可选，含义为读Doris外表时的最大IO吞吐，默认值为-1，也就是不限制IO带宽。
注意事项：
@@ -64,6 +77,29 @@ Workload Group 是从 2.0 版本开始支持的功能，Workload Group 在 2.0
2 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
+## Workload Group分组功能
+Workload Group功能是对单台BE资源用量的划分。当用户创建了一个Group A，默认情况下这个Group
A的元信息会被发送到所有BE上并启动线程，这会带来以下问题：
+1.
生产环境下通常会在一个Doris集群内拆分出多个小集群，比如拆分出本地存储的集群和用于查外部存储的包含ComputeNode的集群，这两个集群间的查询是独立的。
+此时用户如果期望使用Workload Group功能，那么就会出现查外部存储的负载使用的Workload Group和查本地存储的负载使用的Workload
Group的mem_limit累加值不能超过100%，然而实际上这两种负载完全位于不同的机器上，这显然是不合理的。
+2. 线程数本身也是一种资源，如果一个进程的线程数配额被耗尽，这会导致进程挂掉，默认把Workload Group的元信息发送给所有节点本身也是不合理的。
+
+基于以上原因，Doris实现了对于Workload Group的分组功能，相同Tag分组下的Workload
Group的累加值不能超过100%，但是一个集群中就可以有多个这样的Tag分组。
+当一个BE节点也被打上了Tag，那么这个BE会根据一定的规则匹配对应的Workload Group。
+
+具体用法如下：
+1. 创建名为tag_wg的Workload Group，指定其tag名为cn1，此时如果集群中的BE都没有打标签的话，那么这个Workload
Group的元信息会被发送到所有BE上。tag属性可以指定多个，使用英文逗号分隔。
+```
+create workload group tag_wg properties('tag'='cn1');
+```
+2. 修改集群中一个BE的标签为cn1，此时tag_wg这个Workload
Group就只会发送到这个BE以及标签为空的BE上。tag.workload_group属性可以指定多个，使用英文逗号分隔。
+```
+alter system modify backend "localhost:9050" set ("tag.workload_group" =
"cn1");
+```
+
+Workload Group和BE的匹配规则说明:
+1. 当Workload Group的Tag为空，那么这个Workload Group可以发送给所有的BE，不管该BE是否指定了tag。
+2. 当Workload Group的Tag不为空，那么Workload Group只会发送给具有相同标签的BE。
+
## 配置 cgroup v1 的环境
Doris 的 2.0 版本使用基于 Doris 的调度实现 CPU 资源的限制，但是从 2.1 版本起，Doris 默认使用基于 CGroup v1
版本对 CPU 资源进行限制（暂不支持 CGroup v2），因此如果期望在 2.1 版本对 CPU 资源进行约束，那么需要 BE 所在的节点上已经安装好
CGroup v1 的环境。
@@ -97,6 +133,15 @@ doris_cgroup_cpu_path = /sys/fs/cgroup/cpu/doris
需要注意的是，目前的 workload group 暂时不支持一个机器多个 BE 的部署方式。
+## 在K8S中使用Workload Group的注意事项
+Workload的CPU管理是基于CGroup实现的，如果期望在容器中使用Workload
Group，那么需要以特权模式启动容器，容器内的Doris进程才能具备读写宿主机CGroup文件的权限。
+当Doris在容器内运行时，Workload
Group的CPU资源用量是在容器可用资源的情况下再划分的，例如宿主机整机是64核，容器被分配了8个核的资源，Workload
Group配置的CPU硬限为50%，
+那么Workload Group实际可用核数为4个（8核 * 50%）。
+
+WorkloadGroup的内存管理和IO管理功能是Doris内部实现，不依赖外部组件，因此在容器和物理机上部署使用并没有区别。
+
+如果要在K8S上使用Doris，建议使用Doris Operator进行部署，可以屏蔽底层的权限细节问题。
+
## workload group 使用
1. 首先创建一个自定义的 workload group。
```
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
