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 570c8e552f add workload analysis (#1019)
570c8e552f is described below
commit 570c8e552f76c0034c6e2cb335ef4c171012ccea
Author: wangbo <wan...@apache.org>
AuthorDate: Sat Aug 17 17:01:54 2024 +0800
add workload analysis (#1019)
---
...rkload-system-table.md => workload-analysis.md} | 176 +++++++--------------
1 file changed, 54 insertions(+), 122 deletions(-)
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-system-table.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-analysis.md
similarity index 50%
rename from
i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-system-table.md
rename to
i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-analysis.md
index 2e03ef09d4..fd90fea7b0 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-system-table.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/admin-manual/resource-admin/workload-analysis.md
@@ -1,6 +1,6 @@
---
{
- "title": "Workload系统表",
+ "title": "工作负载分析",
"language": "zh-CN"
}
---
@@ -25,13 +25,9 @@ under the License.
-->
## 背景
-Doris支持通过Workload系统表对运行中的工作负载的资源使用情况进行分析，常用于以下场景：
-
-1. 查看集群中Workload Group的资源用量，包括CPU和内存。
-2. 查看目前集群中目前资源用量最大的N个sql。
-3. 查看集群中Workload Group的排队情况
-
-用户可以通过提交sql的方式查询这些信息，找出目前系统中资源占用比较高的Workload Group或者sql，并进行相应的处理。
+Doris支持通过Workload系统表对集群中的工作负载进行分析，可以解决以下问题：
+1. 帮助用户了解每个Workload Group的资源利用率，合理的设置资源上限，避免资源的浪费。
+2. 当集群由于资源不足导致可用性下降时，可以使用系统表快速定位出目前资源使用的分布情况，从做出相应的资源管控决策，恢复集群的可用性。
## Workload系统表介绍
目前系统表主要在```information_schema```库里。
@@ -63,75 +59,40 @@ Doris支持通过Workload系统表对运行中的工作负载的资源使用情
* shuffle_send_bytes，查询在当前节点作为shuffle客户端发送的字节数
* shuffle_send_rows，查询在当前节点作为shuffle客户端发送的行数
-## 基本用法
-1. 查看资源用量topN的sql
- ```
- select
- t2.query_id,
- t2.workload_group_id,
- t2.`database`,
- t1.cpu_time,
- t1.mem_used,
- t2.`sql`
- from
- (select query_id, sum(task_cpu_time_ms) as
cpu_time,sum(current_used_memory_bytes) as mem_used from backend_active_tasks
group by query_id)
- t1 left join active_queries t2
- on t1.query_id = t2.query_id
- order by cpu_time desc, mem_used desc limit 10;
- ```
-
-2. 查看目前单BE上资源用量topN的sql
- ```
- select
- t2.query_id,
- t2.workload_group_id,
- t2.`database`,
- t1.cpu_time,
- t1.mem_used,
- t2.`sql`
- from
- (select query_id, sum(task_cpu_time_ms) as
cpu_time,sum(current_used_memory_bytes) as mem_used
- from backend_active_tasks where be_id=12345 group by query_id)
- t1 left join active_queries t2
- on t1.query_id = t2.query_id
- order by cpu_time desc, mem_used desc limit 10;
- ```
-
-
-3. 查看各个workload group运行中/排队的查询数量
- ```
- select
- workload_group_id,
- sum(case when query_status='QUEUED' then 1 else 0 end) as queue_num,
- sum(case when query_status='RUNNING' then 1 else 0 end) as
running_query_num
- from
- active_queries
- group by workload_group_id
- ```
-
-4. 查看各个workload group排队的都是哪些查询，以及排队的时间
- ```
- select
- workload_group_id,
- query_id,
- query_status,
- now() - queue_start_time as queued_time
- from
- active_queries
- where query_status='queued'
- order by workload_group_id
- ```
-
-## 应用场景
-当集群的查询延迟上升时，可用性下降时，可以通过集群的整体监控确瓶颈点：
-1. 当BE的CPU资源用满，内存使用不高，说明主要瓶颈应该在CPU上。
-2. 当BE的CPU资源和内存资源使用都很高，说明主要瓶颈在内存上。
-3. 当BE的CPU资源和内存资源使用都不高，但是IO使用很高，说明主要瓶颈在IO上。
-4. CPU/内存/IO都不高，但是排队的查询较多，说明排队参数配置不合理，可以尝试调大排队并发。
-确认了集群的瓶颈点之后，可以通过workload group系统表进一步分析出目前使用资源较多的sql，然后进行查询的降级处理。
-
-### 找出CPU使用最高的sql
-1. CPU使用topN的sql
+### workload_group_resource_usage
+```workload_group_resource_usage```实时展示了Workload Group当前的资源用量。
+字段说明如下：
+* be_id，be的id
+* workload_group_id，workload group的id
+* memory_usage_bytes，workload group的内存用量
+* cpu_usage_percent，workload group CPU用量的百分比，计算方式为1s内Workload
Group总的CPU活跃时间/1s内总可用的CPU时间，该值取的是最近10s的平均值。
+* local_scan_bytes_per_second，workload group读本地文件的每秒字节数。
+需要注意的是，由于Doris的Page
Cache和操作系统缓存的存在，该值通常要大于使用pidstat等系统工具监控到的值。如果配置了多个文件夹，那么该值为所有文件夹读IO的累加值。
+如果需要每个文件夹粒度的读IO吞吐，可以在BE的bvar监控上看到明细数据。
+* remote_scan_bytes_per_second，workload group读远程数据的每秒字节数。
+
+## 工作负载分析与处理方法
+当通过监控发现集群的可用性下降时，可以按照以下流程进行处理：
+1. 先通过监控大致判断目前集群的瓶颈点，比如是内存用量过高，CPU用量过高，还是IO过高，如果都很高，那么可以考虑优先解决内存的问题。
+2.
确定了集群瓶颈点之后，可以通过```workload_group_resource_usage```表来查看目前资源用量最高的Group，比如是内存瓶颈，那么可以先找出内存用量最高的N个Group。
+3. 确定了资源用量最高的Group之后，首先可以尝试调低这个Group的查询并发，因为此时集群资源已经很紧张了，要避免持续有新的查询进来耗尽集群的资源。
+4. 对当前Group的查询进行降级，根据瓶颈点的不同，可以有不同的处理方法：
+* 如果是CPU瓶颈，那么可以尝试把这个Group的CPU修改为硬限，并将```cpu_hard_limit```设置为一个较低的值，主动让出CPU资源。
+* 如果是IO瓶颈，可以通过```read_bytes_per_second```参数限制该Group的最大IO。
+*
如果是内存瓶颈，可以通过设置该Group的内存为硬限，并调低```memory_limit```的值，来释放部分内存，需要注意的是这可能会导致当前Group大量查询失败。
+5. 完成以上步骤后，通常集群的可用性会有所恢复。此时可以做更进一步的分析，也就是引起该Group资源用量升高的主要原因，
+是这个Group的整体查询并发升高导致的还是某些大查询导致的，如果是某些大查询导致的，那么可以通过快速杀死这些大查询的方式进行故障恢复。
+6.
可以使用```backend_active_tasks```结合```active_queries```找出目前集群中资源用量比较异常的SQL，然后通过kill语句杀死这些SQL释放资源。
+
+## 常用SQL
+1. 查看目前所有的Workload Group并依次按照内存/CPU/IO降序显示。
+```
+select
be_id,workload_group_id,memory_usage_bytes,cpu_usage_percent,local_scan_bytes_per_second
+ from workload_group_resource_usage
+order by memory_usage_bytes,cpu_usage_percent,local_scan_bytes_per_second desc
+```
+
+2. CPU使用topN的sql
```
select
t2.query_id,
@@ -146,24 +107,7 @@ Doris支持通过Workload系统表对运行中的工作负载的资源使用情
order by cpu_time desc limit 10;
```
-2. 统计workload group的cpu时间
- ```
- select
- t2.workload_group_id,
- sum(t1.cpu_time) cpu_time
- from
- (select query_id, sum(task_cpu_time_ms) as cpu_time from
backend_active_tasks group by query_id)
- t1 left join active_queries t2
- on t1.query_id = t2.query_id
- group by workload_group_id order by cpu_time desc
- ```
-
-如果是单sql的CPU使用率过高，那么可以通过取消查询的方式来缓解。
-
-如果是cpu时间较长的sql都来自于同一个workload group，那么可以通过调低这个workload
group的cpu优先级或者调低scan线程的数量来降低cpu的使用。
-
-### 找出内存使用最高的sql
-1. 内存使用topN的sql
+3. 内存使用topN的sql
```
select
t2.query_id,
@@ -176,28 +120,7 @@ Doris支持通过Workload系统表对运行中的工作负载的资源使用情
order by mem_used desc limit 10;
```
-2. 各个workload group的内存用量
- ```
- select
- t2.workload_group_id,
- sum(t1.mem_used) wg_mem_used
- from
- (select query_id, sum(current_used_memory_bytes) as mem_used from
backend_active_tasks group by query_id)
- t1 left join active_queries t2
- on t1.query_id = t2.query_id
- group by t2.workload_group_id order by wg_mem_used desc
- ```
-
-如果是单个查询占掉了大部分内存，那么可以通过取消这个查询来快速释放内存。
-
-如果有优先级较低的workload group使用了较多的内存，那么可以通过对这个workload group进行降级来释放内存：
-1. 如果内存配置的是软限，那么可以修改为硬限，并减小workload group的内存限制
-2. 通过workload group的排队功能降低这个workload的查询并发
-
-### 找出扫描数据量过高的查询
-目前Doris没有直接收集查询的磁盘IO的指标，不过可以通过扫描数据的行数和字节数进行间接的判断
-
-1. 扫描数据量topN的sql
+4. 扫描数据量topN的sql
```
select
t2.query_id,
@@ -211,7 +134,7 @@ Doris支持通过Workload系统表对运行中的工作负载的资源使用情
order by scan_rows desc,scan_bytes desc limit 10;
```
-2. 各个workload group的scan数据量
+5. 各个workload group的scan数据量
```
select
t2.workload_group_id,
@@ -224,7 +147,16 @@ Doris支持通过Workload系统表对运行中的工作负载的资源使用情
group by t2.workload_group_id
order by wg_scan_rows desc,wg_scan_bytes desc
```
-
-如果是单个sql的scan数据量较大，那么可以通过杀死查询的方式查看是否会有缓解
-
-如果是某个workload group的扫描数据量较大，那么可以通过调低workload group的扫描线程数来降低IO
\ No newline at end of file
+
+6. 查看各个workload group排队的都是哪些查询，以及排队的时间
+ ```
+ select
+ workload_group_id,
+ query_id,
+ query_status,
+ now() - queue_start_time as queued_time
+ from
+ active_queries
+ where query_status='queued'
+ order by workload_group_id
+ ```
\ 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
