GBase 8a Resource Pool 队列等待和任务超时的排查记录

报表任务排队半小时后失败，业务侧通常只看到“执行超时”或“任务被取消”。但在 GBase 8a 集群里，这类问题不一定是 SQL 写得慢，也不一定是数据库整体资源不足。有时候只是任务进了不合适的资源池，或者资源池参数把并发、等待时间、运行时间限制得太紧。把所有现象都归到慢 SQL，会导致优化方向跑偏。

Resource Pool 的价值在于把集群资源按任务类别进行管理。官方文档里把资源池分成静态资源池和动态资源池，静态资源池偏资源供给，动态资源池偏任务约束。创建资源池时可以设置 CPU、内存、临时空间、最大活动任务数、任务并行度、等待超时、运行超时等属性。也就是说，一个任务最终能不能跑、能跑多久、能并发多少，并不只取决于 SQL 本身，还取决于它进入了哪个池。

先区分“正在跑慢”和“根本没跑上”

很多调度平台只记录任务开始和结束时间，不区分数据库内部是执行中还是等待中。比如任务 02:00 提交，02:30 失败，看起来像跑了 30 分钟，其实可能前 25 分钟都在队列里等资源，真正执行只跑了 5 分钟。排查时如果直接拿 SQL 去改索引、改分布键，就会错过资源池队列这个关键点。

现象	可能状态	排查重点
提交后长时间无结果	队列等待	max_activetask、task_waiting_timeout
跑到固定时长失败	运行超时	task_running_timeout
同一 SQL 白天慢、夜间快	资源竞争	资源池并发和优先级
管理员执行正常，业务账号失败	进入不同资源池	用户和资源池绑定关系
大任务一跑小任务全堵	池隔离不足	静态池/动态池拆分

真正的第一步，是确认任务有没有进入执行态。如果还在等待队列里，SQL 优化只能解决一部分问题；如果已经执行但消耗资源过高，才需要继续看执行计划、数据倾斜和临时空间。

资源池参数不要只看 CPU

很多人理解资源池时只盯 CPU 百分比，但 GBase 8a Resource Pool 里能控制的远不止 CPU。内存、临时磁盘空间、磁盘读写、最大活动任务数、单任务最大并行度、等待超时、运行超时都可能影响任务。

-- 示例：查询资源池定义，字段以现场版本为准
SHOW RESOURCE POOLS;

-- 如果现场支持更详细的系统表查询，可按资源池名称过滤
SELECT *
  FROM gclusterdb.resource_pool
 WHERE pool_name LIKE '%rpt%';

排查时我会重点看下面几个参数。

参数	关注点	容易导致的问题
priority	任务调度优先级	低优先级任务长时间等待
cpu_percent	CPU 配额	CPU 争用时吞吐下降
max_memory	内存限制	大聚合、大排序失败或频繁落盘
max_temp_diskspace	临时空间	Join、排序中间结果写爆
max_activetask	活动任务数	任务排队而不是执行
task_max_parallel_degree	单任务并行度	并行不足或资源被单任务吃满
task_waiting_timeout	等待超时	任务还没执行就失败
task_running_timeout	运行超时	长报表固定时间被杀

参数本身没有绝对好坏。比如 max_activetask 太小会排队，太大又可能让一堆任务同时抢资源；task_running_timeout 太短会误杀正常长任务，太长又会让异常 SQL 占住资源。资源池不是为了把所有值调大，而是为了让不同类型任务互不拖垮。

用户进入哪个池要查清楚

资源池排查里一个高频误区是：DBA 用管理员账号跑 SQL 很快，于是判断 SQL 没问题；业务账号跑就超时，于是又怀疑权限或网络。实际上两者可能进了不同资源池。管理员账号进入默认高资源池，业务账号进入低优先级报表池，结果自然不同。

现场应该把账号、业务系统、资源池、任务类型做一张映射表。

账号	业务系统	资源池	任务类型	备注
etl_load	数据加载	pool_load	夜间入库	高 IO、固定窗口
rpt_app	报表平台	pool_report	查询汇总	并发多、单任务中等
adhoc_user	临时分析	pool_adhoc	手工查询	优先级低、限制更严
risk_batch	风控批处理	pool_batch	长任务	运行时长较长

