GBase 8a 资源管理研究

我最近看 GBase 8a 这块资料时，一个感受特别明显：很多现场里数据库变慢，不一定是 SQL 本身突然变差了，也不一定是机器突然不够了，更常见的情况其实是任务类型混在一起以后，资源开始互相抢。白天临时报表一上来，夜里跑批没跑完；批量导入刚开始，分析查询就跟着抖；有些环境看起来 CPU 还没完全打满，但会话已经开始排队，最后大家都觉得“8a 这次怎么突然不稳”。

我自己理解下来，GBase 8a 这类 MPP 场景里，真正麻烦的从来不是单条 SQL，而是多类任务同时出现时，系统到底让谁先跑、谁多拿一点资源、谁应该排队。如果这个顺序没有提前设计，后面很多“性能问题”本质上都会变成资源争抢问题。

所以我现在看 GBase 8a 的性能现场，通常不会先问“哪个 SQL 最慢”，而是先问下面这几件事：

1. 现在系统里同时跑的是不是同一类任务。
2. 高优先级业务有没有跟批量任务混到一个入口下。
3. 并发数量、内存、I/O 和临时空间有没有做边界。

这些问题不先拆清楚，后面就算把几条 SQL 优化掉，系统整体也不一定稳。

我一般先把 8a 的资源问题分成这几类

现场现象	我优先怀疑的点	第一动作
报表一多，跑批整体变慢	没做任务分组，大家在抢同一套资源	先看用户和业务是否分流
三五个大查询一起跑，后来的都卡住	并发数量没有做限制	看 show processlist 是否出现排队
节点 CPU、内存波动很大	资源池边界没配好	先看资源池和消费者组设计
临时表空间涨得快	大查询和批量任务都在吃临时空间	先看任务类型和 max_temp_diskspace
表创建和加载把空间打满	用户侧空间边界没做	补磁盘限额，不只盯 SQL

这个拆法是我自己后来慢慢形成的。因为真正落到现场时，最怕的不是系统资源紧，而是所有任务都觉得自己更重要，结果没人让路。

一、我现在更习惯先把业务分成“谁该先跑，谁可以等”

GBase 8a 的资源管理思路，我自己更愿意把它理解成四层：

• Consumer Group：先把人或者业务分组。
• Resource Pool：给每组资源边界。
• Resource Plan：把这些资源方案组织起来。
• Resource Directive：把组和池真正装配起来。

这个设计我个人挺认同，因为它不是直接对单条 SQL 硬控，而是先把“业务身份”和“资源策略”绑定起来。跑批用户、报表用户、临时分析用户，本来就不应该拿同一套规则去跑。

我通常会先这样划分

用户/任务类型	我更倾向放在哪一类	原因
核心查询接口	高优先级组	响应时间更敏感
夜间批处理	中优先级组	可以吃资源，但不适合抢白天入口
临时报表分析	低优先级组	允许排队，避免冲击主业务
导入装载任务	独立组	常常伴随 I/O 和临时空间放大
运维巡检 / 管理操作	默认或专门组	不应该和重报表一个池子

我最近整理下来觉得，这一步比一上来调参数有用得多。因为如果业务分组本身就是乱的，后面再怎么调并发、调内存，效果都不会特别稳。

二、资源池这块，我更关心“上限”和“先后顺序”，不只是 CPU 百分比

社区和手册里对 GBase 8a 资源管控的描述比较完整，CPU、内存、I/O、临时磁盘空间、磁盘空间这些都能控，而且资源池还分静态池和动态池。 我自己理解下来，可以把它简单看成两层：

• 静态资源池 更像总盘子。
• 动态资源池 更像某一类任务实际能拿到的份额。

这个层次很关键，因为很多人一开始只盯 cpu_percent，但真正到了现场，光有 CPU 限额还不够。SQL 并发数、内存上限、临时空间这些，往往更影响系统是不是会突然抖一下。

我自己更常盯的几个项

