近期，出于对数据库性能的深入探究兴趣，我决定对 openGauss 在高并发环境下的表现进行一次系统性评估，旨在为未来业务系统的迁移工作提供可靠的数据支持。作为一款备受关注的开源数据库，openGauss 的稳定性与处理能力广受业界认可。为了精准模拟多维度负载场景，本次测试选用了经典的多线程压测工具 sysbench，该工具能够有效衡量 CPU、内存及数据库层面的性能指标。整个实验过程基于 Ubuntu 22.04 LTS 操作系统展开，所有操作步骤、遇到的问题以及最终结果均被完整记录，确保测试具备可复现性和参考价值。

一、测试目标与背景说明

本项测试的核心目的在于全面评估 openGauss 数据库在不同并发压力下的事务处理效率、响应延迟特性以及系统资源消耗情况，从而为后续生产环境中的参数调优提供数据依据。测试采用单机部署模式运行 openGauss，重点聚焦以下几项目标：

• 完成 sysbench 工具在 Ubuntu 22.04 系统上的安装与配置，确保其能顺利对接 openGauss 数据库；
• 利用 sysbench 模拟读写混合、纯读和纯写等典型业务负载场景，采集关键性能数据；
• 分析随着并发线程数增加，TPS（每秒事务数）、QPS（每秒查询数）及平均响应时间的变化趋势；
• 识别测试过程中出现的性能瓶颈，并提出初步优化建议。

二、测试环境搭建

为保障测试结果的准确性，测试前需完成操作系统配置、openGauss 数据库部署及相关依赖库的安装。硬件资源配置已提前规划，并严格按照标准流程执行环境准备。

2.1 系统与硬件配置

本次测试所使用的服务器为物理机，具体软硬件信息如下。测试开始前已通过命令 apt update && apt upgrade -y 对系统进行了更新维护：

配置项	具体参数
CPU	11th Gen Intel(R) Core(TM) i5-11400 @ 2.60GHz (2.59 GHz)
内存	32GB DDR5 4800MHz
磁盘	100GB NVMe SSD（读取速度约350MB/s，写入速度约300MB/s）
操作系统	Ubuntu 22.04.3 LTS（64位，内核版本 5.15.0-88-generic）
openGauss 版本	openGauss 5.0.0（单机模式）
sysbench 版本	sysbench 1.0.20

通过执行 lscpu、free -h 和 df -h 命令可分别验证 CPU、内存与磁盘空间使用情况，确保系统资源充足，避免因资源争抢影响测试数据的有效性。例如，运行 free -h 后返回的部分输出如下：

2.2 openGauss 安装与初始化配置

openGauss 数据库已完成前期部署，相关安装流程不再赘述。

三、sysbench 安装与适配配置

sysbench 支持多种测试类型，针对数据库压测需要依赖 MySQL 或 PostgreSQL 协议驱动。由于 openGauss 兼容 PostgreSQL 通信协议，因此可通过 PostgreSQL 驱动实现连接。为此，必须安装相应的客户端开发库以保证工具正常工作。

3.1 安装编译依赖与基础工具

为使 sysbench 能够正确适配 openGauss，推荐通过源码编译方式进行安装。首先需安装必要的构建工具链及 PostgreSQL 相关依赖包：

sudo apt install -y automake libtool pkg-config  
apt install -y gcc cmake make libpq-dev postgresql-client

其中，libpq-dev 是 PostgreSQL 的客户端开发库，用于支持 sysbench 与 openGauss 建立连接；而 automake 则是编译 sysbench 源码时所需的关键工具包之一。

3.2 编译并安装 sysbench

从官方 GitHub 仓库获取 sysbench 1.0.20 版本的源码包，解压后进入目录并执行自动化脚本进行配置与编译：

cd /home/omm  
wget https://github.com/akopytov/sysbench/archive/refs/tags/1.0.20.tar.gz  
tar -zxf 1.0.20.tar.gz  
cd sysbench-1.0.20  
./autogen.sh  
./configure --with-pgsql --without-mysql --prefix=/usr/local/sysbench  
make -j4  # 使用多线程编译，可根据 CPU 核心数量调整线程数  
sudo make install

