测试背景
1.1 测试组件架构
1.2 测试目标
本次测试对象为Postgreql 和pfs在以curvebs为底层存储时的稳定性、可靠性、性能测试。重点测试curvebs在异常情况下，上层pg的表现
2 测试准备
2.1 测试工具 benchmarksql
BenchmarkSQL:是一款经典的开源数据库测试工具，内嵌了TPCC测试脚本，可以对EnterpriseDB、PostgreSQL、MySQL、Oracle以及SQL Server等数据库直接进行测试
使用版本：5.0
2.2 压测工具 pgbench
pgbench :postgresql 自带提供了一款轻量级的压力测试工具，按自己的需求对数据库进行性能压力测试
版本：跟随pgsql
2.3 测试环境
2.3.1 主机信息
客户端配置为：
| 机器IP | 配置 | 内核 | 可用域 |
|---|---|---|---|
| 10.182.26.25 | CPU：Intel(R)Xeon(R)E5-2670v3@2.30GHz |
内存：256GB
硬盘：2798GB|Linux 4.19.87-netease6-1
#2 SMP Mon Sep 7 07:50:31 UTC 2020 x86_64 GNU/Linux||CPU：Intel(R)Xeon(R)E5-2670v3@2.30GHz
内存：256GB
硬盘：2798GB|Linux 4.9.65-netease
#1 SMP Thu Jul 11 17:32:39 CST 2019 x86_64 GNU/Linux|pubbeta2|
curvebs物理节点：异常测试环境
curve版本： 1.2.0
磁盘调度策略：noop
操作系统内核版本：4.9.65-netease #1 SMP Thu Aug 2 03:02:48
存储节点个数: 6
硬盘型号：INTEL SSDSC2BB01
硬盘大小： 1.5T SSD
每个节点硬盘个数：20
2.3.2 curve卷大小
| 编号 | 卷类型 | 卷大小 |
|---|---|---|
| 1 | curve | 10T |
挂载10T curve卷作为数据盘，关闭卷的 QOS 限制。
2.3.4 软件环境
| 软件 | 版本 |
|---|---|
| pfs | 2.0.0 |
| Postgreql | POLARDB_11_STABLE |
3 测试指标
| 性能指标 | 说明 |
|---|---|
| tpmc | 流量指标(Throughput,简称tpmC)：按照TPC组织的定义，流量指标描述了系统在执行支付操作、订单状态查询、发货和库存状态查询这4种交易的同时，每分钟可以处理多少个新订单交易 |
| Response time | 每个请求的平均响应时间 |
| TPS | 每秒钟处理的事务数 |
| read/write requests | 用它除以总时间，得到吞吐量QPS |
| cpu% | 注意宿主机与云主机的CPU占用率，是否cpu成为瓶颈 |
| 内存 | 注意宿主机与云主机的内存使用情况 |
4 测试要点
4.1 pgbench性能测试
主要测试结果：
| 测试场景 | 事务延迟平均 (curve) | 事务延迟平均 (ceph) | TPS (curve) | TPS (ceph) | 事务延迟平均 (curve条带化) | TPS (curve条带化) |
|---|---|---|---|---|---|---|
| 10000w数据16并发用户 | 4.712 ms | 3.027 ms | 3393.83 | 5285.65 | 2.410 ms | 6639.28 |
| 10000w数据32并发用户 | 6.382 ms | 4.318 ms | 5014.27 | 7411.27 | 3.687 ms | 8677.54 |
| 10000w数据64并发用户 | 9.817 ms | 6.519 ms | 6513.94 | 9816.15 | 5.912 ms | 10824.06 |
| 10000w数据128并发用户 | 17.554 ms | 13.958 ms | 7289.05 | 9167.86 | 11.012 ms | 11620.58 |
| 10000w数据256并发用户 | 36.463 ms | 26.835 ms | 6920.91 | 9535.27 | 26.581 ms | 9625.85 |
| 测试场景 | 事务延迟平均 (curve条带化) | 事务延迟平均 (ceph) | TPS (curve条带化) | TPS (ceph) |
|---|---|---|---|---|
| 10000w数据16并发用户 | 2.410 ms | 3.027 ms | 6639.28 | 5285.65 |
| 10000w数据32并发用户 | 3.687 ms | 4.318 ms | 8677.54 | 7411.27 |
| 10000w数据64并发用户 | 5.912 ms | 6.519 ms | 10824.06 | 9816.15 |
| 10000w数据128并发用户 | 11.012 ms | 13.958 ms | 11620.58 | 9167.86 |
| 10000w数据256并发用户 | 26.581 ms | 26.835 ms | 9625.85 | 9535.27 |
详细测试过程见：
场景
描述 对数据库进行读写操作。
初始化数据 10000w ：pgbench -i -s 1000
测试策略 1.执行读写测试
16并发16线程 ： pgbench -M prepared -r -P 1 -c 16 -j 16 -T 300 pgbench
32并发32线程：pgbench -M prepared -r -P 1 -c 32 -j 32 -T 300 pgbench
64并发64线程：pgbench -M prepared -r -P 1 -c 64 -j 64 -T 300 pgbench
128并发128线程：pgbench -M prepared -r -P 1 -c 128 -j 128 -T 300 pgbench
256并发256线程:pgbench -M prepared -r -P 1 -c 256 -j 256 -T 300 pgbench
参数值 -c ：客户端并发数
-j : 线程数
-T ： benchmark测试时间 300s
scale： 测试数据量 ×10万
range : 活跃数据量
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
4.2 benchmarksql测试
主要测试结果：
| 配置参数 | tpmc (curve) | tmpc (ceph) | tpmtotal (curve) | tpmtotal (ceph) |
|---|---|---|---|---|
| warehouse=10,loadWorkers=10 |
terminals=10|14471.6|13761.2|32132.78|30787.0|
|warehouse=20,loadWorkers=20
terminals=50|25289.76|20971.92|56096.81|46643.21|
|warehouse=10,loadWorkers=100
terminals=50|29684.1|21320.66|65954.55|47420.65|
|warehouse=10,loadWorkers=50
terminals=50|26177.03|22091.9|57989.95|49161.07|
配置文件重要参数如下：
1）warehouse：
BenchmarkSQL数据库每个warehouse大小大概是100MB，如果该参数设置为10，那整个数据库的大小大概在1000MB。
建议将数据库的大小设置为服务器物理内存的2-5倍，如果服务器内存为16GB，那么warehouse设置建议在328～819之间。
2）terminals：
terminals指的是并发连接数，建议设置为服务器CPU总线程数的2-6倍。
如果服务器为双核16线程（单核8线程），那么建议配置在32～96之间。
配置文件详解：
1.db=mysql //数据库类型，postgres/oracle/mysql/firebird/goldilocks
2.driver=org.mariadb.jdbc.Driver //客户端驱动
conn=jdbc:mysql://...:3306/bmsdb //mysql数据库连接字符串
user=bms //数据库登录用户名，需要我们提前在数据库中建立benchmarksql用户
password=bms //如上用户密码
warehouses=20
loadWorkers=20
terminals=50
//To run specified transactions per terminal- runMins must equal zero
runTxnsPerTerminal=0
//To run for specified minutes- runTxnsPerTerminal must equal zero
runMins=5
//Number of total transactions per minute
limitTxnsPerMin=0
场景
描 述 benchmarksql测试
测试策略 1.创建配置文件
warehouse 设置为 10
loadWorkers=10
terminals=10
2.执行读写测试
./runBenchmark.sh props.pg
3、结果
参数值 warehouses=10
loadWorkers=10
terminals=10
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
场景
描述 benchmarksql测试
测试策略 1.创建配置文件
warehouse 设置为 20
loadWorkers=20
terminals=50
2.执行读写测试
./runBenchmark.sh props.pg
3、结果
参数值 warehouses=20
loadWorkers=20
terminals=50
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
场景
描述 benchmarksql测试
测试策略 1.创建配置文件
warehouse 设置为 10
loadWorkers=100
terminals=50
2.执行读写测试
./runBenchmark.sh props.pg
3、结果
参数值 warehouses=10
loadWorkers=100
terminals=50
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
场景
描述 benchmarksql测试
测试策略 1.创建配置文件
warehouse 设置为 10
loadWorkers=50
terminals=50
2.执行读写测试
./runBenchmark.sh props.pg
3、结果
参数值 warehouses=10
loadWorkers=50
terminals=50
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
4.3 稳定性测试
三个client节点，其中一个进行pgbench读写测试:
场景
描述 对数据库进行读写操作。
初始化数据 10 亿：pgbench -i -s 10000
测试策略 1. 创建读写脚本rw.sql
\set aid random_gaussian(1, :range, 10.0)
\set bid random(1, 1 * :scale)
\set tid random(1, 10 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;
UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP); END;
2.执行读写测试
总数据量 10 亿，热数据量随机选择1亿，5亿，10亿。反复执行
pgbench -M prepared -v -r -P 1 -f ./rw.sql -c 64 -j 64 -T 3600 -D scale=1000000 -D range=10000000
pgbench -M prepared -v -r -P 1 -f ./rw.sql -c 64 -j 64 -T 3600 -D scale=1000000 -D range=500000000
pgbench -M prepared -v -r -P 1 -f ./rw.sql -c 64 -j 64 -T 3600 -D scale=1000000 -D range=1000000000
参数值 -c ：客户端并发数64
-j : 线程数 64
-T ： benchmark测试时间 3600s
scale： 测试数据量 ×10万
range : 活跃数据量
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
另外一个进行只读测试：
场景
描述 对数据库进行只读操作。
初始化数据 10 亿：pgbench -i -s 10000
测试策略 1. 创建只读脚本ro.sql
\set aid random_gaussian(1, :range, 10.0)
SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
2.执行只读测试
总数据量 10 亿，热数据 1 亿
pgbench -M prepared -v -r -P 1 -f ./ro.sql -c 32 -j 32 -T 120 -D scale=10000 -D range=1000000
总数据量 10 亿，热数据 5 亿
pgbench -M prepared -n -r -P 1 -f ./ro.sql -c 32 -j 32 -T 120 -D scale=10000 -D range=5000000
总数据量 10 亿，热数据 10 亿
pgbench -M prepared -n -r -P 1 -f ./ro.sql -c 32 -j 32 -T 120 -D scale=10000 -D range=10000000
参数值 -c ：客户端并发数32
-j : 线程数 32
-T ： benchmark测试时间 120s
scale： 测试数据量 ×10万
range : 活跃数据量
备注 为保证测试数据的可靠性。每个场景测试至少执行2轮。
4.4 异常测试
稳定性测试方法的同时，进行如下异常测试：
| 用例名称 | 预期结果 | 测试结果 |
|---|---|---|
| 关闭任一chunkserver | io短暂卡顿 | 无影响 |
| 启动任一chunkserver | 无影响 | 无影响 |
| 重启任一chunkserver | io短暂卡顿 | 无影响 |
| 关闭任一节点所有chunkserver | io短暂卡顿 | 短暂掉0 |
| 启动任一节点所有chunkserver | 无影响 | 无影响 |
| 重启任一节点所有chunkserver | io短暂卡顿 | 短暂掉0 |
| 关闭mds | 影响管理面功能，io无影响 | 无影响 |
| 启动mds | 无影响 | 无影响 |
| 重启mds | 短暂影响管理面功能，io无影响 | 无影响 |
| 2个节点各关闭1个chunkserver服务 | 部分io持续hang | 可恢复 |
| 2个节点各启动1个chunkserver服务 | io恢复 | 可恢复 |
| 2个节点各重启1个chunkserver服务 | 部分io持续hang ，然后恢复 | 短暂掉0 |
| chunkserver进程hang等服务异常 | io短暂卡顿 | 无影响 |
| mds进程hang等服务异常 | 管理面受影响，io无影响 | 无影响 |
| 机器宕机，整机设置pendding | 目前可能会有30秒到2分钟的卡顿，需要优化 | 性能下降 |
| 所有mds进程异常重启 | 恢复后可正常挂卸载，io恢复 | 恢复后io正常 |
| 所有etcd进程异常重启 | 恢复后可正常挂卸载，io恢复 | 恢复后io正常 |
| 一个mds节点宕机 | 可正常挂卸载，无io卡顿 | 无影响 |
| 一个etcd节点宕机 | 可正常挂卸载，无io卡顿 | 无影响 |
| killall chunkserver，快速启动所有chunkserver模拟演练升级 | killall chunkserver后挂卸载异常、io阻塞；chunkserver恢复后能快速恢复 | 正常恢复 |
| pendding迁移中触发pfs一次全表扫描 | 扫描正常 | 扫描正常 |