验证 MySQL 在 OpenPower 服务器上的性能指标,以及用容器方式部署的可行性和性能指标。
TPS (每秒事务处理量 (TransactionPerSecond) )
一个表达系统处理能力的性能指标,每秒处理的消息数( Transaction Per Second ),每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。
两台 Inspur Power FP5280G2 服务器( OpenPower )
l 2个CPU , 2路22 核, 2.7GHz
l 512GB 内存
l 双口 10Gb 网卡
l SSD ,做成 raid10
l SUSE Linux Enterprise Server 12 SP4 (ppc64le)
l Kernel 4.12.14-95.6.1.16904.0
l Docker version 18.06.3-ce, build d7080c1
l MySQL 5.7.25
l sysbench v1.1
l 开源 sysbench v1.1 fileio
l 开源 sysbench v1.1 olt_read_write
依据X86 环境下所提供脚本,测试方法如下:
l fileio: 20 个文件,共 40GB ,读写比例 1.5 ,测试 16K 的 rndrw 随机读写 IO 。记录 IO 的 IOPS 和带宽
file_num=20
file_totalsize=40G
rw_ratio=1.5
file-block-size
fileio_mode="rndrw"
l olt_read_write :准备 30 个 2 千万记录的 testdb_30_2000w 数据库,按不同线程数并发( 8,16,32,64,96,128,176,256,512 )压测。记录 TPS 、 IO 平均响应时间、系统 CPU ,内存使用率, IOPS 指标,磁盘繁忙程度指标
sbtest_db=testdb_30_2000w
sbtest_tables=30
sbtest_tablesize=20000000
SSD 做成 raid10, 划分文件系统 /db ,容量 2.7TB ,准备 8 个 Docker 的数据库,每个数据库数据和日志合计约 200GB 。
宿主机 fileio 测试
1 个 Docker fileio 测试
8 个 Dockers fileio 测试
sles12u4:/db # for i in 1 2 3 4 5 6 7 8
do
tail -12 fileio${i}/sysbench_fileio_run_8_${i}.out | egrep "Throughput|read|write|Latency|avg"
done
Throughput:
read: IOPS=3492.51 54.57 MiB/s (57.22 MB/s)
write: IOPS=2328.31 36.38 MiB/s (38.15 MB/s)
Latency (ms):
avg: 10.99
Throughput:
read: IOPS=3474.14 54.28 MiB/s (56.92 MB/s)
write: IOPS=2316.11 36.19 MiB/s (37.95 MB/s)
Latency (ms):
avg: 11.05
Throughput:
read: IOPS=3481.78 54.40 MiB/s (57.05 MB/s)
write: IOPS=2321.21 36.27 MiB/s (38.03 MB/s)
Latency (ms):
avg: 11.03
Throughput:
read: IOPS=3481.06 54.39 MiB/s (57.03 MB/s)
write: IOPS=2320.70 36.26 MiB/s (38.02 MB/s)
Latency (ms):
avg: 11.03
Throughput:
read: IOPS=3501.06 54.70 MiB/s (57.36 MB/s)
write: IOPS=2334.07 36.47 MiB/s (38.24 MB/s)
Latency (ms):
avg: 10.97
Throughput:
read: IOPS=3511.53 54.87 MiB/s (57.53 MB/s)
write: IOPS=2341.00 36.58 MiB/s (38.35 MB/s)
Latency (ms):
avg: 10.93
Throughput:
read: IOPS=3531.98 55.19 MiB/s (57.87 MB/s)
write: IOPS=2354.66 36.79 MiB/s (38.58 MB/s)
Latency (ms):
avg: 10.87
Throughput:
read: IOPS=3564.27 55.69 MiB/s (58.40 MB/s)
write: IOPS=2376.17 37.13 MiB/s (38.93 MB/s)
Latency (ms):
avg: 10.77
l 宿主机、 1 个 Docker 、 8 个 Dockers 上 fileio 测试 IOPS 差不多。
l 8 个 Dockers 的 Latency(ms) 延迟相对较大,是因为并发线程数较多。
Sysbench oltp_read_write 测试
依据 X86 环境测试提供的脚本,事物隔离级别设定的是: transaction_isolation=READ-COMMITTED 。
经测试发现,设定 transaction_isolation=READ-COMMITTED 时,在宿主机或者 1 个 Docker 容器进行里测试时,在 FP5280G2 这种 CPU 高配置机器上,如果并发数太多 (>=256) , MySQL 数据库内部 Mutex , spin_lock 争抢较为严重,附 512 线程时 perf top 截图如下:
在这种情况下,虽然 CPU 负载仍然较低,但增加并发线程并不能带来更高的 TPS 。
如果保持事物隔离级别为 MySQL 默认值 transaction_isolation= REPEATABLE-READ, 这种情况能有所缓解,在宿主机或者 1 个 Docker 容器进行里测试时,相应的 TPS 会更高。
因此我们本次分别设置 transaction_isolation 为客户设定值 READ-COMMITTED 和 默认值 REPEATABLE-READ ,测试了两组结果。
transaction_isolation=READ-COMMITTED 。
宿主机 oltp 测试结果
1 个 Docker oltp 测试结果
8 个 Dockers oltp 测试结果
transaction_isolation 设为默认值 REPEATABLE-READ
宿主机 oltp 测试结果
1 个 Docker oltp 测试结果
8 个 Dockers oltp 测试结果
Sysbench oltp_read_write 测试小结
从上述结果可以看出:
l SSD 做成 RAID10 , IO 处理能力有限,还有压测工具 sysbench 软件并发能力限制,不能压满 CPU ;
l 对于单个 MySQL 数据库,不论运行在宿主机中或者 1 个 Docker 中, TPS 差不多
l 事务隔离级别 READ-COMMITTED 在高并发情况下, MySQL 数据库内部 Mutex , spin_lock 争抢较为严重, TPS 比 默认事务隔离级别 REPEATABLE-READ 低
l 运行 8 个 Docker 时, 512GB 内存, 8 个 Docker MySQL 数据库每个 MySQL 数据库仅仅能分到几十 GB , Buffer 不足,因此默认事务隔离级别 REPEATABLE-READ 的 TPS 比单个 Docker 时的 TPS 低一些;而对于事务隔离级别 READ-COMMITTED , 8 个 Docker MySQL 数据库能分散并发压力,所以 TPS 比单个 Docker 时的 TPS 更高一些
Fileio 场景
X86 的 fileio 场景测试结果:
OpenPower 的 fileio 场景测试结果:
总结: fileio 主要由磁盘性能决定,所以 X86 和 OpenPower 平台下的性能差异并不大。
OLTP 场景
X86 的 OLTP 场景测试结果:
OpenPower 的 OLTP 场景测试结果:
总结: OLTP 场景时,有两个方面可能限制了 OpenPower 的性能结果:
所以我们测试了两种事务隔离级别的情况,如上表所示,默认事务隔离级别的 TPS 性能更好。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞1
添加新评论0 条评论