活动专区

活动公告

上车！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 写入高峰抖一下，我通常会先看检查点和 WAL

我最近看 GBase 8c 运维资料时，对写入抖动这类问题又做了一次整理。很多现场反馈会说“CPU 不高、SQL 也不复杂，但某个时间点插入和更新突然慢了一截”。这种问题不一定是锁，也不一定是 SQL 写法，写入链路里的 WAL、刷盘、检查点节奏经常是关键变量。

GBase 8c 使用预写式日志 WAL，也就是数据页真正落盘前，变更记录要先写入日志。这个机制保证了异常恢复能力，但也意味着写入性能和日志目录、磁盘延迟、检查点频率、后台刷脏节奏关系很密切。写入高峰一到，如果检查点过密或者刷盘压力集中，就会出现短时间响应变慢。

## 写入链路里我会盯哪些点

从落地角度看，一条更新语句不是只改内存里的数据页这么简单。它至少会带来 WAL 记录、脏页、事务提交、后续检查点等动作。

| 环节 | 关注点 | 异常时的表现 |
| --- | --- | --- |
| WAL 写入 | 日志文件是否持续增长，磁盘是否延迟高 | 提交变慢、日志目录压力大 |
| 脏页积累 | 后台是否能平滑刷盘 | 高峰后集中刷盘，I/O 抖动 |
| 检查点 | 触发是否太频繁 | 周期性写入卡顿 |
| 归档或备份 | WAL 是否及时转储 | 日志目录膨胀，恢复链路风险变高 |
| 分布式节点 | CN、DN 负载是否一致 | 某个 DN 写入延迟拖慢整体 |

真正排查时，我不会只看数据库内部。磁盘层面的 `await`、`util`、日志目录空间、文件系统延迟也要一起看。数据库参数只能解释一部分，底层 I/O 才是写入稳定性的地基。

## 先确认是不是周期性抖动

写入抖动最怕凭感觉判断。我的习惯是先把时间线拉出来，看它是不是有明显周期。如果每隔一段时间慢一下，且慢点和日志切换、检查点、备份任务、批处理任务重合，就有继续深挖的价值。

可以先从会话和等待入手。

```sql
-- 查看当前活跃会话，观察是否集中卡在写入或提交阶段
SELECT
    datname,
    usename,
    state,
    wait_event,
    wait_event_type,
    query_start,
    left(query, 120) AS sql_text
FROM pg_stat_activity
WHERE state &lt;&gt; 'idle'
ORDER BY query_start;
```

再看后台进程日志，关注检查点相关信息、WAL 切换、归档异常、磁盘写入报错。GBase 8c 的运行日志、WAL 日志、性能日志各有用途，不能只看 SQL 错误日志。WAL 对异常恢复很关键，日志目录也不能只当普通文件目录看待。

## 常见参数不要孤立理解

写入抖动治理里，参数经常被单独拿出来调。我的理解是，这些参数要一起看：检查点间隔、WAL 容量、刷盘节奏、维护窗口、磁盘能力，任何一块单独调大或调小都可能带来副作用。

| 参数或对象 | 关注方向 | 调整思路 |
| --- | --- | --- |
| `checkpoint_timeout` | 时间触发检查点的间隔 | 太短会增加检查点频率 |
| `max_wal_size` | WAL 增长触发检查点的空间上限 | 太小容易因 WAL 压力提前触发 |
| `checkpoint_completion_target` | 检查点写盘分散程度 | 倾向于让刷盘更平滑 |
| `wal_buffers` | WAL 缓冲能力 | 高并发写入可评估是否偏小 |
| `synchronous_commit` | 提交等待策略 | 影响事务持久性和提交延迟，需要谨慎评估 |
| WAL 所在磁盘 | 顺序写能力和延迟 | 建议和数据、归档压力分开评估 |

我不会在不了解业务 RPO、持久性要求的情况下随意动 `synchronous_commit`。有些场景为了吞吐愿意接受提交延迟策略变化，但金融、交易、账务类系统通常不能只按性能目标处理。

## 一段比较常见的现场现象

某个系统白天业务写入平稳，晚上 22 点有一批状态回写任务。任务开始后，数据库没有出现大量锁等待，CPU 也不满，但应用侧插入延迟从几十毫秒抖到几百毫秒。查看磁盘发现 WAL 目录所在盘写入很高，运行日志里检查点比较密集。

这类问题我会按下面顺序处理。

```sql
-- 1. 先记录当前关键参数
SHOW checkpoint_timeout;
SHOW max_wal_size;
SHOW checkpoint_completion_target;
SHOW wal_buffers;
SHOW synchronous_commit;

-- 2. 查看业务侧高峰窗口内的活跃 SQL
SELECT
    now() AS snap_time,
    datname,
    usename,
    wait_event_type,
    wait_event,
    count(*) AS session_cnt
FROM pg_stat_activity
WHERE state &lt;&gt; 'idle'
GROUP BY datname, usename, wait_event_type, wait_event
ORDER BY session_cnt DESC;
```