编译完成后将安装路径加入系统环境变量中，以便全局调用：

echo "export PATH=/usr/local/sysbench/bin:\$PATH" >> /etc/profile  
source /etc/profile

执行 sysbench --version 命令以验证是否安装成功，若返回结果为“sysbench 1.0.20”，则表明sysbench已正确安装。

3.3 配置 sysbench 连接 openGauss

sysbench 通过 PostgreSQL 协议驱动与 openGauss 建立连接，需配置数据库类型、主机地址、端口、用户名、密码以及目标数据库名称。为了简化后续测试命令的输入，我创建了一个名为 sysbench_pg.conf 的配置文件，内容如下：

[global]
# 全局参数（必须置于 [global] 节点下，脚本方可识别）
table_size=1000000     # 每张表包含100万条数据
tables=10              # 总共创建10张测试表
range_size=100000      # 查询范围大小（可选，不影响建表操作）

[pgsql]
# PostgreSQL 数据库连接专用参数
pgsql_host=192.168.72.128
pgsql_port=5432
pgsql_db=sysbench_db
pgsql_user=gaussadmin
pgsql_password=GaussAdmin@2025

将该配置文件保存至 /home/omm 目录下，后续执行测试时可通过 --config-file 参数直接引用，避免重复填写连接信息。

四、压力测试实施流程

本次性能测试基于 sysbench 提供的 oltp_common 场景，模拟真实业务中的数据库负载情况，整体流程分为三个阶段：“数据准备”、“测试执行”和“结果记录”。测试涵盖混合读写、只读、只写三种工作模式，并在每种模式下设置不同的并发线程数（1、2、4、8、16、32、64），用于分析并发量对系统性能的影响。为保证测试准确性，测试前已关闭系统防火墙及非必要后台服务，减少外部干扰。

4.1 测试前环境准备

为确保测试结果的一致性和可靠性，在正式开始前需完成以下基础配置：

• 清理系统缓存：执行命令 sync && echo 3 > /proc/sys/vm/drop_caches，清除内存缓存，防止历史缓存影响当前测试数据；
• 调整 openGauss 最大连接数：编辑数据库配置文件 /opt/opengauss/data/postgresql.conf，将 max_connections 参数从默认值100修改为200，修改后重启数据库使配置生效；

1. 确认 gaussadmin 用户凭证有效并具备访问权限
   用户密码必须与配置文件中设定的 pgsql_password=GaussAdmin@2025 完全一致，注意区分大小写及特殊字符。
   若 openGauss 启用了远程访问控制策略，需确保 IP 地址 192.168.72.128 被允许登录。可通过检查并修改 pg_hba.conf 文件添加相应规则：

   # 编辑 pg_hba.conf（位于数据目录）
   vi /opt/opengauss/data/pg_hba.conf
   
   # 添加以下行，允许 192.168.72.0/24 网段内的 gaussadmin 用户使用密码方式连接
   host   sysbench_db   gaussadmin   192.168.72.0/24   md5
   

在运行 sysbench 测试之前，请确认满足以下前提条件，否则可能出现连接失败问题：

2. 目标数据库 sysbench_db 已存在
   使用 omm 用户登录 openGauss 并创建所需数据库：

   su - omm
   # 使用管理员账户连接数据库
   gsql -d postgres -U omm -p 5432
   

   登录成功后执行以下 SQL 语句：

   -- 创建测试用数据库
   CREATE DATABASE sysbench_db;
   
   -- 授予 gaussadmin 用户完整权限
   GRANT ALL PRIVILEGES ON DATABASE sysbench_db TO gaussadmin;
   
   -- 退出 gsql 客户端
   \q
   

3. 手动连接测试（验证环境连通性）
   使用 gsql 工具模拟 sysbench 的连接方式，验证能否正常接入数据库，确保网络和认证配置无误。

所有测试均采用统一设置：每次运行持续60秒，预热期为10秒，待系统进入稳定状态后再采集性能数据。

4.2 数据准备阶段

使用 sysbench 的 oltp_common.lua 脚本模块进行测试数据初始化。依据前述配置文件，执行以下命令生成10张测试表，每张表包含100万条记录：

