鲲鹏上 openGauss 默认参数只发挥四成性能：NUMA 绑核和大页配置的实战校准

把 openGauss 从 x86 迁到鲲鹏 920 后，Sysbench OLTP 读写测试的 TPS 只有原 MySQL 5.7 的六成左右，P99 写入延迟反而高出 50%。第一反应是“ARM 跑数据库果然不行”，但拆开看 perf 数据后发现，CPU 的 cache-misses 和跨 NUMA 内存访问占比异常高，问题不在数据库本身，而在鲲鹏的多 NUMA 架构下，进程和内存没有绑到同一个节点上。

一、 先确认 NUMA 拓扑，再谈绑核

鲲鹏 920 通常是多 NUMA 节点设计，每个 socket 有自己的本地内存控制器。openGauss 默认启动时，进程可以在任意 CPU 核上被调度，内存页也可能落在远端节点。鲲鹏社区的调优指导明确将绑核与 NUMA 亲和列为 InfluxDB 等数据库在鲲鹏上的首要优化手段：将进程与内存约束在同一 NUMA 或同一 socket，减少跨 NUMA 访问内存。

我们先用 numactl -H 确认节点的 CPU 和内存分布，然后用 numactl --cpunodebind=0 --membind=0 将 openGauss 主进程绑定到 node 0。仅这一项，TPS 就从 5200 回升到了约 6800。绑核不是可选项，是鲲鹏多 NUMA 场景下的前置条件。

二、 大页：TLB Miss 是隐性杀手

openGauss 的 shared_buffers 调大之后，普通 4K 页会导致 TLB（地址转换缓存）频繁 miss，尤其在鲲鹏的多级页表结构下，地址转换开销比 x86 更敏感。我们按鲲鹏社区建议启用了大页内存，将 shared_buffers 设置为 8GB 并配合 1G 大页（hugepagesz=1G hugepages=8）。大页生效后，perf stat 中的 dTLB-load-misses 下降了约一个数量级，复杂查询的响应时间明显更平稳。

三、 参数对齐：shared_buffers 和 wal_buffers 不能照搬 x86

默认的 shared_buffers=32MB 在鲲鹏上严重不足。我们按物理内存的 25% 调到 8GB，wal_buffers 从 512KB 调到 64MB，maintenance_work_mem 调到 2GB。这一组调整后，VACUUM 和索引创建的速度提升了 3 倍以上，对鲲鹏多核架构的并行维护操作收益尤其明显。但注意 work_mem 不能盲目调大：如果连接数超过 1000，work_mem 需要相应降低，否则每个连接的内存分配叠加会直接触发 OOM。

四、 结果与总结

最终 TPS 从默认的 5200 提升到 9800，QPS 从 21000 到 52000，P99 写入延迟从 68ms 降到 38ms，整体追平并超过了原 x86 MySQL 的基线。排查顺序可以归纳为：先 numactl 绑核消除跨节点访问 → 再开大页减少 TLB 开销 → 最后按物理内存比例调整 shared_buffers 和 wal_buffers。鲲鹏跑数据库的瓶颈，多数时候不在芯片，在“默认参数是给 x86 写的”。