Logo

菜单

易君召
发布于 2026-09-10 / 作者：易君召 / 1 阅读
0

OpenGauss 6.0 LTS 性能优化完整方案

OpenGauss 6.0 LTS 内核亮点：Ustore 原位更新、SMP 并行增强、UWAL WAL 加速、Gazelle 用户态网络、分区表大幅优化、DBMind AI 智能调优，下面按操作系统层 → 内核参数 → 存储引擎选型 → 表结构与索引 → SQL 优化 → 集群主备复制 → 资源管控与运维监控分层优化，区分 OLTP 在线事务 / OLAP 分析场景。

一、操作系统层优化（基础，优先级最高）

1. 内核参数（sysctl.conf）

# 共享内存
kernel.shmmax = 物理内存的70%
kernel.shmall = shmmax/4k
# 网络
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
# 文件IO
fs.file-max = 1048576
vm.swappiness = 0        # 尽量禁用swap，避免数据库换页抖动
vm.overcommit_memory = 0
# THP（透明大页）：必须关闭，数据库场景会严重抖动

  • 关闭透明大页 transparent_hugepage=never

  • 文件系统：XFS 推荐，SSD 盘关闭 atime，挂载参数 noatime,nodiratime,barrier=0

  • IO 调度器：SSD 用none/mq-deadline，机械盘deadline

  • NUMA 架构（鲲鹏 / AMD/Intel 多路）

    1. 绑核：numactl 启动实例，CPU 与内存同 node 亲和

    2. 开启大页，推荐 1G 大页，提升 shared_buffers 访问效率

    3. openGauss 参数 numa_distribute_mode 控制内存分布

2. 硬件与网络

  • 数据盘、WAL 日志分开不同 SSD，WAL 盘优先高耐久 SSD，WAL 是写入瓶颈

  • 企业版可启用 Gazelle 用户态网络，北向网络零拷贝，单机 TPCC 提升约 15%，适合高吞吐 OLTP 场景openGauss

二、postgresql.conf 核心参数调优（OLTP 与 OLAP 分开）

修改方式：ALTER SYSTEM SET xxx='value';，部分参数需要重启数据库生效

内存参数（最核心）

参数

OLTP 推荐

OLAP 推荐

说明

shared_buffers

物理内存 25%

物理内存 50%

数据库页缓存，不超过 50%，防止 OS 内存不足

work_mem

8~64MB

256MB~2GB

单算子内存（排序 / HashJoin）；并发高不能设太大，否则 OOM

maintenance_work_mem

1~4GB

4~8GB

VACUUM、建索引、统计信息采集

wal_buffers

64MB

128MB

WAL 缓冲区，最大 16MB？openGauss 支持更大，减少 WAL 刷盘

max_connections

200~500

64~128

不要盲目开大；高并发优先用连接池（PgBouncer）

最佳实践：业务层使用连接池，数据库 max_connection 控制在合理范围，大量短连接会导致进程调度开销飙升。

WAL 与 Checkpoint（写入性能关键，6.0 支持 UWAL）

max_wal_size = 32GB
min_wal_size = 8GB
checkpoint_timeout = 15min        # 拉长检查点间隔，减少IO尖峰
checkpoint_completion_target = 0.9
wal_compression = on             # WAL压缩，节省磁盘、降低网络带宽
# 批量提交优化
commit_delay = 100
commit_siblings = 5

  • synchronous_commit：核心金融场景保持on；非核心业务可remote_write提升写入，有极小丢数据风险。

  • 6.0 企业版开启 UWAL，加速 XLog，主备同步复制 TPCC 提升约 20%openGauss

SMP 并行查询（OLAP / 大查询，6.0 增强）

query_dop = 1                    # OLTP=1关闭并行；OLAP设为CPU核数/2，会话可动态SET
max_parallel_workers_per_gather = 4

注意：并行查询会抢占 CPU，OLTP 业务不要全局开启 query_dop，只在报表 / ETL 会话临时打开，执行完关闭，防止在线业务 CPU 被打满华为云开发...。

优化器与统计信息

default_statistics_target = 500
enable_beta_opts = on

定期收集统计信息：

ANALYZE VERBOSE table_name;

6.0 DBMind 支持自动索引推荐、虚拟索引、workload 索引推荐，可自动发现缺失索引、统计信息老化问题。

三、存储引擎选型（openGauss6.0 多引擎，选型决定上限）

  1. Ustore（原位更新，推荐 OLTP） 替代传统 Astore，update/delete 不产生大量旧版本，减少 VACUUM 压力，大压力下性能抖动＜3%，存储空间提升 15%；高更新业务首选。 

    CREATE TABLE xxx (...) WITH (STORAGE_TYPE=USTORE);

  2. Astore（行存）：通用行存，适合读多写少 OLTP

  3. MOT 内存表：热点小表、字典表，全内存，极高吞吐，持久化有限

  4. 列存 CStore：OLAP、大报表、批量聚合，高压缩比，适合海量数据只读分析

  5. 分区表：范围 / 列表 / 哈希分区，6.0 对数千分区场景做深度优化，多分区场景查询 / 导入性能提升最高 30%；时序、订单流水强烈建议按时间做范围分区 + 自动分区扩展，减少扫描范围，清理历史数据直接 drop 分区，不产生大量日志与 vacuum 开销openGauss。