sysbench --config-file=/home/omm/sysbench_pg.conf \
--test=/usr/local/sysbench/share/sysbench/oltp_common.lua \
prepare

等待命令执行完成即可，sysbench 将自动完成表结构创建和数据插入操作。

在数据生成阶段，sysbench会自动于sysbench_db数据库中创建10张表，分别为sbtest1至sbtest10。每张表均包含四个字段：id、k、c和pad，并为id字段建立主键索引。完成数据准备后，可使用openGauss的命令\d sbtest1查看表结构，并通过执行SELECT COUNT(*) FROM sbtest1;来验证数据记录数是否达到100万条。

结果显示，表已成功创建。

4.3 测试执行过程

本次性能测试划分为三种不同场景，分别模拟典型业务负载类型。每个场景下，并发线程数从1逐步增加至64，以观察系统在不同压力下的表现。测试命令主要涉及以下关键参数：--threads（设置并发线程数量）、--time（定义测试持续时间）、--warmup-time（设定预热时长）以及--db-driver（指定数据库驱动类型）等。

4.3.1 混合读写负载（oltp_read_write）

该场景用于模拟常见的综合业务负载，涵盖SELECT、INSERT、UPDATE与DELETE操作，其操作比例贴近真实应用场景。测试所用命令模板如下所示，其中[threads]需替换为具体的并发值（如1、2、4、8、16、32、64）：

sysbench --config-file=/home/omm/sysbench_pg.conf \
--test=/usr/local/sysbench/share/sysbench/oltp_read_write.lua \
--threads=[threads] \
--time=60 \
--db-driver=pgsql \
run > /home/omm/test_results/read_write_[threads].log

由于当前测试环境为双核虚拟机，资源有限，因此以4个并发线程为例执行测试：

sysbench --config-file=/home/omm/sysbench_pg.conf /usr/local/sysbench/share/sysbench/oltp_read_write.lua --threads=4 --time=60 --db-driver=pgsql run > /home/omm/test_results/read_write_4.log

4.3.2 纯读负载（oltp_read_only）

此场景仅包含SELECT查询操作，适用于模拟报表展示、数据分析等以读为主的业务场景。测试命令与混合读写类似，仅需将脚本模块更换为oltp_read_only.lua即可：

sysbench --config-file=/home/omm/sysbench_pg.conf \
--test=/usr/local/sysbench/share/sysbench/oltp_read_only.lua \
--threads=2 \
--time=60 \
--db-driver=pgsql \
run > /home/omm/test_results/read_only_2.log

考虑到前一轮四线程测试受服务器硬件配置限制，性能未完全释放，本次选择双线程进行对比测试，以便更清晰地观察效果。

4.3.3 纯写负载（oltp_write_only）

该场景聚焦于INSERT、UPDATE和DELETE操作，用于评估数据写入密集型任务的表现，例如日志记录或批量数据导入。同样采用双线程并发进行测试，命令如下：

sysbench --config-file=/home/omm/sysbench_pg.conf \
--test=/usr/local/sysbench/share/sysbench/oltp_write_only.lua \
--threads=2 \
--time=60 \
--db-driver=pgsql \
run > /home/omm/test_results/write_only_2.log

每次测试完成后，间隔5分钟再启动下一轮，确保系统资源充分恢复至稳定状态。同时，在测试过程中可通过top和iostat等工具实时监控CPU利用率及磁盘I/O状况，记录各项资源使用的峰值数据。

4.4 测试结果说明

sysbench输出的日志文件中包含多项关键性能指标，用于全面评估数据库性能：

• TPS（Transactions per Second）：每秒事务处理数，体现数据库整体事务吞吐能力；
• QPS（Queries per Second）：每秒查询次数，反映数据库的查询处理效率；
• Response time：事务响应时间，包括平均响应时间、中位数及95%分位值，衡量系统响应速度；
• Errors：测试期间发生的错误数量，用于判断系统的稳定性与可靠性。

五、测试结果分析

