Meelo
作者Meelo2021-12-29 12:08
系统工程师, 浪潮商用机器有限公司

MySQL on OpenPower + Docker

字数 4251阅读 1054评论 0赞 1

测试背景和目的

验证 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 。

Sysbench fileio 测试

宿主机 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

fileio 测试小结

从上述结果可以看出:

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 ,测试了两组结果。

事物隔离级别( READ-COMMITTED )

transaction_isolation=READ-COMMITTED 。

宿主机 oltp 测试结果

1 个 Docker oltp 测试结果

8 个 Dockers oltp 测试结果

事物隔离级别(默认值 REPEATABLE-READ )

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 的性能结果:

  1. X86 测试时 事务隔离级别为 READ-COMMITTED ,在高并发情况下, MySQL 数据库内部 Mutex , spin_lock 争抢较为严重, TPS 比 默认事务隔离级别 REPEATABLE-READ 低。
  2. 受限于测试工具 Sysbench , OpenPower 上的 CPU 使用率并不能压满。

所以我们测试了两种事务隔离级别的情况,如上表所示,默认事务隔离级别的 TPS 性能更好。

  1. 在同样事务隔离级别为 READ-COMMITTED 时, 1 个 Docker 情况下 OpenPower 的 TPS 是 X86 的 1.3 倍, OpenPower 8 个 Docker 的 TPS 是 X86 5 个 Docker 的 2.1 倍。
  2. OpenPower 在默认事务隔离级别 REPEATABLE-READ 时, 1 个 Docker 情况下 TPS 是事务隔离级别为 READ-COMMITTED 的 1.4 倍, 8 个 Docker 情况下 TPS 是事务隔离级别为 READ-COMMITTED 的 1.1 倍。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

1

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广