索引选型：Btree（主键 / 等值范围）、GIN（JSON / 数组）、BRIN（时序大表）；全局分区索引用于分区表跨分区查询。

四、表结构、索引与并发锁优化

  1. 索引原则

    • OLTP：只保留高频查询过滤字段索引，索引越多，INSERT/UPDATE 越慢；单表索引建议≤5

    • 避免 select *，只查询需要字段，减少 IO 与网络

    • 避免隐式类型转换（where col='123'，col 是 int），导致索引失效

  2. 锁优化（6.0 主备锁粒度优化）

    • 长事务是性能杀手，尽量缩短事务；长事务会阻碍 CSN 清理，膨胀 undo

    • 大批量更新，分批 commit，不要一次性更新千万行

    • Ustore 减少版本膨胀，降低 vacuum 压力，适合高频更新场景

  3. 表压缩：行存表开启压缩，节省存储，减少 IO，CPU 会小幅增加。

五、SQL 与执行计划优化

  1. 使用 explain analyze 查看真实执行计划，定位全表扫描、HashJoin 内存溢出（下盘临时文件）、高代价嵌套循环

  2. 6.0 内置 dbe_perf.statement，自动记录慢 SQL、端到端链路耗时；慢 SQL 阈值通过 DBMind 配置 

    select * from dbe_perf.statement order by total_time desc limit 20;

  3. 全局 PlanCache，缓存执行计划，减少重复硬解析；参数 enable_global_plancache

  4. 批量操作：COPY 代替多条 INSERT；UPSERT 合并写入；避免循环单行 DML

六、主备集群复制优化

  1. 一主多备架构，区分同步备、异步备：核心业务 1 个同步备，其他备机异步，降低主库等待延迟

  2. 6.0 优化 SyncRepLock，大粒度锁拆分，同步备场景 TPCC 提升 10%，减少主备锁竞争openGauss

  3. 备库可读：开启备机只读分担查询压力；分离读写，主库只写，报表跑备库

  4. 并行逻辑解码，提升逻辑复制（发布订阅）同步速度，适用于跨机房数据同步

七、资源管控、Cgroup、DBMind 智能运维

  1. cgroup 资源隔离 gs_cgroup：区分在线业务 / ETL 任务，防止大查询抢占在线业务 CPU、IO

  2. DBMind（6.0 内置 AI 能力）：慢 SQL 自动识别、索引推荐、参数自调优、异常预测、自动生成优化报告，企业版强烈推荐部署；对接 Prometheus+grafana 监控大盘，采集数据库指标、慢查询、锁等待、buffer 命中率

  3. 定期维护

    • Ustore/Astore 表定期 VACUUM ANALYZE，清理死元组，防止表膨胀

    • 监控指标：buffer 命中率、WAL 写入延迟、锁等待、undo 膨胀、临时文件、checkpoint IO 尖峰

    • 工具：gs_checkperf一键性能诊断；gs_collector收集故障现场信息openGauss

八、场景化调优清单

OLTP（交易，高并发短事务）

  • 引擎：Ustore 行存

  • SMP：query_dop=1，关闭并行查询

  • WAL 盘独立 SSD，UWAL 开启

  • 连接池，控制 max_connections，短连接收敛

  • 分区：时序流水表按时间分区，热点隔离

OLAP（报表，大聚合，低并发）

  • 引擎：CStore 列存，大表分区

  • query_dop 根据 CPU 核数打开并行查询

  • 增大 work_mem、maintenance_work_mem

  • 报表跑备库，主库不承担分析负载

九、常见坑与避坑

  1. shared_buffers 设太大，占用系统内存，触发 swap，性能暴跌

  2. work_mem 设置过大，并发多 SQL 同时排序，瞬间 OOM

  3. 长事务，undo / 版本堆积，表膨胀，查询越来越慢

  4. 大量不必要索引，写入 TPS 持续下降

  5. 并行查询全局开启，大报表抢占在线业务 CPU

  6. 不关闭透明大页，随机 IO 抖动，高并发性能不稳定

  7. WAL 与数据盘同一块磁盘，checkpoint 和 WAL 刷盘 IO 争抢

十、调优实施步骤（推荐顺序）

  1. 环境基线：OS 内核、文件系统、大页、NUMA 绑核、关闭 THP（先做）

  2. 硬件分离：数据盘 / WAL 盘独立 SSD

  3. 存储引擎选型、表分区设计

  4. 基础内存 / WAL 参数调优，重启生效

  5. 抓慢 SQL，explain analyze，优化索引与 SQL

  6. 开启 DBMind 监控，持续观测负载，动态微调参数

  7. 业务压测，对比 TPS、响应时间，迭代优化

3DES（Triple DES，三...
AI Agents & 开源 LL...