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_oltpapp_oltp中等避免无限放大全天重点看 P95 响应rp_reportapp_report较低允许排队白天低并发、晚间放宽重点看等待时间rp_batchapp_batch夜间放开白天收紧夜间为主重点看总耗时rp_temp临时分析账号很低申请制重点看是否影响主业务伪代码如下主要表达配置思路-- 资源池创建示例参数名称以当前版本为准createresource pool rp_oltpwith(mem_percent35,active_statements80,max_dop1);createresource pool rp_reportwith(mem_percent25,active_statements12,queue_timeout600);createresource pool rp_batchwith(mem_percent30,active_statements8,queue_timeout1800);-- 用户绑定资源池示例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_activitywherestateidleandquery_startnow()-interval10 minutesorderbyrunning_timedesc;-- 按业务账号观察连接是否异常放大selectusename,client_addr,count(*)asconn_cntfrompg_stat_activitygroupbyusename,client_addrorderbyconn_cntdesc;如果环境中有资源池相关视图或 WLM 视图我会把等待队列、资源池命中、作业结束原因也纳入巡检。没有这些信息时至少要从会话、SQL 时长、应用账号维度做基础观察。资源治理不是配完参数就结束后面需要用数据证明配置有没有效果。白天和夜间可以不是一套策略很多库的资源争抢是时间型的。白天接口优先晚上批处理优先。如果一套资源池策略全天不变就会出现白天批处理干扰接口或者夜间报表资源太小跑不完。我的做法是把资源池和调度窗口联动起来。一个简单的方式是在调度系统里控制批任务提交时间并在任务开始前切换批处理用户的资源池参数任务结束后恢复。这里要特别注意变更审计和失败回滚不能脚本跑一半失败导致白天还留着夜间策略。-- 夜间窗口开始前放宽批处理并发alterresource pool rp_batchwith(active_statements16,mem_percent45);-- 白天窗口恢复alterresource pool rp_batchwith(active_statements4,mem_percent15);我会把这类变更放进标准变更脚本并在脚本里写入检查项-- 变更前确认没有异常长事务selectusename,now()-xact_startasxact_age,state,substr(query,1,100)frompg_stat_activitywherexact_startisnotnullandnow()-xact_startinterval30 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