活动专区

活动公告

上车！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 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` | 临时分析 | 低优先级，严格限额 |

示例脚本可以按这个思路写，具体语法和参数以当前版本环境为准：

```sql
-- 账号拆分示例
create user app_oltp identified by '***';
create user app_report identified by '***';
create user app_batch identified by '***';

-- 授权只给必要 schema，不建议共享高权限账号
grant usage on schema ods to app_report;
grant select on all tables in schema ods to app_report;

grant usage on schema dwd to app_batch;
grant select, insert, update, delete on all tables in schema dwd to app_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` | 临时分析账号 | 很低 | 申请制 | 重点看是否影响主业务 |

伪代码如下，主要表达配置思路：

```sql
-- 资源池创建示例，参数名称以当前版本为准
create resource pool rp_oltp
with (
    mem_percent = 35,
    active_statements = 80,
    max_dop = 1
);

create resource pool rp_report
with (
    mem_percent = 25,
    active_statements = 12,
    queue_timeout = 600
);

create resource pool rp_batch
with (
    mem_percent = 30,
    active_statements = 8,
    queue_timeout = 1800
);

-- 用户绑定资源池示例
alter user app_oltp resource pool rp_oltp;
alter user app_report resource pool rp_report;
alter user app_batch resource pool rp_batch;
```

这里的数值不是通用答案。真正落地时，我会从保守值开始，先保障核心业务不抖，再根据一周的峰谷曲线调整。资源池最怕一开始就配得很激进，看起来充分利用资源，实际没有缓冲空间。

## 监控不要只看系统 CPU

资源池做完以后，如果监控还只是 CPU、内存、磁盘 IO，很多问题仍然看不清。我会补三类数据库侧指标：谁在跑、谁在等、谁被限制。

```sql
-- 当前活跃会话，按用户和状态聚合
select usename,
       state,
       count(*) as sess_cnt
  from pg_stat_activity
 group by usename, state
 order by sess_cnt desc;

-- 长时间运行 SQL
select usename,
       now() - query_start as running_time,
       state,
       substr(query, 1, 120) as sql_text
  from pg_stat_activity
 where state &lt;&gt; 'idle'
   and query_start &lt; now() - interval '10 minutes'
 order by running_time desc;

-- 按业务账号观察连接是否异常放大
select usename,
       client_addr,
       count(*) as conn_cnt
  from pg_stat_activity
 group by usename, client_addr
 order by conn_cnt desc;
```

如果环境中有资源池相关视图或 WLM 视图，我会把等待队列、资源池命中、作业结束原因也纳入巡检。没有这些信息时，至少要从会话、SQL 时长、应用账号维度做基础观察。资源治理不是配完参数就结束，后面需要用数据证明配置有没有效果。

## 白天和夜间可以不是一套策略

很多库的资源争抢是时间型的。白天接口优先，晚上批处理优先。如果一套资源池策略全天不变，就会出现白天批处理干扰接口，或者夜间报表资源太小跑不完。我的做法是把资源池和调度窗口联动起来。

一个简单的方式是在调度系统里控制批任务提交时间，并在任务开始前切换批处理用户的资源池参数，任务结束后恢复。这里要特别注意变更审计和失败回滚，不能脚本跑一半失败导致白天还留着夜间策略。

```sql
-- 夜间窗口开始前，放宽批处理并发
alter resource pool rp_batch with (
    active_statements = 16,
    mem_percent = 45
);

-- 白天窗口恢复
alter resource pool rp_batch with (
    active_statements = 4,
    mem_percent = 15
);
```

我会把这类变更放进标准变更脚本，并在脚本里写入检查项：

```sql
-- 变更前确认没有异常长事务
select usename, now() - xact_start as xact_age, state, substr(query,1,100)
  from pg_stat_activity
 where xact_start is not null
   and now() - xact_start &gt; interval '30 minutes';

-- 变更后记录资源池参数快照，便于回溯
-- 可结合现场资源池视图或配置命令输出落库
```

## 资源池和 SQL 改造要一起做

资源池能避免一个业务拖垮另一个业务，但不能把坏 SQL 变成好 SQL。比如报表账号被限制以后，报表只是排队更久，根因可能还是没有筛选条件、统计信息失真、临时表设计不合理、宽表字段读取过多。

我一般会把治理动作分成两张清单：

| 资源侧动作 | SQL 侧动作 |
|---|---|
| 拆账号、绑定资源池 | 补谓词、减少全表扫描 |
| 限制并发和队列 | 优化关联条件和分布键 |
| 调整时段策略 | 拆分超大聚合任务 |
| 监控等待和执行时长 | 固化执行计划观察点 |
| 限制临时分析账号 | 推动临时需求入调度流程 |

这两边要一起推进。只调资源池，业务会觉得“数据库更慢了”；只改 SQL，下一次临时分析高峰还是可能把系统打满。

## 参数调整要留下回退线

资源池参数有一个很现实的问题：调整后可能短期看不出效果，也可能某个边界设得太紧，导致业务排队明显。我的习惯是每次只改一到两个变量，观察一个完整业务周期，再决定是否继续。

| 调整动作 | 观察指标 | 回退信号 |
|---|---|---|
| 降低报表并发 | 在线接口响应、报表等待时间 | 报表 SLA 明显超时 |
| 增加批处理资源 | 夜间总耗时、白天残留任务 | 批处理越过夜间窗口 |
| 收紧临时查询 | 临时账号等待和失败数 | 正常排障查询受阻 |
| 提高在线账号保障 | CPU 利用率、短查询 P95 | 整体资源闲置过多 |

我不太喜欢一次性做大范围参数重构。资源治理最需要可解释：为什么改、改了什么、预期改善什么、多久回看、怎么回退。这样业务方也更容易接受。

## 一个现场可用的治理闭环

最后我会把 GBase 8c 资源池治理整理成一个闭环：

1. 先按业务拆账号，不让在线、报表、批处理混用同一账号。
2. 建资源池时先保核心业务，再给分析和批处理留边界。
3. 把资源池参数、账号绑定、调度窗口写入运维台账。
4. 每天看活跃会话、长 SQL、等待队列、资源池命中情况。
5. 每周回看一次峰值和 SLA，再做小幅参数调整。
6. 对超过阈值的 SQL 单独进入 SQL 改造流程。

从我自己的经验看，资源池真正的价值不是把机器跑满，而是让资源使用变得可预期。生产库最怕突然性，一个账号突然提交几十个大查询，一个批任务突然跨过白天窗口，一个临时分析突然占满 CPU。资源池把这些风险提前放进边界里，后续排障才不会每次都从“谁把库打满了”开始。

## 参考资料

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





GBase 8c

运维管理

GBase 8c 混合负载挤在一起时，资源池别只管并发数

GBase 8c 混合负载挤在一起时，资源池别只管并发数

评论

热门帖子