本次测试共采集到3组有效数据（对应3种不同场景，固定1种并发线程数），所有测试过程中未出现任何错误，表明openGauss在当前负载条件下具备良好的稳定性。以下将从多个维度对测试结果进行深入分析，并结合系统资源监控信息，揭示性能变化的内在规律。

5.1 核心性能指标汇总

为清晰展示不同场景下的性能表现，整理了三种典型工作负载的TPS、QPS及响应时间等关键指标。

表1：混合读写场景性能指标

指标	数值 / 表现	评价
平均延迟（925.9ms）	0.9 秒 / 事务	对于 3.8GB 内存 + 1000 万条数据规模，处于“正常范围”；无 swap 时可优化至约 500ms，有 swap 情况下通常在 800–1000ms 之间
95th 延迟（1191.92ms）	1.2 秒 / 事务	最大延迟为 1465ms，无极端长尾现象，反映出线程调度合理、数据库运行稳定
TPS（4.31persec）	4.31 事务 / 秒	接近该内存配置下的理论最优值（理想上限为 5–6 TPS）
QPS（86.2persec）	86.2 查询 / 秒	与TPS保持约20:1的比例，符合 oltp_read_write.lua 脚本设计逻辑，查询效率正常
错误率 / 重连数	连接、权限、索引配置均正确，无语法或环境类异常
线程公平性（65.25/0.43）	4 线程分配均匀，无线程饥饿现象	线程数量与双核 CPU 匹配良好，避免了频繁上下文切换带来的开销

表2：只读场景性能指标

指标	只读 2 线程（当前结果）	读写 4 线程（之前结果）	性能差异（只读 vs 读写）
TPS（每秒事务数）	4.99 per sec（≈5）	4.31 per sec	提升 16%
平均延迟	400.03 ms（0.4 秒）	925.90 ms（0.92 秒）	降低 57%（延迟减半以上）
95th 延迟	475.79 ms（0.48 秒）	1191.92 ms（1.19 秒）	降低 60%
最大延迟	558.72 ms	1465.83 ms	降低 62%
QPS（每秒查询数）	79.80 per sec	86.20 per sec	略降 7%，属正常波动范围
错误率	均无错误，系统稳定性优异

表3：只写场景性能指标

指标	只写 2 线程	只读 2 线程	读写 4 线程	只写场景优势（vs 最优的只读）
TPS（每秒事务数）	1132.94 per sec	4.99	4.31	提升 227 倍（从 5→1133）
平均延迟	1.76 ms（0.00176 秒）	400.03 ms	925.90 ms	降低 99.56%（从 400ms→1.76ms）
95th 延迟	3.02 ms	475.79 ms	1191.92 ms	降低 99.36%（从 475ms→3ms）
最大延迟	58.58 ms	558.72 ms	1465.83 ms	降低 90%（从 558ms→58ms）
QPS（每秒查询数）	6797.61 per sec	79.80	86.20	提升 85 倍（从 80→6800）
错误率	均无错误，系统运行高度稳定

5.2 性能变化规律分析

在配备 3.8GB 物理内存和 4 核 CPU 的服务器环境下，openGauss 展现出超出预期的整体性能表现，三种 OLTP 工作负载呈现出显著且合理的性能差异：

• 场景适配能力强：只写场景表现尤为突出，TPS高达1132.94/s，平均延迟低至1.76ms，远超同类硬件条件下的其他模式；只读场景同样优秀，TPS接近5/s，延迟控制在400ms以内，满足中小型业务系统的读取需求；混合读写场景虽受限于内存容量，导致TPS为4.31/s、平均延迟达925.90ms，但全程无错误发生，稳定性极佳，符合低配环境下的合理预期。
• 线程配置精准匹配：2线程配置适用于只写和只读场景，实现了负载均衡，无明显调度开销；而4线程则更适配复杂的读写混合任务，在保证并发能力的同时避免了因线程过多引发的性能下降，体现出优秀的并发管理机制。
• 硬件资源利用高效：尽管内存仅有3.8GB，openGauss仍能充分挖掘硬件潜力。尤其在只写场景中，性能几乎逼近物理极限；而在只读与混合场景中，缓存与CPU资源也得到了充分利用，未发现明显资源闲置或浪费现象。

