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 32fb9dc7fb7 [docs]update workload group (#1058)
32fb9dc7fb7 is described below
commit 32fb9dc7fb7f7f247d0de257c9065999ab558f78
Author: wangbo <wan...@apache.org>
AuthorDate: Tue Aug 27 20:35:23 2024 +0800
[docs]update workload group (#1058)
---
docs/admin-manual/resource-admin/workload-group.md | 54 +++++++++++++++++-----
.../admin-manual/resource-admin/workload-group.md | 48 +++++++++++++++----
2 files changed, 80 insertions(+), 22 deletions(-)
diff --git a/docs/admin-manual/resource-admin/workload-group.md
b/docs/admin-manual/resource-admin/workload-group.md
index 6b6d01ffbe5..c2acefbc449 100644
--- a/docs/admin-manual/resource-admin/workload-group.md
+++ b/docs/admin-manual/resource-admin/workload-group.md
@@ -69,9 +69,13 @@ Scenario 2: If the Workload Group is not used in version
2.0, it is also necessa
Notes:
-1 At present, the simultaneous use of CPU's soft and hard limits is not
supported. A cluster can only have soft or hard limits at a certain time. The
switching method will be described in the following text.
+1. At present, the simultaneous use of CPU's soft and hard limits is not
supported. A cluster can only have soft or hard limits at a certain time. The
switching method will be described in the following text.
-2 All properties are optional, but at least one propety needs to be specified
when creating a Workload Group.
+2. All properties are optional, but at least one property needs to be
specified when creating a Workload Group.
+
+3. It is important to note that the default CPU soft limit values differ
between cgroup v1 and cgroup v2. In cgroup v1, the default CPU soft limit value
is 1024, with a range of 2 to 262144. In contrast, cgroup v2 has a default CPU
soft limit value of 100, with a range of 1 to 10000.
+
+If a value outside of this range is specified for the soft limit, it can lead
to a failure in modifying the CPU soft limit in the backend. Additionally, if
you set the default value of 100 in a cgroup v1 environment, it might cause the
priority of this workload group to be the lowest on the machine.
## Grouping Workload Group By Tag
The Workload Group feature divides the resource usage of a single BE. When a
user creates a Workload Group (Group A), its metadata is by default sent to all
BEs and threads are started on each BE, leading to the following issues:
@@ -94,9 +98,9 @@ Workload Group and BE Matching Rules:
If the Workload Group's tag is empty, the Workload Group can be sent to all
BEs, regardless of whether the BE has a tag or not.
If the Workload Group's tag is not empty, the Workload Group will only be sent
to BEs with the same tag.
-## Configure cgroup v1
+## Configure cgroup
-Doris 2.0 version uses Doris scheduling to limit CPU resources, but since
version 2.1, Doris defaults to using CGgroup v1 to limit CPU resources (CGgroup
v2 is currently not supported). Therefore, if CPU resources are expected to be
limited in version 2.1, it is necessary to have CGgroup v1 installed on the
node where BE is located.
+Doris 2.0 version uses Doris scheduling to limit CPU resources, but since
version 2.1, Doris defaults to using CGgroup v1 to limit CPU resources.
Therefore, if CPU resources are expected to be limited in version 2.1, it is
necessary to have CGgroup installed on the node where BE is located.
If users use the Workload Group software limit in version 2.0 and upgrade to
version 2.1, they also need to configure CGroup, Otherwise, cpu soft limit may
not work.
@@ -104,13 +108,29 @@ If using CGroup within a container, the container needs
to have permission to op
Without configuring cgroup, users can use all functions of the workload group
except for CPU limitations.
-1 Firstly, confirm that the CGgroup v1 version has been installed on the node
where BE is located, and the path ```/sys/fs/cgroup/cpu/``` exists.
+1. Firstly, confirm that the CGgroup has been installed on the node where BE
is located.
+```
+cat /proc/filesystems | grep cgroup
+nodev cgroup
+nodev cgroup2
+nodev cgroupfs
+```
+
+2. Check the cgroup version.
+```
+If this path exists, it indicates that cgroup v1 is currently active.
+/sys/fs/cgroup/cpu/
-2 Create a new directory named doris in the CPU path of cgroup, user can
specify their own directory name.
+
+If this path exists, it indicates that cgroup v2 is currently active.
+/sys/fs/cgroup/cgroup.controllers
+```
+
+3. Create a new directory named doris in the CPU path of cgroup, user can
specify their own directory name.
```mkdir /sys/fs/cgroup/cpu/doris```
-3 It is necessary to ensure that Doris's BE process has read/write/execute
permissions for this directory
+4. It is necessary to ensure that Doris's BE process has read/write/execute
permissions for this directory
```
// Modify the permissions of this directory to read, write, and execute
chmod 770 /sys/fs/cgroup/cpu/doris
@@ -119,14 +139,24 @@ chmod 770 /sys/fs/cgroup/cpu/doris
chown -R doris:doris /sys/fs/cgroup/cpu/doris
```
-4 Modify the configuration of BE and specify the path to cgroup
+5. If cgroup v2 is being used in the current environment, the following
actions need to be taken. This is because cgroup v2 has stricter permission
controls, requiring write access to the cgroup.procs file in the root directory
in order to move processes between groups.
+```
+chmod a+w /sys/fs/cgroup/cgroup.procs
+```
+
+6. Modify the configuration of BE and specify the path to cgroup
```
doris_cgroup_cpu_path = /sys/fs/cgroup/cpu/doris
```
-5 restart BE, in the log (be. INFO), you can see the words "add thread xxx to
group" indicating successful configuration.
+7. restart BE, in the log (be. INFO), you can see the words "add thread xxx to
group" indicating successful configuration.
+
+:::tip
+NOTE:
-It should be noted that the current workload group does not support the
deployment of multiple BE on same machine.
+1. The current workload group does not yet support the deployment of multiple
BEs on a single machine.
+2. After the machine is restarted, the above cgroup configurations will be
cleared. If you want the above configurations to take effect after a reboot,
you can use systemd to set these operations as a custom system service, so that
the creation and permission assignments are automatically completed each time
the machine restarts.
+:::
## Note for Using Workload Groups in K8S
The CPU management for Workloads is implemented based on CGroup. To use
Workload Groups within containers, you need to start the containers in
privileged mode so that the Doris processes inside the container have
permission to read and write CGroup files on the host.
@@ -257,8 +287,8 @@ mysql [information_schema]>desc
information_schema.workload_group_privileges;
Column Description：
1. grantee, user or role.
2. workload_group_name, value is the name of Workload Group or '%', where '%'
represents all Workload Group.
-3. privilege_type，type of privilege, at present, the value of this column is
only Usage_priv。
-4. is_grantable，value is YES or NO, it means whether the user can grant access
privilege of Workload Group to other user.Only root/admin user has grant
privilege.
+3. privilege_type, type of privilege, at present, the value of this column is
only Usage_priv。
+4. is_grantable, value is YES or NO, it means whether the user can grant
access privilege of Workload Group to other user.Only root/admin user has grant
privilege.
Basic usage：
1. Search for Workload Group with authorized access based on username.
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 5b9912c431d..cfa8789cd84 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
@@ -72,9 +72,13 @@ Workload Group 是从 2.0 版本开始支持的功能，Workload Group 在 2.0
注意事项：
-1 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
+1. 目前暂不支持 CPU 的软限和硬限的同时使用，一个集群某一时刻只能是软限或者硬限，下文中会描述切换方法。
+
+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 所有属性均为可选，但是在创建 Workload Group 时需要指定至少一个属性。
## Workload Group分组功能
Workload Group功能是对单台BE资源用量的划分。当用户创建了一个Group A，默认情况下这个Group
A的元信息会被发送到所有BE上并启动线程，这会带来以下问题：
@@ -99,8 +103,8 @@ 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 的环境。
+## 配置 cgroup 的环境
+Doris 的 2.0 版本使用基于 Doris 的调度实现 CPU 资源的限制，但是从 2.1 版本起，Doris 默认使用基于 CGroup v1
版本对 CPU 资源进行限制，因此如果期望在 2.1 版本对 CPU 资源进行约束，那么需要 BE 所在的节点上已经安装好 CGroup 的环境。
用户如果在 2.0 版本使用了 Workload Group 的软限并升级到了 2.1 版本，那么也需要配置 CGroup，否则可能导致软限失效。
@@ -108,13 +112,28 @@ Doris 的 2.0 版本使用基于 Doris 的调度实现 CPU 资源的限制，但
在不配置 cgroup 的情况下，用户可以使用 workload group 除 CPU 限制外的所有功能。
-1 首先确认 BE 所在节点已经安装好 CGroup v1 版本，确认存在路径```/sys/fs/cgroup/cpu/```即可
+1. 首先确认 BE 所在节点是否已经安装好cgroup
+```
+cat /proc/filesystems | grep cgroup
+nodev cgroup
+nodev cgroup2
+nodev cgroupfs
+```
+
+2. 确认cgroup的版本
+```
+如果包含这个路径说明目前生效的是cgroup v1
+/sys/fs/cgroup/cpu/
+
+如果包含这个路径说明目前生效的是cgroup v2
+/sys/fs/cgroup/cgroup.controllers
+```
-2 在 cgroup 的 cpu 路径下新建一个名为 doris 的目录，这个目录名用户可以自行指定
+3. 在 cgroup 的 cpu 路径下新建一个名为 doris 的目录，这个目录名用户可以自行指定
```mkdir /sys/fs/cgroup/cpu/doris```
-3 需要保证 Doris 的 BE 进程对于这个目录有读/写/执行权限
+4. 需要保证 Doris 的 BE 进程对于这个目录有读/写/执行权限
```
// 修改这个目录的权限为可读可写可执行
chmod 770 /sys/fs/cgroup/cpu/doris
@@ -123,14 +142,23 @@ chmod 770 /sys/fs/cgroup/cpu/doris
chown -R doris:doris /sys/fs/cgroup/cpu/doris
```
-4 修改 BE 的配置，指定 cgroup 的路径
+5. 如果目前环境里使用的是cgroup v2版本，那么需要做以下操作。这是因为cgroup
v2对于权限管控比较严格，需要具备根目录的cgroup.procs文件的写权限才能实现进程在group之间的移动。
+```
+chmod a+w /sys/fs/cgroup/cgroup.procs
+```
+
+6. 修改 BE 的配置，指定 cgroup 的路径
```
doris_cgroup_cpu_path = /sys/fs/cgroup/cpu/doris
```
-5 重启 BE，在日志（be.INFO）可以看到"add thread xxx to group"的字样代表配置成功
+7. 重启 BE，在日志（be.INFO）可以看到"add thread xxx to group"的字样代表配置成功
-需要注意的是，目前的 workload group 暂时不支持一个机器多个 BE 的部署方式。
+:::tip
+注意事项：
+1. 目前的 workload group 暂时不支持一个机器多个 BE 的部署方式。
+2.
当机器重启之后，上面的cgroup配置就会清空。如果期望上述配置重启之后可以也可以生效，可以使用systemd把以上操作设置成系统的自定义服务，这样在每次机器重启的时候，自动完成创建和授权操作。
+:::
## 在K8S中使用Workload Group的注意事项
Workload的CPU管理是基于CGroup实现的，如果期望在容器中使用Workload
Group，那么需要以特权模式启动容器，容器内的Doris进程才能具备读写宿主机CGroup文件的权限。
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