然后结合系统命令看磁盘，不只看平均值，更要看高峰窗口内的尖峰。

```bash
# 示例命令，实际按主机环境调整
vmstat 1 10
iostat -x 1 10
df -h
```

如果发现 WAL 盘和数据盘共用同一块慢盘，参数调整空间其实有限。此时更有效的处理可能是隔离日志目录、错峰批处理、降低单批提交规模，而不是只改数据库参数。

## 批处理提交粒度会放大 WAL 压力

很多写入抖动并不是单条 SQL 慢，而是批处理把压力集中打到一个时间点。比如一口气更新几千万行状态，事务很大，WAL 生成量也大。失败后回滚成本更高，恢复压力也更明显。

我更倾向于把批处理拆成可控小批次，配合进度表和幂等条件。

```sql
-- 示例：按时间窗口分批更新，避免一个超大事务
UPDATE dwd.order_fact
SET order_status = 'CLOSED',
    update_time = current_timestamp
WHERE order_status = 'PAID'
  AND create_time &gt;= timestamp '2026-05-01 00:00:00'
  AND create_time &lt;  timestamp '2026-05-02 00:00:00';

COMMIT;
```

对于高频任务，可以把批次维度从“全表一次”改成“按日期、按分片键、按业务批次号”。这样做不只是为了减少锁影响，也能让 WAL 生成和刷盘更平滑。

| 批处理方式 | 优点 | 风险 |
| --- | --- | --- |
| 单个大事务 | 逻辑简单，提交点少 | WAL 暴涨、回滚重、检查点压力集中 |
| 按日期分批 | 容易恢复，便于追踪 | 需要处理跨日期业务 |
| 按主键范围分批 | 分布相对均匀 | 主键和业务条件不一致时要小心 |
| 按业务批次号分批 | 可审计、可重跑 | 需要作业设计配合 |

## 分布式节点要看最慢的那个

GBase 8c 分布式环境里，写入稳定性经常被某个节点拖慢。一个 DN 的 WAL 盘延迟上升，就可能让整体事务表现变差。排查时只看 CN 是不够的，DN 上的数据目录、日志目录、系统日志、磁盘压力都要一起看。

我在巡检脚本里通常会把节点维度加进去，至少保留这些信息：

```text
节点名、实例角色、数据目录空间、WAL目录空间、最近一小时日志错误数、磁盘await、磁盘util、检查点相关日志次数
```

如果条件允许，还可以把批处理窗口里的 WAL 目录增长量记录下来。单日增长量不吓人，真正有用的是“每 5 分钟增长量”和业务任务时间线之间的关系。

## 我会避免的几个动作

第一，不会一上来就把所有检查点参数调大。参数放大后，单次异常恢复时间、磁盘占用、备份归档压力都可能变化。

第二，不会只因为 WAL 多就清理 WAL 文件。WAL 与恢复链路有关，手工删除很容易把恢复能力破坏掉。要处理空间问题，应先确认归档、备份和保留策略。

第三，不会只看平均 TPS。平均值掩盖尖峰，写入抖动更需要看分钟级甚至秒级延迟。

第四，不会把批处理失败都归因于数据库。应用一次提交过大、批次没有幂等、失败重跑没有范围控制，也会制造数据库侧压力。

## 一个我比较认可的治理闭环

| 阶段 | 动作 | 目标 |
| --- | --- | --- |
| 发现 | 对齐慢点、作业、检查点、磁盘峰值 | 确认是否为写入链路抖动 |
| 验证 | 收集 WAL 增长、等待事件、I/O 指标 | 找到压力集中点 |
| 缓解 | 拆批、错峰、限制单批提交量 | 先降低业务影响 |
| 优化 | 调整检查点和 WAL 相关参数 | 平滑刷盘节奏 |
| 固化 | 加巡检、加容量预警、保留变更记录 | 防止下个高峰复现 |

写入稳定性不是一个参数能解决的问题。GBase 8c 的 WAL 和检查点机制提供了可靠性基础，现场要做的是让写入压力、刷盘压力、批处理节奏匹配起来。真正把时间线和节点维度对齐后，很多“偶发抖动”都会变得可解释。

## 参考资料

```text
GBase 8c 日志参考 https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E6%8C%87%E5%8D%97/03%20%E8%BF%90%E7%BB%B4%E7%AE%A1%E7%90%86/%E6%97%A5%E5%BF%97%E5%8F%82%E8%80%83
GBase 8c 文档介绍 https://www.gbase.cn/docs/gbase-8c/%E6%AC%A2%E8%BF%8E/
GBase 8c 管理员指南 https://www.gbase.cn/docs/gbase-8c/02%20%E7%AE%A1%E7%90%86%E5%91%98%E6%8C%87%E5%8D%97
```





GBase 8c

GBase 8c 写入高峰抖一下，我通常会先看检查点和 WAL

GBase 8c 写入高峰抖一下，我通常会先看检查点和 WAL

评论

热门帖子