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 156d9630f29 modify workload group to use min/max memory percent (#2707)
156d9630f29 is described below
commit 156d9630f2963b97216a4befb6ac4c841d62f203
Author: yiguolei <[email protected]>
AuthorDate: Tue Aug 5 19:27:46 2025 +0800
modify workload group to use min/max memory percent (#2707)
## Versions
- [ x] dev
- [ ] 3.0
- [ ] 2.1
- [ ] 2.0
## Languages
- [x ] Chinese
- [ ] English
## Docs Checklist
- [ ] Checked by AI
- [ ] Test Cases Built
---------
Co-authored-by: yiguolei <[email protected]>
---
.../workload-management/workload-group.md | 74 ++++++++------
.../workload-management/workload-group.md | 112 +++++++++------------
2 files changed, 89 insertions(+), 97 deletions(-)
diff --git a/docs/admin-manual/workload-management/workload-group.md
b/docs/admin-manual/workload-management/workload-group.md
index 5b7634f3ef7..05826176b2c 100644
--- a/docs/admin-manual/workload-management/workload-group.md
+++ b/docs/admin-manual/workload-management/workload-group.md
@@ -32,6 +32,50 @@ Workload Group provides in-process resource isolation
capabilities, which differ
- Upgrading from Doris 2.0 to 2.1: Since the Workload Group feature in Doris
2.1 relies on CGroup, you need to configure the CGroup environment before
upgrading to Doris 2.1.
+- In version Doris 4.0, the original concepts of CPU soft limit and hard limit
have been modified to min_cpu_percent and max_cpu_percent, and the concepts of
memory soft limit and hard limit have been modified to min_memory_percent and
max_memory_percent.
+
+## Core Concepts
+
+**MIN_CPU_PERCENT and MAX_CPU_PERCENT**
+
+The value range is [0%, 100%]. These settings define the minimum and maximum
guaranteed CPU bandwidth for all requests in a Workload Group when there is CPU
contention.
+
+- MAX_CPU_PERCENT (maximum CPU percentage) is the upper limit of CPU bandwidth
for the group. Regardless of the current CPU usage, the CPU usage of the
current Workload Group will never exceed MAX_CPU_PERCENT.
+
+- MIN_CPU_PERCENT (minimum CPU percentage) is the CPU bandwidth reserved for
the Workload Group. When there is contention, other groups cannot use this
portion of bandwidth. However, when resources are idle, bandwidth exceeding
MIN_CPU_PERCENT can be used.
+
+- The sum of MIN_CPU_PERCENT across all Workload Groups must not exceed 100%,
and MIN_CPU_PERCENT cannot be greater than MAX_CPU_PERCENT.
+
+For example, assume the Sales and Marketing departments of a company share the
same Doris instance. The Sales department has a CPU-intensive workload with
high-priority queries, while the Marketing department also has a CPU-intensive
workload but with lower-priority queries. By creating separate Workload Groups
for each department, you can assign a minimum CPU percentage of 40% to the
Sales Workload Group and a maximum CPU percentage of 30% to the Marketing
Workload Group. This configura [...]
+
+**MIN_MEMORY_PERCENT and MAX_MEMORY_PERCENT**
+
+The value range is [0%, 100%]. These settings represent the minimum and
maximum amount of memory that a Workload Group can use.
+
+- MAX_MEMORY_PERCENT means that when requests are running in the group, their
memory usage will never exceed this percentage of the total memory. Once
exceeded, the query will either trigger disk spilling or be killed.
+
+- MIN_MEMORY_PERCENT sets the minimum memory value for a group. When resources
are idle, memory exceeding MIN_MEMORY_PERCENT can be used. However, when memory
is insufficient, the system will allocate memory according to
MIN_MEMORY_PERCENT (minimum memory percentage). It may select some queries to
kill, reducing the memory usage of the Workload Group to MIN_MEMORY_PERCENT to
ensure that other Workload Groups have sufficient memory available.
+
+- The sum of MIN_MEMORY_PERCENT across all Workload Groups must not exceed
100%, and MIN_MEMORY_PERCENT cannot be greater than MAX_MEMORY_PERCENT.
+
+**Other Settings**
+
+
+
+
+| Property | Data type | Default value | Value range
| Description
[...]
+|------------------------------|-----------|---------------|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
+| max_concurrency | Integer | 2147483647 | [0, 2147483647]
| Optional. Specifies the maximum query concurrency. The default value
is the maximum value of an integer, meaning no concurrency limit. When the
number of running queries reaches the maximum concurrency, new queries will
enter a queue.
[...]
+| max_queue_size | Integer | 0 | [0, 2147483647]
| Optional. Specifies the length of the query waiting queue. When the
queue is full, new queries will be rejected. The default value is 0, which
means no queuing. If the queue is full, new queries will fail directly.
[...]
+| queue_timeout | Integer | 0 | [0, 2147483647]
| Optional. Specifies the maximum waiting time for a query in the
waiting queue, in milliseconds. If the query's waiting time in the queue
exceeds this value, an exception will be thrown directly to the client. The
default value is 0, meaning no queuing; queries will immediately fail upon
entering the queue.
[...]
+| scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the number of threads used for scanning in the
current Workload Group. When this property is set to -1, it means it is not
active, and the actual scan thread num on the BE will default to the
doris_scanner_thread_pool_thread_num configuration in the BE.
[...]
+| max_remote_scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the maximum number of threads in the scan thread
pool for reading external data sources. When this property is set to -1, the
actual number of threads is determined by the BE, typically based on the number
of CPU cores.
[...]
+| min_remote_scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the minimum number of threads in the scan thread
pool for reading external data sources. When this property is set to -1, the
actual number of threads is determined by the BE, typically based on the number
of CPU cores.
[...]
+| read_bytes_per_second | Integer | -1 | [1,
9223372036854775807] | Optional. Specifies the maximum I/O throughput when
reading internal tables in Doris. The default value is -1, meaning no I/O
bandwidth limit is applied. It is important to note that this value is not tied
to individual disks but to directories. For example, if Doris is configured
with two directories to store internal table data, the maximum read I/O for
each directory will not exceed this value. If [...]
+| remote_read_bytes_per_second | Integer | -1 | [1,
9223372036854775807] | Optional. Specifies the maximum I/O throughput when
reading external tables in Doris. The default value is -1, meaning no I/O
bandwidth limit is applied.
[...]
+
+
+
## Configuring Workload Group
### Setting Up the CGroup Environment
@@ -149,36 +193,6 @@ You can refer to
[CREATE-WORKLOAD-GROUP](../../sql-manual/sql-statements/cluster
The CPU limit configured at this point is a soft limit. Since version 2.1,
Doris will automatically create a group named normal, which cannot be deleted.
-### Workload Group Properties
-
-
-| Property | Data type | Default value | Value range
| Description
[...]
-|------------------------------|-----------|---------------|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[...]
-| cpu_share | Integer | -1 | [1, 10000]
| Optional, effective under CPU soft limit mode. The valid range of
values depends on the version of CGroup being used, which is described in
detail later. cpu_share represents the weight of CPU time that the Workload
Group can acquire; the larger the value, the more CPU time it can obtain. For
example, if the user creates three Workload Groups, g-a, g-b, and g-c, with
cpu_share values of 10, 30, and 40 [...]
-| memory_limit | Float | -1 | (0%, 100%]
| Optional. Enabling memory hard limit represents the maximum available
memory percentage for the current Workload Group. The default value means no
memory limit is applied. The cumulative value of memory_limit for all Workload
Groups cannot exceed 100%, and it is typically used in conjunction with the
enable_memory_overcommit attribute. For example, if a machine has 64GB of
memory and the memory_limit [...]
-| enable_memory_overcommit | Boolean | true | true, false
| Optional. Used to control whether the memory limit for the current
Workload Group is a hard limit or a soft limit, with the default set to true.
If set to false, the Workload Group will have hard memory limit, and when the
system detects that the memory usage exceeds the limit, it will immediately
cancel the tasks with the highest memory usage within the group to release the
excess memory. If set to t [...]
-| cpu_hard_limit | Integer | -1 | [1%, 100%]
| Optional. Effective under CPU hard limit mode, it represents the
maximum CPU percentage a Workload Group can use. Regardless of whether the
machine's CPU resources are fully utilized, the Workload Group's CPU usage
cannot exceed the cpu_hard_limit. The cumulative value of cpu_hard_limit for
all Workload Groups cannot exceed 100%. This attribute was introduced in
version 2.1 and is not supported in ver [...]
-| max_concurrency | Integer | 2147483647 | [0, 2147483647]
| Optional. Specifies the maximum query concurrency. The default value
is the maximum value of an integer, meaning no concurrency limit. When the
number of running queries reaches the maximum concurrency, new queries will
enter a queue.
[...]
-| max_queue_size | Integer | 0 | [0, 2147483647]
| Optional. Specifies the length of the query waiting queue. When the
queue is full, new queries will be rejected. The default value is 0, which
means no queuing. If the queue is full, new queries will fail directly.
[...]
-| queue_timeout | Integer | 0 | [0, 2147483647]
| Optional. Specifies the maximum waiting time for a query in the
waiting queue, in milliseconds. If the query's waiting time in the queue
exceeds this value, an exception will be thrown directly to the client. The
default value is 0, meaning no queuing; queries will immediately fail upon
entering the queue.
[...]
-| scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the number of threads used for scanning in the
current Workload Group. When this property is set to -1, it means it is not
active, and the actual scan thread num on the BE will default to the
doris_scanner_thread_pool_thread_num configuration in the BE.
[...]
-| max_remote_scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the maximum number of threads in the scan thread
pool for reading external data sources. When this property is set to -1, the
actual number of threads is determined by the BE, typically based on the number
of CPU cores.
[...]
-| min_remote_scan_thread_num | Integer | -1 | [1, 2147483647]
| Optional. Specifies the minimum number of threads in the scan thread
pool for reading external data sources. When this property is set to -1, the
actual number of threads is determined by the BE, typically based on the number
of CPU cores.
[...]
-| tag | String | empty | -
| This feature has been discontinued and is not recommended for use in
production environments; Specifies tags for the Workload Group. The cumulative
resource values of Workload Groups with the same tag cannot exceed 100%. To
specify multiple values, use commas to separate them.
[...]
-| read_bytes_per_second | Integer | -1 | [1,
9223372036854775807] | Optional. Specifies the maximum I/O throughput when
reading internal tables in Doris. The default value is -1, meaning no I/O
bandwidth limit is applied. It is important to note that this value is not tied
to individual disks but to directories. For example, if Doris is configured
with two directories to store internal table data, the maximum read I/O for
each directory will not exceed this value. If [...]
-| remote_read_bytes_per_second | Integer | -1 | [1,
9223372036854775807] | Optional. Specifies the maximum I/O throughput when
reading external tables in Doris. The default value is -1, meaning no I/O
bandwidth limit is applied.
[...]
-
-:::tip
-
-1. Currently, the simultaneous use of both cpu hard limit and cpu soft limit
is not supported.
-At any given time, a cluster can only have either a soft limit or a hard
limit. The method for switching between them will be described later.
-
-2. All properties are optional, but at least one property must be specified
when creating a Workload Group.
-
-3. It is important to note that the default values for CPU soft limits differ
between CGroup v1 and CGroup v2. The default CPU soft limit for CGroup v1 is
1024, with a valid range from 2 to 262144, while the default for CGroup v2 is
100, with a valid range from 1 to 10000.
- If a value outside the range is set for the soft limit, it may cause the
CPU soft limit modification to fail in BE. If the default value of 100 from
CGroup v2 is applied in a CGroup v1 environment, it could result in this
Workload Group having the lowest priority on the machine.
- :::
-
## Set Workload Group for user
Before binding a user to a specific Workload Group, it is necessary to ensure
that the user has the necessary permissions for the Workload Group.
You can use the user to query the information_schema.workload_groups system
table, and the result will show the Workload Groups that the current user has
permission to access.
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/workload-management/workload-group.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/workload-management/workload-group.md
index c76f04d3a61..35ed5c8a559 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/workload-management/workload-group.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/workload-management/workload-group.md
@@ -33,6 +33,46 @@ Workload Group 提供进程内的资源隔离能力，与进程间的资源隔
- 从 Doris 2.0 升级到 2.1：由于 2.1 版本的 Workload Group 功能依赖于 CGroup，需要先配置 CGroup
环境，再升级到 Doris 2.1 版本。
+- Doris 4.0 版本将原来的CPU 软限和硬限的概念修改为 min_cpu_percent 和
max_cpu_percent，内存软限和硬限的概念修改为 min_memory_percent 和 max_memory_percent。
+
+## 核心属性
+
+**MIN_CPU_PERCENT 和 MAX_CPU_PERCENT**
+
+取值范围 [0%,100%]。这些设置定义了在出现 CPU 争用时，Workload Group 中所有请求的最低和最高保证 CPU 带宽。
+
+- MAX_CPU_PERCENT（最大 CPU 百分比）是该池中 CPU 带宽的最大限制，不论当前CPU 使用率是多少， 当前Workload Group
的 CPU 使用率超过都不会超过 MAX_CPU_PERCENT。
+
+- MIN_CPU_PERCENT（最小 CPU 百分比）是为该Workload预留的 CPU 带宽，在存在争用时，其他池无法使用这部分带宽,
但是当资源空闲时可以使用超过 MIN_CPU_PERCENT 的带宽。
+
+- 所有的Workload Group的 MIN_CPU_PERCENT 之和不能超过 100%，并且 MIN_CPU_PERCENT 不能大于
MAX_CPU_PERCENT。
+
+例如，假设某公司的销售部门和市场部门共享同一个 Doris 实例。销售部门的工作负载是 CPU 密集型的，且包含高优先级查询；市场部门的工作负载同样是
CPU 密集型，但查询优先级较低。通过为每个部门创建单独的Workload Group，可以为销售Workload Group分配 40% 的最小 CPU
百分比，为市场Workload Group分配 30% 的最大 CPU 百分比。这种配置能确保销售工作负载获得所需的 CPU
资源，同时市场工作负载不会影响销售工作负载对 CPU 的需求。
+
+**MIN_MEMORY_PERCENT 和 MAX_MEMORY_PERCENT**
+
+取值范围 [0%,100%]。这些设置是Workload Group 可以使用的最小和最大内存量。
+
+- MAX_MEMORY_PERCENT，意味着当请求在该池中运行时，它们占用的内存绝不会超过总内存的这一百分比，一旦超过那么Query
将会触发落盘或者被Kill。
+
+-
MIN_MEMORY_PERCENT，为某个池设置最小内存值，当资源空闲时，可以使用超过MIN_MEMORY_PERCENT的内存，但是当内存不足时，系统将按照MIN_MEMORY_PERCENT（最小内存百分比）分配内存，可能会选取一些Query
Kill，将Workload Group 的内存使用量降低到MIN_MEMORY_PERCENT，以确保其他Workload Group有足够的内存可用。
+
+- 所有的Workload Group的 MIN_MEMORY_PERCENT 之和不能超过 100%，并且 MIN_MEMORY_PERCENT 不能大于
MAX_MEMORY_PERCENT。
+
+**其他属性**
+
+| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
+|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 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 自行决定，通常和核数相关。
|
+| 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 带宽。
|
+
+
## 配置 workload group
### 配置 CGroup 环境
@@ -138,35 +178,6 @@ Query OK, 0 rows affected (0.03 sec)
此时配置的 CPU 限制为软限。自 2.1 版本起，系统会自动创建一个名为```normal```的 group，不可删除。
-### Workload Group 属性
-
-
-| 属性名称 | 数据类型 | 默认值 | 取值范围 | 说明
|
-|------------------------------|---------|-----|-----|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| 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 进程可用内存配置的默认值。
|
-| 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 带宽。
|
-
-:::tip
-
-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 的优先级在该机器上是最低的。
- :::
-
## 为用户设置 Workload Group
在把用户绑定到某个 Workload Group 之前，需要先确定该用户是否具有某个 Workload Group 的权限。
可以使用这个用户查看 information_schema.workload_groups 系统表，返回的结果就是当前用户有权限使用的 Workload
Group。
@@ -223,7 +234,7 @@ mysql [information_schema]>select * from
information_schema.workload_groups wher
## 修改 Workload Group
```
-mysql [information_schema]>alter workload group g1
properties('cpu_share'='2048');
+mysql [information_schema]>alter workload group g1
properties('min_cpu_percent'='2048');
Query OK, 0 rows affected (0.00 sec
mysql [information_schema]>select cpu_share from
information_schema.workload_groups where name='g1';
@@ -246,29 +257,6 @@ Query OK, 0 rows affected (0.01 sec)
可以参考：[DROP-WORKLOAD-GROUP](../../sql-manual/sql-statements/cluster-management/compute-management/DROP-WORKLOAD-GROUP)。
-## CPU 软硬限模式切换的说明
-目前 Doris 暂不支持同时运行 CPU 的软限和硬限，一个 Doris 集群在任意时刻只能是 CPU 软限或者 CPU 硬限。
-用户可以在两种模式之间进行切换，切换方法如下：
-
-1 假如当前的集群配置是默认的 CPU 软限，期望改成 CPU 的硬限，需要把 Workload Group 的 cpu_hard_limit
参数修改成一个有效的值
-```
-alter workload group test_group properties ( 'cpu_hard_limit'='20%' );
-```
-集群中所有的 Workload Group 都需要修改，所有 Workload Group 的 cpu_hard_limit 的累加值不能超过 100% 。
-
-由于 CPU 的硬限无法给出一个有效的默认值，因此如果只打开开关但是不修改属性，那么 CPU 的硬限也无法生效。
-
-2 在所有 FE 中打开 CPU 硬限的开关
-```
-1 修改磁盘上fe.conf的配置
-experimental_enable_cpu_hard_limit = true
-2 修改内存中的配置
-ADMIN SET FRONTEND CONFIG ("enable_cpu_hard_limit" = "true");
-```
-
-如果用户期望从 CPU 的硬限切换回 CPU 的软限，需要在所有 FE 修改 enable_cpu_hard_limit 的值为 false 即可。
-CPU 软限的属性 cpu_share 默认会填充一个有效值 1024(如果之前未指定 cpu_share 的值)，用户可以根据 group 的优先级对
cpu_share 的值进行重新调整。
-
## 效果测试
### 内存硬限
Adhoc 类查询通常输入的 SQL 不确定，使用的内存资源也不确定，因此存在少数查询占用很大内存的风险。
@@ -328,8 +316,7 @@ Adhoc 类查询通常输入的 SQL 不确定，使用的内存资源也不确定
1. 执行 SQL 命令修改内存配置。
```sql
- alter workload group g2 properties('memory_limit'='0.5%');
- alter workload group g2 properties('enable_memory_overcommit'='false');
+ alter workload group g2 properties('memory_limit'='1%');
```
2. 执行同样的测试，查看系统表的内存用量，内存用量为 1.5G 左右。
@@ -377,9 +364,6 @@ Adhoc 类查询通常输入的 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 进程可用内存再次进行计算的。
-
**使用建议**
@@ -411,22 +395,16 @@ Workload Group 支持 CPU 的软限和硬限，目前比较推荐在线上环境
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");
+ alter workload group g2 properties('max_cpu_percent'='10%');
```
-4. 重新压测查询负载，可以看到当前进程只能使用 9 到 10 个核，占总核数的 10% 左右。
+3. 重新压测查询负载，可以看到当前进程只能使用 9 到 10 个核，占总核数的 10% 左右。
需要注意的是，这里的测试最好使用查询负载会比较能体现出效果，因为如果是高吞吐导入的话，可能会触发 Compaction，使得实际观测的值要比
Workload Group 配置的值大。而 Compaction 的负载目前是没有归入 Workload Group 的管理的。
-5. 除了使用 Linux 的系统命令外，还可以通过使用 Doris 的系统表观察 Group 目前的 CPU 使用为 10% 左右。
+4. 除了使用 Linux 的系统命令外，还可以通过使用 Doris 的系统表观察 Group 目前的 CPU 使用为 10% 左右。
```sql
mysql [information_schema]>select CPU_USAGE_PERCENT from
workload_group_resource_usage where WORKLOAD_GROUP_ID=11201;
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
