GaussDB(DWS)的资源池监控视图

举报
门前一棵葡萄树 发表于 2023/12/26 17:08:06 2023/12/26
【摘要】 一、历史背景GaussDB(DWS)在8.1.3之前版本并不支持资源池监控,彼时想要查看资源池资源使用情况只能汇总资源池下用户资源监控数据得到,而用户监控数据也不是很准确,这就导致了资源池资源监控数据的缺失。此外遇到排队问题时,只能通过pgxc_session_wlmstat视图聚合后得到资源池内作业排队运行数据,对用户使用和现网问题定位很不友好。基于此,我们在8.1.3版本设计实现了资源池...

一、历史背景

GaussDB(DWS)在8.1.3之前版本并不支持资源池监控,彼时想要查看资源池资源使用情况只能汇总资源池下用户资源监控数据得到,而用户监控数据也不是很准确,这就导致了资源池资源监控数据的缺失。此外遇到排队问题时,只能通过pgxc_session_wlmstat视图聚合后得到资源池内作业排队运行数据,对用户使用和现网问题定位很不友好。

基于此,我们在8.1.3版本设计实现了资源池监控视图:gs_respool_resource_info,同时每隔1分钟将资源池监控数据持久化转储一次,保存至gs_respool_resource_history系统表中。

gs_respool_resource_info视图可以同时展示作业运行信息和资源使用信息,但是不包含短查询加速信息。同时作业运行信息为内部记账数据,与实际情况可能有所不同,此外监控视图中作业运行信息为单CN数据。实际使用起来还是有些许不便,基于此,我们在8.2.1版本设计实现了资源池监控DFX视图。

二、资源池监控DFX视图

为了提升排队问题定位效率,同时提升视图易用性,设计实现资源池监控DFX视图:gs_respool_monitor,用于显示所有资源池作业运行信息及资源使用信息。

视图包含字段如下:

名称

类型

描述

rpname

name

资源池名称。

nodegroup

name

资源池所属逻辑集群的名称,默认集群显示“installation”。

cn_count

bigint

集群包含的CN数量,多CN环境下用于判断单CN管控结果是否合理。

short_acc

boolean

资源池是否开启短查询加速。

session_count

bigint

关联该资源池的会话数量,即关联该资源池的用户发起的会话数量,包含IDLE和ACTIVE会话。

active_count

bigint

关联该资源池的活跃会话数量,即正在执行查询的会话数量。

global_wait

bigint

关联该资源池的所有作业中,因单CN上并发超max_active_statements引起排队的作业数。

fast_run

bigint

关联该资源池的所有作业中,正在资源池快车道运行的作业数。

fast_wait

bigint

关联该资源池的所有作业中,在资源池快车道排队的作业数。

fast_limit

bigint

资源池快车道作业并发上限。

slow_run

bigint

关联该资源池的所有作业中,正在资源池慢车道运行的作业数。

slow_wait

bigint

关联该资源池的所有作业中,在资源池慢车道排队的作业数。

slow_limit

bigint

资源池慢车道作业并发上限。

used_mem

text

资源池在所有DN上已用内存的平均值,显示结果已使用pg_size_pretty格式化。

estimate_mem

text

资源池正在运行的作业估算内存之和,显示结果已使用pg_size_pretty格式化。

mem_limit

text

资源池可用内存的上限,显示结果已使用pg_size_pretty格式化。

query_mem_limit

name

资源池内单个查询可以使用的内存上限,主要用于限制查询估算内存,防止估算内存过大导致异常排队;通过估算内存限制查询实际使用内存,显示结果已使用pg_size_pretty格式化。

used_cpu

double precision

资源池在所有DN上占用CPU核数的平均值;CPU隔离以节点和资源池为单位,单个节点上包含多个DN时,资源池在单节点上占用的CPU核数需要乘以DN数。

cpu_limit

double precision

资源池在所有节点上可用CPU上限的平均值,CPU配额管控情况下为GaussDB全部可用CPU核数,CPU限额管控情况下为关联控制组的可用CPU核数。

read_speed

text

资源池在所有DN上逻辑IO读速率的平均值,显示结果已使用pg_size_pretty格式化。

write_speed

text

资源池在所有DN上逻辑IO写速率的平均值,显示结果已使用pg_size_pretty格式化。

send_speed

text

资源池在所有DN上网络发送速率的平均值,显示结果已使用pg_size_pretty格式化。

recv_speed

text

资源池在所有DN上网络接收速率的平均值,显示结果已使用pg_size_pretty格式化。

三、应用示例

8.2.1前定位排队问题只能使用pgxc_session_wlmstat视图汇总得到资源池作业运行信息:

SELECT s.resource_pool AS rpname, s.node_group, COUNT(1) AS session_cnt, 
	SUM(CASE WHEN a.state = 'active' THEN 1 ELSE 0 END) AS active_cnt, 
	SUM(CASE WHEN s.enqueue = 'Global' THEN 1 ELSE 0 END) AS global_wait, 
	SUM(CASE WHEN s.lane = 'fast' AND s.status = 'running' THEN 1 ELSE 0 END) AS fast_run, 
	SUM(CASE WHEN s.lane = 'fast' AND s.status = 'pending' AND s.enqueue NOT IN ('Global', 'None') THEN 1 ELSE 0 END) AS fast_wait, 
	SUM(CASE WHEN s.lane = 'slow' AND s.status = 'running' THEN 1 ELSE 0 END) AS slow_run, 
	SUM(CASE WHEN s.lane = 'slow' AND s.status = 'pending' AND s.enqueue NOT IN ('Global', 'None') THEN 1 ELSE 0 END) AS slow_wait, 
	SUM(CASE WHEN s.status = 'running' THEN s.statement_mem ELSE 0 END) AS est_mem 
FROM pg_catalog.pgxc_session_wlmstat s, pg_catalog.pgxc_stat_activity a
WHERE s.threadid = a.pid(+)
	AND s.attribute != 'Internal'
	AND s.resource_pool != 'root'
GROUP BY 1, 2;

然后使用作业监控视图确认是否正常排队,确认是否正常排队需要确定队首作业内存和正在运行作业估算内存之和是否达到排队标准;此外如果是估算内存过大问题,还需要使用作业监控视图排查估算内存过大的作业。

在现网很多场景下,只能手写SQL查询,而现场写以上查询可能需要很久,给定位带来巨大困难。

而8.2.1版本在定位以上问题就很简单了,使用以下SQL即可定位上述问题:

-- 查询资源池作业运行信息和正在运行作业估算内存之和
select rpname,active_count,global_wait,fast_run,fast_wait,fast_limit,slow_run,slow_wait,slow_limit,estimate_mem,mem_limit from gs_respool_monitor;
-- 查询作业监控信息确认是否正常排队
select rpname,query_start,duration,lane,status,queue,estimate_mem from gs_query_monitor;
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。