GaussDB(DWS)的资源池监控视图
一、历史背景
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;
- 点赞
- 收藏
- 关注作者
评论(0)