六、问题与优化方向

虽然本次测试未出现功能性错误，但在高并发压力下响应时间增长较为明显。结合openGauss的技术特性与实测数据，总结如下潜在瓶颈及后续优化建议，供实际部署参考。

6.1 测试中识别的潜在问题

主要问题源于硬件配置限制，属于轻微性能制约，不影响整体优良表现：

• 在读写混合与只读场景中，由于内存容量有限，部分热点数据需通过磁盘或swap交换区加载，导致访问延迟略有上升；
• 只写场景中存在极轻微的长尾延迟（最高58.58ms），主要由正常的后台刷盘操作引起，对整体吞吐影响可忽略不计。

6.2 初步优化建议

上述优化旨在“锦上添花”，进一步释放现有硬件潜能。

6.2.1 数据库参数调优

针对读写混合场景：

• shared_buffers = 768MB：设置不超过可用内存的50%，以提高数据页缓存命中率；
• work_mem = 16MB：合理控制单个查询使用的内存量，防止因内存过度分配导致OOM或swap启用。

6.2.3 应用层优化建议

针对不同业务类型，合理设置应用线程数可有效提升数据库性能利用率：对于纯写入型业务，建议保持 2 个线程，避免过度并发导致资源争抢；纯读取型业务可根据负载情况配置为 2 至 4 个线程，以增强并行查询处理能力；而读写混合型业务则推荐使用 4 个线程，在保障响应延迟的同时最大化系统吞吐。

6.2.2 系统环境优化

在操作系统层面进行针对性调优，有助于进一步释放硬件潜力。首先，将 CPU 调度策略由默认的 CFS 切换为实时调度（RT），可显著提高数据库进程的 CPU 占有权重，降低任务等待时间。其次，磁盘 I/O 性能方面，启用 mq-deadline 作为 IO 调度器，并关闭磁盘缓存刷新的同步机制，有助于减少 IO 延迟，提升整体响应速度。

同时，停用系统中非必要的后台服务，如 Ubuntu 中的自动更新、日志审计等功能，能够有效释放内存与 CPU 开销，集中资源服务于数据库运行。此外，通过将 vm.swappiness 设置为 10，降低系统对 swap 的依赖，减少因内存交换引发的额外磁盘 IO 操作。若硬件条件允许，替换为 SSD 存储设备，将进一步强化读写及只读场景下的性能表现。

只写场景参数调整：

• wal_buffers = 16MB：增加 WAL 日志缓存容量，减少频繁的顺序写刷盘操作；
• checkpoint_completion_target = 0.95：延长检查点完成窗口，使数据刷盘过程更平滑，缓解长尾延迟问题；
• max_worker_processes = 4：根据 CPU 核心数量合理配置工作进程数，增强写事务的并发处理能力。

只读场景参数优化：

• shared_buffers = 800MB：尽可能扩大共享缓冲区，提升热数据命中率；
• effective_cache_size = 1.3GB：帮助查询规划器更准确地评估执行计划，优化复杂查询效率；
• 关闭写相关冗余配置，如 max_wal_senders = 0，释放被占用的内存资源。

通用参数调优：

• wal_buffers = 8MB：在 WAL 写入频率和内存消耗之间取得平衡；
• checkpoint_timeout = 30min：适当拉长检查点间隔，降低周期性刷盘带来的 IO 高峰。

七、测试总结

在配备 3.8GB 内存的低配服务器上，openGauss 展现出远超预期的 OLTP 性能，堪称“低配硬件上的性能王者”。在只写场景下，TPS 超过千次，延迟稳定在毫秒级别，体现出强大的高并发写入能力；只读场景中，响应延迟低且运行稳定，足以应对中小规模的读密集型业务需求；尽管读写混合场景受到硬件资源限制，但仍能保持无错误运行、任务调度均衡，具备良好的业务适应性。

总体来看，即便在资源受限的环境中，openGauss 依然能够根据不同业务特征精准调优，发挥出卓越的性能水平。其出色的稳定性、高效的资源利用能力以及优秀的事务处理性能，使其成为满足中小规模 OLTP 业务需求的理想选择。