活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# 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 卡住，收益往往非常明显。

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

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

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

再建静态池和动态池：

```sql
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;
```

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

```sql
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`。
这个状态我个人非常看重，因为它意味着资源管控开始发挥作用了——系统没有无边界继续放任务进去，而是在有意识地排队。

### 我现场里一般先看这些

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

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

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

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

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

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

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

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

### 一个用户磁盘限额示意

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

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

```sql
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 现场。因为只要顺序理顺了，很多原来看起来很乱的“性能问题”，最后其实都能回到资源治理这条线上来。

## 参考资料

```text
[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
```





运维管理

GBase 8a 资源管理研究

GBase 8a 资源管理研究

评论

热门帖子