GBase 8c 混合负载挤在一起时，资源池别只管并发数
GBase 8c 混合负载挤在一起时，资源池别只管并发数
我最近看 GBase 8c 资源负载管理资料时，有个感受比较强：资源池不是单纯拿来“限制一下并发”的。现场真正难处理的是混合负载，白天有在线查询，晚上有批处理，某些接口还会突然把一个复杂统计 SQL 打到库上。如果只靠应用侧约定，或者只靠连接池最大连接数，数据库侧还是可能被少数重 SQL 拖住。
从落地角度看，GBase 8c 资源池可以把用户、作业和资源边界联系起来，结合 Cgroup 做主机资源隔离，并提供 SQL 并发控制能力。这里最容易走偏的地方，是把资源池理解成“谁慢就给谁调大”。我更倾向于先按业务重要性和负载类型划圈，再给资源池配置边界，最后用实际运行数据回调。
资源池要解决的不是单个慢 SQL
很多人第一次接触资源池，是因为某条 SQL 慢或者某个批处理把库打满了。单条 SQL 慢，当然可以看执行计划、统计信息、索引、数据分布；但资源池更适合处理另一类问题：多个业务共享同一套 GBase 8c 环境时，如何避免彼此抢资源。
我一般会把场景分成三类：
| 负载类型 | 典型 SQL | 风险 | 资源池关注点 |
|---|---|---|---|
| 在线交易/接口查询 | 主键查、短事务、小范围查询 | 被批处理挤压，响应时间抖动 | 并发稳定、单 SQL 不宜过重 |
| 报表分析 | 多表关联、聚合、排序 | 吃内存和 CPU，容易排队 | 并发上限、内存边界、执行时段 |
| 批量加工 | INSERT SELECT、清洗、汇总 | 长时间占用资源 | 时间窗口、队列、失败重试 |
如果把这三类负载放在同一个用户、同一个连接池、同一套资源边界里，现场排障会很被动。因为数据库看到的只是很多会话，无法稳定区分哪些该保、哪些该等、哪些该挪到低峰执行。
先按用户和业务拆边界
我更倾向于先从账号体系入手，而不是直接建一堆资源池。账号如果已经混在一起，资源池很难发挥作用。比如app_user同时跑在线接口、日报、临时查询，后面再做资源管控就会很别扭。
一个比较容易落地的拆法是：
| 账号 | 业务类型 | 资源策略 |
|---|---|---|
app_oltp | 在线接口 | 保守并发，优先保障响应 |
app_report | 固定报表 | 限制并发，允许排队 |
app_batch | 夜间加工 | 绑定批处理资源池 |
app_ad hoc | 临时分析 | 低优先级，严格限额 |
示例脚本可以按这个思路写，具体语法和参数以当前版本环境为准：
-- 账号拆分示例createuserapp_oltp identifiedby'***';createuserapp_report identifiedby'***';createuserapp_batch identifiedby'***';-- 授权只给必要 schema，不建议共享高权限账号grantusageonschemaodstoapp_report;grantselectonalltablesinschemaodstoapp_report;grantusageonschemadwdtoapp_batch;grantselect,insert,update,deleteonalltablesinschemadwdtoapp_batch;账号拆好以后，再谈资源池才有意义。否则今天限制的是报表，明天发现接口也用这个账号，最后只能把限制放开，资源治理就回到了原点。
并发数不是唯一指标
很多现场喜欢把资源池的第一个参数设成并发数。并发当然重要，但并发数只解决“同时跑几个”的问题，不解决“每个有多重”的问题。一个小查询 100 并发不一定压垮系统，一个大排序 5 并发就可能把内存和临时空间打满。
我通常会把资源边界拆成四层：
| 层次 | 关注点 | 常见现象 |
|---|---|---|
| 会话层 | 连接数、活跃会话数 | 连接池放大后排队严重 |
| SQL 层 | 单 SQL 内存、执行时间 | 大排序、大 hash 关联拖慢全局 |
| 队列层 | 等待数量、等待时间 | 报表集中提交时堆积 |
| 主机层 | CPU、IO、内存 | 节点负载不均，系统抖动 |
GBase 8c 资料里提到资源池通过绑定 Cgroups 管理主机资源，同时提供 SQL 并发控制能力。我自己的理解是，资源池要和 SQL 治理配合用：资源池给边界，SQL 改造降单次消耗，调度系统控制时间窗口。只做其中一项，都容易留下缺口。
一个混合负载资源池设计样例
假设某套 GBase 8c 支撑客户查询、经营报表和夜间汇总。集群不是特别大，白天最怕接口超时，晚上最怕批处理跑不完。我会先给出一个偏保守的初始方案。
| 资源池 | 绑定账号 | 并发建议 | 使用窗口 | 调整方向 |
|---|---|---|---|---|
rp_oltp | app_oltp | 中等，避免无限放大 | 全天 | 重点看 P95 响应 |
rp_report | app_report | 较低，允许排队 | 白天低并发、晚间放宽 | 重点看等待时间 |
rp_batch | app_batch | 夜间放开，白天收紧 | 夜间为主 | 重点看总耗时 |
rp_temp | 临时分析账号 | 很低 | 申请制 | 重点看是否影响主业务 |
伪代码如下，主要表达配置思路：
-- 资源池创建示例，参数名称以当前版本为准createresource pool rp_oltpwith(mem_percent=35,active_statements=80,max_dop=1);createresource pool rp_reportwith(mem_percent=25,active_statements=12,queue_timeout=600);createresource pool rp_batchwith(mem_percent=30,active_statements=8,queue_timeout=1800);-- 用户绑定资源池示例alteruserapp_oltp resource pool rp_oltp;alteruserapp_report resource pool rp_report;alteruserapp_batch resource pool rp_batch;这里的数值不是通用答案。真正落地时，我会从保守值开始，先保障核心业务不抖，再根据一周的峰谷曲线调整。资源池最怕一开始就配得很激进，看起来充分利用资源，实际没有缓冲空间。
监控不要只看系统 CPU
资源池做完以后，如果监控还只是 CPU、内存、磁盘 IO，很多问题仍然看不清。我会补三类数据库侧指标：谁在跑、谁在等、谁被限制。
-- 当前活跃会话，按用户和状态聚合selectusename,state,count(*)assess_cntfrompg_stat_activitygroupbyusename,stateorderbysess_cntdesc;-- 长时间运行 SQLselectusename,now()-query_startasrunning_time,state,substr(query,1,120)assql_textfrompg_stat_activitywherestate<>'idle'andquery_start<now()-interval'10 minutes'orderbyrunning_timedesc;-- 按业务账号观察连接是否异常放大selectusename,client_addr,count(*)asconn_cntfrompg_stat_activitygroupbyusename,client_addrorderbyconn_cntdesc;如果环境中有资源池相关视图或 WLM 视图，我会把等待队列、资源池命中、作业结束原因也纳入巡检。没有这些信息时，至少要从会话、SQL 时长、应用账号维度做基础观察。资源治理不是配完参数就结束，后面需要用数据证明配置有没有效果。
白天和夜间可以不是一套策略
很多库的资源争抢是时间型的。白天接口优先，晚上批处理优先。如果一套资源池策略全天不变，就会出现白天批处理干扰接口，或者夜间报表资源太小跑不完。我的做法是把资源池和调度窗口联动起来。
一个简单的方式是在调度系统里控制批任务提交时间，并在任务开始前切换批处理用户的资源池参数，任务结束后恢复。这里要特别注意变更审计和失败回滚，不能脚本跑一半失败导致白天还留着夜间策略。
-- 夜间窗口开始前，放宽批处理并发alterresource pool rp_batchwith(active_statements=16,mem_percent=45);-- 白天窗口恢复alterresource pool rp_batchwith(active_statements=4,mem_percent=15);我会把这类变更放进标准变更脚本，并在脚本里写入检查项：
-- 变更前确认没有异常长事务selectusename,now()-xact_startasxact_age,state,substr(query,1,100)frompg_stat_activitywherexact_startisnotnullandnow()-xact_start>interval'30 minutes';-- 变更后记录资源池参数快照，便于回溯-- 可结合现场资源池视图或配置命令输出落库资源池和 SQL 改造要一起做
资源池能避免一个业务拖垮另一个业务，但不能把坏 SQL 变成好 SQL。比如报表账号被限制以后，报表只是排队更久，根因可能还是没有筛选条件、统计信息失真、临时表设计不合理、宽表字段读取过多。
我一般会把治理动作分成两张清单：
| 资源侧动作 | SQL 侧动作 |
|---|---|
| 拆账号、绑定资源池 | 补谓词、减少全表扫描 |
| 限制并发和队列 | 优化关联条件和分布键 |
| 调整时段策略 | 拆分超大聚合任务 |
| 监控等待和执行时长 | 固化执行计划观察点 |
| 限制临时分析账号 | 推动临时需求入调度流程 |
这两边要一起推进。只调资源池，业务会觉得“数据库更慢了”；只改 SQL，下一次临时分析高峰还是可能把系统打满。
参数调整要留下回退线
资源池参数有一个很现实的问题：调整后可能短期看不出效果，也可能某个边界设得太紧，导致业务排队明显。我的习惯是每次只改一到两个变量，观察一个完整业务周期，再决定是否继续。
| 调整动作 | 观察指标 | 回退信号 |
|---|---|---|
| 降低报表并发 | 在线接口响应、报表等待时间 | 报表 SLA 明显超时 |
| 增加批处理资源 | 夜间总耗时、白天残留任务 | 批处理越过夜间窗口 |
| 收紧临时查询 | 临时账号等待和失败数 | 正常排障查询受阻 |
| 提高在线账号保障 | CPU 利用率、短查询 P95 | 整体资源闲置过多 |
我不太喜欢一次性做大范围参数重构。资源治理最需要可解释：为什么改、改了什么、预期改善什么、多久回看、怎么回退。这样业务方也更容易接受。
一个现场可用的治理闭环
最后我会把 GBase 8c 资源池治理整理成一个闭环：
- 先按业务拆账号，不让在线、报表、批处理混用同一账号。
- 建资源池时先保核心业务，再给分析和批处理留边界。
- 把资源池参数、账号绑定、调度窗口写入运维台账。
- 每天看活跃会话、长 SQL、等待队列、资源池命中情况。
- 每周回看一次峰值和 SLA，再做小幅参数调整。
- 对超过阈值的 SQL 单独进入 SQL 改造流程。
从我自己的经验看，资源池真正的价值不是把机器跑满，而是让资源使用变得可预期。生产库最怕突然性，一个账号突然提交几十个大查询，一个批任务突然跨过白天窗口，一个临时分析突然占满 CPU。资源池把这些风险提前放进边界里，后续排障才不会每次都从“谁把库打满了”开始。
参考资料
GBase 8c 开发者指南 资源负载管理 https://www.gbase.cn/docs/gbase-8c/03%20%E5%BC%80%E5%8F%91%E8%80%85%E6%8C%87%E5%8D%97/%E8%B5%84%E6%BA%90%E8%B4%9F%E8%BD%BD%E7%AE%A1%E7%90%86 GBase 8c 工具参考 gs_cgroup https://www.gbase.cn/docs/gbase-8c/04%20%E5%B7%A5%E5%85%B7%E5%8F%82%E8%80%83/02%20%E6%9C%8D%E5%8A%A1%E7%AB%AF%E5%B7%A5%E5%85%B7/gs_cgroup GBase 8c SQL参考 SQL语法 https://www.gbase.cn/docs/gbase-8c/05%20SQL%E5%8F%82%E8%80%83/SQL%E8%AF%AD%E6%B3%95