作为一名数据库运维工程师，近期我突然心血来潮想要评估openGauss数据库在高并发场景下的性能表现，以便为业务系统迁移提供数据支撑。openGauss作为开源数据库的代表，其稳定性和性能备受关注，而sysbench作为一款经典的多线程压力测试工具，能精准模拟CPU、内存及数据库等多维度负载。本次测试我选择在Ubuntu22.04 LTS系统上开展，全程记录操作细节、遇到的问题及最终结果，确保内容真实可复现。

一、测试背景与核心目标

本次测试的核心需求是验证openGauss数据库在不同并发量下的事务处理能力、响应延迟及资源占用情况，为后续业务部署时的参数调优提供依据。测试环境为单机部署的openGauss，主要聚焦以下目标：

完成Ubuntu22.04系统下sysbench工具的安装与配置，确保其支持openGauss数据库测试；

基于sysbench模拟读写混合、只读、只写等典型业务场景，获取关键性能指标；

分析不同并发线程数下，openGauss的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 NVMeSSD硬盘（读写速度分别为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数据库部署与配置

这里我之前已经安装过了就不过多阐述了。

三、sysbench工具安装与配置

sysbench支持多种测试模式，针对数据库测试需依赖MySQL或PostgreSQL的驱动。由于openGauss兼容PostgreSQL协议，因此需安装PostgreSQL的客户端开发库，确保sysbench能正常连接openGauss。

3.1 安装依赖库与编译工具

sysbench需要通过源码编译安装才能更好地适配openGauss，因此先安装gcc、cmake等编译工具及PostgreSQL依赖：

|----------------------------------------------------------------------------------------------------------------|
| Bash 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

从sysbench官网下载1.0.20版本源码包，解压后通过cmake指定PostgreSQL驱动路径进行编译安装：

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| bash 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 # 在 sysbench-1.0.20 目录下执行（当前目录就是） ./autogen.sh ./configure --with-pgsql --without-mysql --prefix=/usr/local/sysbench # 编译并安装 make -j4 # 多线程编译，按 CPU 核心数调整 sudo make install |

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

执行`sysbench --version`验证安装，若输出"sysbench 1.0.20"则表示安装成功。

3.3 sysbench连接openGauss配置

sysbench通过PostgreSQL驱动连接openGauss，需指定数据库类型、连接地址、端口、用户名、密码及数据库名。为简化后续测试命令，我创建了一个配置文件sysbench_pg.conf，内容如下：

|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ini [global] # 全局通用参数（必须放在 [global] 节，脚本才会识别） table_size=1000000 # 每张表100万条记录 tables=10 # 共10张测试表 range_size=100000 # 范围查询大小（可选，不影响表创建） [pgsql] # 数据库连接专属参数（放在 [pgsql] 节） 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`设置为200（默认100），重启数据库生效；

确认 gaussadmin 用户密码正确且有访问权限

密码需与配置文件中的 pgsql_password=GaussAdmin@2025 完全一致（区分大小写、特殊字符）；

若 openGauss 启用了远程访问限制，需确保 192.168.72.128 允许 gaussadmin 登录（可检查 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 前，需确保 openGauss 满足以下条件（否则仍会连接失败）：

目标数据库 sysbench_db 已创建

su - omm

登录 openGauss 数据库（用管理员用户 omm）

gsql -d postgres -U omm -p 5432

登录后执行 SQL：

sql

-- 创建测试数据库 sysbench_db

CREATE DATABASE sysbench_db;

-- 给 gaussadmin 用户授权（确保有创建表、插入数据的权限）

GRANT ALL PRIVILEGES ON DATABASE sysbench_db TO gaussadmin;

-- 退出数据库

测试手动连接（验证环境是否正常）

用 gsql 模拟 sysbench 的连接方式，确认能正常登录：

固定测试时长：每种场景测试时长设置为60秒，预热时间10秒，确保测试进入稳定状态后再记录数据。

4.2 数据准备阶段

使用sysbench的oltp_common模块创建测试数据，基于之前创建的配置文件，执行以下命令生成10张表，每张表100万条记录：

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

接下来让sysbench创建完就行

数据生成过程中，sysbench会自动在sysbench_db数据库中创建名为sbtest1-sbtest10的10张表，每张表包含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）：