项目	我更在意它解决什么问题
cpu_percent	避免某类任务长期把 CPU 吃满
max_memory	控制算子内存上限，避免单组任务放大
max_disk_readio / max_disk_writeio	限制读写通量，降低互相拖累
max_temp_diskspace	防止临时空间被一类任务吃穿
max_disk_space	防止表空间扩张过猛
max_activetask	明确同时允许运行多少活跃任务

这里我个人最看重的是 max_activetask。 因为很多时候，系统变慢不是因为单条 SQL 太重，而是同一批重任务一起上来了。这时先把活跃任务数控住，比单独纠结某一个 CPU 比例更直接。

三、我做资源管控时，通常会先拿“并发限制”做第一刀

社区里有一个比较直观的示例：通过资源管控把某个用户组的 SQL 并发限制为 2。 我自己很喜欢这个例子，因为它特别接近现场。很多环境里你未必一上来就想做特别复杂的资源治理，但先把最危险的高并发大 SQL 卡住，收益往往非常明显。

一个比较容易理解的配置示意

先建消费者组，把用户放进去：

create consumer group cg_report comment 'report workload';
alter consumer group cg_report add user report_user;

再建静态池和动态池：

create resource pool static_report(
  cpu_percent=100,
  max_memory=4096,
  max_disk_readio=100,
  max_disk_writeio=100,
  max_temp_diskspace=1024,
  max_disk_space=102400,
  max_activetask=10
) type static;

create resource pool dy_report(
  priority=1,
  cpu_percent=60,
  max_memory=1024,
  max_temp_diskspace=256,
  max_disk_space=4096,
  max_disk_writeio=80,
  max_disk_readio=80,
  max_activetask=2
) type dynamic base on static_report;

然后把资源计划和资源指令装配起来：

create resource plan rp_daytime;
create resource directive rd_report(
  plan_name='rp_daytime',
  group_name='cg_report',
  pool_name='dy_report'
);

create resource directive rd_default(
  plan_name='rp_daytime',
  group_name='default_consumer_group',
  pool_name='dy_report'
);

set global active_resource_plan='rp_daytime';

这套 SQL 不是为了追求“配得多复杂”，而是为了说明一个核心思路： 先把报表类任务单独拉出来，再明确告诉系统：这类任务同时最多跑几条。

这个动作最适合什么场景

场景	我为什么优先建议先做并发限制
报表和跑批混跑	大任务一起上来最容易把系统拖抖
临时分析多、SQL 不可控	先让后来的排队，系统至少不至于失控
多用户共用同一个 coordinator	比完全放开更稳
还没来得及做更细资源分级	并发限制见效快，适合先止血

四、现场里真正好用的观察点，不是“慢没慢”，而是有没有开始排队

我自己排这类问题时，很少只看“某条 SQL 执行几秒”。 更关键的其实是：系统是不是已经开始排队了。

社区的示例里就展示过，当同组用户连续发起 3 个大查询，而资源池只允许 2 个活跃任务时，第三个会话会在 show processlist 里显示 waiting in res pool。 这个状态我个人非常看重，因为它意味着资源管控开始发挥作用了——系统没有无边界继续放任务进去，而是在有意识地排队。

我现场里一般先看这些

show processlist;
show status like '%mem%';
show status like '%thread%';

如果已经做过资源管控，我会特别盯这两类现象：

现象	我会怎么理解
waiting in res pool	资源池限制开始生效，系统在做有边界排队
大量 SQL 都在执行中，没有等待	不一定是好事，可能资源边界没真正控住
报表用户一直拿满资源	说明资源组可能给大了
核心业务也被迫排队	说明分组和优先级可能还不合理

所以我自己更倾向于这样判断： 资源池不是为了让所有 SQL 都立即执行，而是为了让不该抢跑的任务先排队。

五、只做资源池还不够，磁盘和临时空间边界我现在也会一起考虑

这个点我后来越来越重视。 很多人做资源管理，最先想到的是 CPU 和内存，但 GBase 8a 现场里，真正把系统拖得很难受的，还有两类问题：

1. 临时空间被大查询吃得太快。
2. 某个用户持续建表、装载，把磁盘占用一路顶高。

