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

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

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

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

写入链路里我会盯哪些点

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

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

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

先确认是不是周期性抖动

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

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

-- 查看当前活跃会话，观察是否集中卡在写入或提交阶段
SELECT
    datname,
    usename,
    state,
    wait_event,
    wait_event_type,
    query_start,
    left(query, 120) AS sql_text
FROM pg_stat_activity
WHERE state <> '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 目录所在盘写入很高，运行日志里检查点比较密集。

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

-- 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 <> 'idle'
GROUP BY datname, usename, wait_event_type, wait_event
ORDER BY session_cnt DESC;

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

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

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

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

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

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

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

COMMIT;

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

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

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

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

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

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

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

我会避免的几个动作

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

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

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

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

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

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

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

参考资料

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