如果没有这张表，资源池就会变成隐性配置。任务失败时，大家只看到 SQL 和报错，看不到它背后的资源约束。建议在变更单里明确：新账号默认进入哪个池、任务预计并发是多少、峰值数据量是多少、是否允许排队、最长运行多久。

队列等待要按时间线复盘

资源池问题最怕只看结果，不看时间线。一个任务失败后，至少要还原提交时间、进入队列时间、开始执行时间、结束时间、同时段其他任务、资源池活动任务数。如果能把这些信息放在一起，很多问题会很明显。

02:00:00  rpt_app 提交日报查询 A
02:00:05  pool_report 活动任务数已满，A 进入等待
02:05:10  查询 B、C 仍在运行，占用活动名额
02:20:05  A 达到 task_waiting_timeout，被取消
02:21:00  B 执行结束，资源释放

从业务侧看，A “跑了 20 分钟失败”；从数据库侧看，A 根本没开始跑。处理方案也就不同：不是优化 A 的 SQL，而是调整报表池并发、错峰调度，或者拆分长短任务。

长短任务不要混在一个池里

同一个资源池里混放秒级查询、分钟级报表、小时级批处理，迟早会出问题。长任务占住活动任务名额，小任务排队；小任务并发太多，又会把长任务资源切得很碎。比较稳的做法是把任务按特征拆池。

任务类别	特征	资源池策略
秒级查询	并发高、单次短	控制单任务资源，保证响应
常规报表	分钟级、可排队	中等并发，明确等待超时
夜间批处理	长时间、大扫描	单独池，避开白天查询
数据加载	IO 密集、窗口固定	和报表查询隔离
临时分析	不可预期	低优先级，限制运行时长

拆池不是越细越好。池太多会增加管理复杂度，池太少又无法隔离风险。比较现实的起点是按“加载、报表、批处理、临时分析”四类拆开，再根据实际峰值调整。

不要把超时只当失败，要当保护

task_waiting_timeout 和 task_running_timeout 经常被抱怨“限制太死”。但从集群治理角度看，超时不是单纯的障碍，它也是保护机制。没有等待超时，低优先级任务可能在队列里堆一整晚；没有运行超时，异常 SQL 可能持续占用资源。

关键是超时值要和任务类型匹配。秒级接口查询等待 30 秒就该失败；夜间批处理等待 30 秒可能太短。临时分析跑 2 小时应该被限制；正式月结任务跑 2 小时可能是正常窗口。

接口类：等待 10-30 秒，运行 1-3 分钟
日报类：等待 5-15 分钟，运行 30-60 分钟
月结类：等待 30-60 分钟，运行按窗口评估
临时分析：等待低优先级，运行时长严格限制

这些值只是思路，不是模板。现场要结合硬件、数据量和 SLA 设定。重要的是每个池的超时策略要说得清楚，而不是所有账号都用同一套默认值。

资源池调整前要留证据

调大资源池参数之前，最好先留证据。包括同一时间段任务列表、资源池活动任务数、失败任务等待时间、执行计划摘要、节点资源使用情况。否则参数调大后虽然短期好了，但后续没人知道问题真正来自哪里。

一份最小记录可以这样写：

现象：rpt_app 日报 02:00 提交，02:20 超时失败
资源池：pool_report
疑似参数：max_activetask=4，task_waiting_timeout=1200
同时段任务：4 个长报表占用活动名额
判断：任务主要失败于等待队列，不是执行阶段
处理：长报表迁移到 pool_batch，pool_report 保留短报表
验证：次日同窗口无等待超时，平均排队时间下降

这种记录能避免“今天调大一个参数，明天又调回来”的循环。资源池是治理工具，不是救火按钮。

结尾总结

GBase 8a Resource Pool 排查的关键，是先判断任务到底是在等待、执行、还是被超时保护机制终止。不要把所有超时都当成 SQL 慢，也不要只盯 CPU 参数。活动任务数、等待超时、运行超时、内存和临时空间限制，都可能决定任务命运。

更稳的做法是按任务类别拆分资源池，明确账号和资源池映射，长短任务分开，加载和查询隔离。每次调整前保留时间线和证据，调整后观察完整业务窗口。这样资源池才能真正起到隔离和治理作用，而不是变成隐藏在后台的随机限制。

参考资料

[1] GBase 8a 创建和管理 Resource Pool https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/admin-administrator-guide/admin-resource-management/admin-create-manage-resourcepool
[2] GBase 社区优质文章区 https://www.gbase.cn/community/section/11