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 5a3477cb651 [docs]add not for workload group (#2248)
5a3477cb651 is described below

commit 5a3477cb6511f4d41781a712f8e00dde7fa9a436
Author: wangbo <wan...@apache.org>
AuthorDate: Tue Apr 1 12:25:41 2025 +0800

    [docs]add not for workload group (#2248)
    
    ## Versions
    
    - [x] dev
    - [x] 3.0
    - [x] 2.1
    - [ ] 2.0
    
    ## Languages
    
    - [x] Chinese
    - [x] English
    
    ## Docs Checklist
    
    - [ ] Checked by AI
    - [ ] Test Cases Built
---
 docs/admin-manual/workload-management/workload-group.md          | 6 ++++++
 .../current/admin-manual/workload-management/workload-group.md   | 9 +++++++++
 .../admin-manual/workload-management/workload-group.md           | 8 ++++++++
 .../admin-manual/workload-management/workload-group.md           | 8 ++++++++
 .../admin-manual/workload-management/workload-group.md           | 6 ++++++
 .../admin-manual/workload-management/workload-group.md           | 6 ++++++
 6 files changed, 43 insertions(+)

diff --git a/docs/admin-manual/workload-management/workload-group.md 
b/docs/admin-manual/workload-management/workload-group.md
index 0d52f52e00b..89667f11494 100644
--- a/docs/admin-manual/workload-management/workload-group.md
+++ b/docs/admin-manual/workload-management/workload-group.md
@@ -37,6 +37,12 @@ The currently supported isolation capabilities include:
 * Managing memory resources, with support for both memory hard limit and 
memory soft limit;
 * Managing IO resources, including IO generated by reading local and remote 
files.
 
+:::tip
+Workload Group provides in-process resource isolation capabilities, which 
differ from inter-process resource isolation methods (such as Resource Group 
and Compute Group) in the following ways:
+
+1. In-process resource isolation cannot achieve complete isolation. For 
example, when high-load and low-load queries run within the same process, even 
if CPU usage for the high-load group is restricted using Workload Group to keep 
overall CPU usage within a reasonable range, the latency of the low-load group 
may still be affected. However, it will perform better compared to having no 
CPU control at all. This limitation arises because certain shared components 
within the process, such as  [...]
+2. The choice of a resource isolation strategy depends on the trade-off 
between isolation and cost. If some degree of latency can be tolerated while 
prioritizing lower costs, the Workload Group isolation approach may be 
suitable. On the other hand, if complete isolation is required and higher costs 
are acceptable, an inter-process resource isolation approach (i.e., placing 
isolated workloads in separate processes) should be considered. For example, 
using Resource Group or Compute Group t [...]
+:::
 
 ## Version Notes
 
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 f9a143e7f63..5b839f95c93 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
@@ -34,6 +34,15 @@ Workload Group 是一种进程内实现的对负载进行逻辑隔离的机制
 * 管理内存资源,支持内存硬限和内存软限;
 * 管理 IO 资源,包括读本地文件和远程文件产生的 IO。
 
+:::tip
+Workload Group 提供进程内的资源隔离能力,与进程间的资源隔离方式( Resource Group, Compute Group )存在以下区别:
+
+1. 进程内的资源隔离无法做到彻底的隔离性,比如高负载查询和低负载查询在同一个进程内运行,即使通过 Workload Group 对高负载分组的 CPU 
使用进行限制使得整体的 CPU 使用在合理范围内,
+    那么低负载分组的延迟也难免会受到影响,但相比于不做 CPU 
管控的情况会有更好的表现。这是由于进程内部难免存在一些无法隔离的公共组件,比如公共的缓存和公共的 RPC 线程池。
+2. 在做资源隔离方案的选择时,具体使用 Workload Group 
还是基于进程的资源隔离方案(也就是把需要隔离的负载放到不同的进程),主要取决于隔离性和成本的权衡,可以容忍一定的延迟但是偏好低成本的场景,可以选择 
Workload Group 的隔离方案;
+   期望完全的隔离性同时可以接受更高的成本,那么可以选择基于进程的资源隔离方案,例如 Resource Group 或者 Compute 
Group,把高优负载划分到独立的 BE 节点上就可以做到比较彻底的隔离。
+:::
+
 
 ## 版本说明
 
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 f9a143e7f63..3550cda2464 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
@@ -34,6 +34,14 @@ Workload Group 是一种进程内实现的对负载进行逻辑隔离的机制
 * 管理内存资源,支持内存硬限和内存软限;
 * 管理 IO 资源,包括读本地文件和远程文件产生的 IO。
 
+:::tip
+Workload Group 提供进程内的资源隔离能力,与进程间的资源隔离方式( Resource Group, Compute Group )存在以下区别:
+
+1. 进程内的资源隔离无法做到彻底的隔离性,比如高负载查询和低负载查询在同一个进程内运行,即使通过 Workload Group 对高负载分组的 CPU 
使用进行限制使得整体的 CPU 使用在合理范围内,
+   那么低负载分组的延迟也难免会受到影响,但相比于不做 CPU 
管控的情况会有更好的表现。这是由于进程内部难免存在一些无法隔离的公共组件,比如公共的缓存和公共的 RPC 线程池。
+2. 在做资源隔离方案的选择时,具体使用 Workload Group 
还是基于进程的资源隔离方案(也就是把需要隔离的负载放到不同的进程),主要取决于隔离性和成本的权衡,可以容忍一定的延迟但是偏好低成本的场景,可以选择 
Workload Group 的隔离方案;
+   期望完全的隔离性同时可以接受更高的成本,那么可以选择基于进程的资源隔离方案,例如 Resource Group 或者 Compute 
Group,把高优负载划分到独立的 BE 节点上就可以做到比较彻底的隔离。
+   :::
 
 ## 版本说明
 
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 f9a143e7f63..3550cda2464 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
@@ -34,6 +34,14 @@ Workload Group 是一种进程内实现的对负载进行逻辑隔离的机制
 * 管理内存资源,支持内存硬限和内存软限;
 * 管理 IO 资源,包括读本地文件和远程文件产生的 IO。
 
+:::tip
+Workload Group 提供进程内的资源隔离能力,与进程间的资源隔离方式( Resource Group, Compute Group )存在以下区别:
+
+1. 进程内的资源隔离无法做到彻底的隔离性,比如高负载查询和低负载查询在同一个进程内运行,即使通过 Workload Group 对高负载分组的 CPU 
使用进行限制使得整体的 CPU 使用在合理范围内,
+   那么低负载分组的延迟也难免会受到影响,但相比于不做 CPU 
管控的情况会有更好的表现。这是由于进程内部难免存在一些无法隔离的公共组件,比如公共的缓存和公共的 RPC 线程池。
+2. 在做资源隔离方案的选择时,具体使用 Workload Group 
还是基于进程的资源隔离方案(也就是把需要隔离的负载放到不同的进程),主要取决于隔离性和成本的权衡,可以容忍一定的延迟但是偏好低成本的场景,可以选择 
Workload Group 的隔离方案;
+   期望完全的隔离性同时可以接受更高的成本,那么可以选择基于进程的资源隔离方案,例如 Resource Group 或者 Compute 
Group,把高优负载划分到独立的 BE 节点上就可以做到比较彻底的隔离。
+   :::
 
 ## 版本说明
 
diff --git 
a/versioned_docs/version-2.1/admin-manual/workload-management/workload-group.md 
b/versioned_docs/version-2.1/admin-manual/workload-management/workload-group.md
index 1d24e813e77..308c7f0640a 100644
--- 
a/versioned_docs/version-2.1/admin-manual/workload-management/workload-group.md
+++ 
b/versioned_docs/version-2.1/admin-manual/workload-management/workload-group.md
@@ -37,6 +37,12 @@ The currently supported isolation capabilities include:
 * Managing memory resources, with support for both memory hard limit and 
memory soft limit;
 * Managing IO resources, including IO generated by reading local and remote 
files.
 
+:::tip
+Workload Group provides in-process resource isolation capabilities, which 
differ from inter-process resource isolation methods (such as Resource Group 
and Compute Group) in the following ways:
+
+1. In-process resource isolation cannot achieve complete isolation. For 
example, when high-load and low-load queries run within the same process, even 
if CPU usage for the high-load group is restricted using Workload Group to keep 
overall CPU usage within a reasonable range, the latency of the low-load group 
may still be affected. However, it will perform better compared to having no 
CPU control at all. This limitation arises because certain shared components 
within the process, such as  [...]
+2. The choice of a resource isolation strategy depends on the trade-off 
between isolation and cost. If some degree of latency can be tolerated while 
prioritizing lower costs, the Workload Group isolation approach may be 
suitable. On the other hand, if complete isolation is required and higher costs 
are acceptable, an inter-process resource isolation approach (i.e., placing 
isolated workloads in separate processes) should be considered. For example, 
using Resource Group or Compute Group t [...]
+   :::
 
 ## Version Notes
 
diff --git 
a/versioned_docs/version-3.0/admin-manual/workload-management/workload-group.md 
b/versioned_docs/version-3.0/admin-manual/workload-management/workload-group.md
index 1d24e813e77..308c7f0640a 100644
--- 
a/versioned_docs/version-3.0/admin-manual/workload-management/workload-group.md
+++ 
b/versioned_docs/version-3.0/admin-manual/workload-management/workload-group.md
@@ -37,6 +37,12 @@ The currently supported isolation capabilities include:
 * Managing memory resources, with support for both memory hard limit and 
memory soft limit;
 * Managing IO resources, including IO generated by reading local and remote 
files.
 
+:::tip
+Workload Group provides in-process resource isolation capabilities, which 
differ from inter-process resource isolation methods (such as Resource Group 
and Compute Group) in the following ways:
+
+1. In-process resource isolation cannot achieve complete isolation. For 
example, when high-load and low-load queries run within the same process, even 
if CPU usage for the high-load group is restricted using Workload Group to keep 
overall CPU usage within a reasonable range, the latency of the low-load group 
may still be affected. However, it will perform better compared to having no 
CPU control at all. This limitation arises because certain shared components 
within the process, such as  [...]
+2. The choice of a resource isolation strategy depends on the trade-off 
between isolation and cost. If some degree of latency can be tolerated while 
prioritizing lower costs, the Workload Group isolation approach may be 
suitable. On the other hand, if complete isolation is required and higher costs 
are acceptable, an inter-process resource isolation approach (i.e., placing 
isolated workloads in separate processes) should be considered. For example, 
using Resource Group or Compute Group t [...]
+   :::
 
 ## Version Notes
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org

Reply via email to