GBase 8a 文档里除了资源池对磁盘空间的控制，还提供了用户级磁盘限额。这个能力我觉得特别适合“多团队共用集群”的环境，因为它和资源池是两个维度：前者偏任务执行过程控制，后者偏用户长期占用控制。

一个用户磁盘限额示意

create user etl_user identified by '***';
grant all on ods.* to etl_user;
grant usage on *.* to etl_user limit_storage_size=500G;

配好以后，我一般还会去看系统表里的使用现状：

select *
from information_schema.gnodes_user_diskspace_usage;

我自己更常怎么搭配使用

问题类型	我更常用的控制手段
重报表一下子把系统拖慢	资源池 + 并发限制
装载任务把临时空间吃高	限制 max_temp_diskspace
某个用户长期占表空间	用户级磁盘限额
系统整体磁盘快满	资源池磁盘上限 + 用户配额一起看

这个地方我个人比较在意一点： 资源管控和用户配额不是替代关系，而是互补关系。 只做其中一层，很多问题都控不住。

六、我自己比较容易提醒团队的几个坑

1）只建资源池，不改用户入口

资源池配得再好，如果报表、跑批、临时分析还在共用同一个用户，最后效果通常很有限。因为系统根本分不清谁是谁。

2）静态池和动态池边界没想清楚

动态资源池不是想给多少就给多少。官方文档里对动态池和静态池之间的关系有明确限制，同一静态池下动态池参数总和不能随便超配。这个边界不先看清，后面很容易配出逻辑冲突。

3）默认消费者组随便配

default_consumer_group 本来就是兜底组，如果直接把所有高资源策略都挂给默认组，最后相当于没真正分流。

4）看见排队就以为系统坏了

有了 waiting in res pool，并不一定是坏事。很多时候恰恰说明系统在按规则控流。真正要警惕的是核心业务也被低优先级任务一起拖进队列。

5）只在单节点上验证，不看多 coordinator 入口

社区示例里也提醒过，并发限制这类能力在多管理节点场景下要结合业务入口一起看。这个点我特别认同，因为只看一个 coordinator 上“控住了”，不代表整个入口层面真的控住了。

七、我现在更认可的一套 GBase 8a 资源治理顺序

如果让我现在给一个 GBase 8a 集群梳理资源策略，我通常会按这个顺序来：

1. 先按业务分用户和入口 报表、跑批、装载、临时分析，先别混在一个账户里。
2. 再做消费者组设计 先明确谁属于哪一组，再谈资源边界。
3. 然后先上并发限制 先把最危险的大并发重任务控住，系统先稳下来。
4. 再补 CPU、内存、I/O、临时空间策略 这一步更像精细化治理。
5. 最后再补用户级磁盘限额 控执行过程，也控长期占用，治理才完整。

结尾收一下

我最近重新整理 GBase 8a 资源管控这块内容时，越来越觉得这件事最难的不是语法，而是顺序。很多现场一看到慢，就先去找最慢 SQL；但真正落到系统层面，很多问题其实是任务入口没有先分开，资源边界没有先定下来，最后才表现成 SQL 慢、节点抖、会话排队。

从落地角度看，我个人更倾向于这么理解：

• 先把人和任务分组；
• 再把资源池边界定下来；
• 先控并发，再做细化资源分配；
• 执行过程靠资源池，长期占用靠用户配额。

这样做看起来没有特别花哨，但我觉得更符合 GBase 8a 现场。因为只要顺序理顺了，很多原来看起来很乱的“性能问题”，最后其实都能回到资源治理这条线上来。

参考资料

[1] 资源管理
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/

[2] GBase 8a资源管控资源管理的介绍
https://www.gbase.cn/community/post/682

[3] GBase 8a通过资源管控样例限制集群SQL并行数量
https://www.gbase.cn/community/post/681

[4] 创建和管理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

[5] 用户级磁盘限额
https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/admin-administrator-guide/admin-management-secure/admin-user-disk-limit

[6] 故障应急处理（二）- 资源使用情况异常
https://www.gbase.cn/community/post/4020

[7] GBase 8a集群查看当前运行状态，内存使用情况
https://www.gbase.cn/community/post/273