因为我虚拟机上是双核的，这里以四线程为例执行并发4线程的测试命令：

|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| bash 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：

|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| bash 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 |

其实这里其实我们从上面并发四线程得出的效果并不够好，主要是服务器配置限制了openGauss的发挥。这里我们以双线程为例执行查看效果

4.3.3 只写场景（oltp_write_only）

该场景包含INSERT、UPDATE、DELETE操作，模拟数据录入、日志写入等写密集型业务。这里一样以并发双线程为例，测试命令如下：

每种并发线程数的测试完成后，我都会间隔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 秒 / 事务 | 无极端长尾延迟（max 延迟 1465ms），说明线程调度和数据库稳定性良好 |
| TPS（4.31persec） | 4.31 事务 / 秒 | 接近 3.8GB 内存下的最优值（该配置下理论上限 5-6 TPS） |
| QPS （86.2persec） | 86.2 查询 / 秒 | 与 TPS 比例（20:1）符合 oltp_read_write.lua 脚本逻辑，无查询效率异常 |
| 错误率 / 重连数 | 0 | 数据库连接、权限、索引配置正常，无语法或环境错误 |
| 线程公平性 | 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%（正常差异） |
| 错误率 | 0 | 0 | 均无错误，稳定性拉满 |

表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） |
| 错误率 | 0 | 0 | 0 | 均无错误，稳定性拉满 |

5.2 性能变化规律分析

在 3.8GB 物理内存 + 4 核 CPU 的服务器配置下，openGauss 表现超预期，三种 OLTP 场景性能呈现鲜明且优秀的变化特征：

场景适配性极强：只写场景表现炸裂，TPS 达 1132.94 每秒，平均延迟仅 1.76ms，碾压同硬件下其他场景；只读场景表现优秀，TPS 近 5 每秒，延迟 400ms 内，满足中小规模只读业务需求；读写混合场景虽受内存限制，TPS 4.31 每秒、延迟 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，减少单个查询内存占用，避免内存溢出；

wal_buffers = 8MB，平衡 WAL 刷盘频率与内存占用；

checkpoint_timeout = 30min，延长检查点间隔，减少刷盘 IO 峰值。

只读场景参数：

shared_buffers = 800MB，最大化数据缓存空间；

effective_cache_size = 1.3GB，提升查询规划准确性，优化复杂读操作执行效率；

关闭写相关冗余配置（max_wal_senders = 0），释放内存资源。

只写场景参数：

wal_buffers = 16MB，增大 WAL 日志缓存，减少顺序写刷盘次数；

checkpoint_completion_target = 0.95，平滑刷盘过程，降低长尾延迟；

max_worker_processes = 4，匹配 CPU 核心数，提升写事务并发处理能力。

6.2.2 系统环境优化

调整CPU调度策略：将系统的CPU调度器从CFS改为RT，提升数据库进程的CPU优先级；

优化磁盘I/O：开启磁盘的IO调度器为mq-deadline，关闭磁盘缓存刷新的同步机制，减少磁盘I/O延迟；

关闭无关服务：禁用Ubuntu系统中的自动更新、日志审计等无关服务，释放系统资源。
降低 swap 依赖（设置 vm.swappiness=10），减少不必要的磁盘 IO 损耗；若条件允许更换 SSD 磁盘，可进一步放大读写 / 只读场景性能优势。

6.2.3 应用层优化建议

根据业务场景选择最优线程数：只写业务维持 2 线程，只读业务可设 2-4 线程，读写混合业务建议 4 线程，最大化适配数据库性能特征。

七、测试总结

在 3.8GB 内存的低配服务器上，openGauss 的 OLTP 性能表现远超预期，堪称 "低配硬件的性能王者"：只写场景 TPS 破千、延迟毫秒级，展现极致并发写入能力；只读场景延迟低、稳定性强，满足中小规模读业务需求；读写混合场景虽受硬件限制，但无错误、调度均衡，具备良好的业务适配性。整体而言，openGauss 在资源有限的环境下，仍能精准适配不同业务场景，发挥出超预期的性能水平，是一款性能优异、稳定性强、资源利用率高的优秀数据库，完全满足中小规模业务的 OLTP 性能需求。

Ubuntu22.04下用sysbench压力测试openGauss数据库的实践记录