Skip to content

昆仑数据库MySQL 分支的性能对比

Jump to bottom
kunlundb edited this page Oct 13, 2021 · 1 revision

资源下载都可在本公司官网完成

前段时间我对Kunlun-percona-mysql-8.0.18-9做了诸多改进，填补了mysql-8.0.18的所有已知的XA事务容灾方面的空白和不足。

同时还对多个子系统和功能模块做了广泛的性能优化，包括对mysql server模块的性能改进，以及对innodb存储引擎的性能改进。

这些改进，预期可以降低事务提交延时，并降低事务日志写入的开销。所有的改动都通过了mysql已有的mtr测试集以及我新增的诸多mtr测试。今天，Kunlun-percona-mysql-8.0.18-9正式发布了，下载地址见附录。

最近我对比测试了Kunlun-percona-mysql-8.0.18-9（下文简称Kunlun-percona），percona-mysql-8.0.18-9（下文简称Percona）和mysql-8.0.20（下文简称mysql）的性能。

现在展示一下结果

一句话结论：对Kunlun-percona的性能改进有很明显的大幅提升，达到了预期的效果。 Kunlun-percona的性能大幅优于Percona，小幅优于mysql；并且Kunlun-percona的事务日志（binlog，innodb redo log）资源开销大幅低于Percona，中幅低于mysql。未来把Kunlun-percona的优化改动合并到mysql-8.0.2x后，很可能可以获得比当前Kunlun-percona-mysql-8.0.18-9更好的性能，并大幅提高对应的mysql-8.0.2x的性能。另外，percona-mysql-8.0.18-9的性能较差是由mysql-8.0.18自身的性能问题造成的，并不是percona 影响了mysql的性能。

DB实例配置和测试配置

所有结果都可重现，附录提供的sysbench-xa下载中，有sysbench驱动脚本（perftest.sh)和数据加载脚本parallel_load.sh，方便用户快速做相同的性能测试。

安装好DB实例后，对每个实例手动执行以下语句来创建测试所需的db和用户：

  1. set global super_read_only=false;

  2. create database test;

  3. create user abc identified by ‘abc’; grant all on . to ‘abc’@’%’;

然后运行parallel_load.sh脚本，然后运行perftest.sh脚本即可。

如果你要修改插入测试表的数据量，确保所有测例使用相同的数据量，并且确保innodb buffer pool不要过于小，小于总数据空间的10%的实际参考意义不大。

这3个mysql分支由完全相同的cmake配置参数build而成，并且使用相同的DB实例配置文件。在Kunlun-percona的文档INSTALL.Kunlun中，有cmake配置参数命令，有兴趣的读者可以使用这个cmake命令来构建mysql-8.0.20和percona-mysql-8.0.18-9 可执行程序，然后把Kunlun-percona/install 目录copy到mysql-8.0.20和percona-mysql-8.0.18-9 的可执行程序目录，然后用里面提供的DB配置模版文件和安装脚本安装DB实例，并根据下文的测试配置信息自行测试对比一下三者的性能。 如果你在性能强劲的服务器上面（比如有40个以上逻辑核CPU的服务器上面）做了我这里描述的性能对比，我鼓励大家把性能测试结果发布出来。

之所以使用mysql-8.0.20是因为根据mysql官方团队的介绍，mysql-8.0.20的性能比之前的mysql-8.0版本有较明显提升，不过从实际结果来看在分布式事务处理方面的性能mysql-8.0.20仍然明显不及Kunlun-percona。

针对上述3种mysql分支的测试软硬件配置完全相同，db实例的配置参数完全相同，sysbench的测试参数也完全相同。文末附录提供了我使用的sysbench程序和脚本下载地址，方便读者快速做性能对比。

sysbench测试程序运行在一台单独的普通配置的计算机S1中，使用另一台性能较好的笔记本S2运行一个db实例，两者用千兆网连接。全部测试过程中，S1的资源未遇到瓶颈。

由于测试硬件只是笔记本电脑，所以测试结果的延时和TPS绝对值会比生产环境的服务器上面跑出来的结果慢一些，参考意义不大；但是不同mysql分支之间相同测例和相同指标的性能数据的差值有很大参考意义。如果在性能强劲的服务器中，可以预期3种mysql分支产品的性能数据会成比例提升，于是他们之间的性能差距也就会更加明显。同时，资源开销（utility）也有很大的参考意义，因为这反映了3个分支的资源使用效率，即使在性能强劲的服务器上面也会表现出相同的资源使用效率。

数据库服务器的硬件资源

CPU：Intel 第十代core i7 （8个逻辑核，8MB L3 cache）

内存：16GB DDR4 2666 MHz

日志存储：Intel optane 持久内存来存储binlog和innodb redo log，以便最快地刷盘。

数据存储：pci-e SSD 来存储innodb tablespace数据文件

sysbench配置

数据量：共20个表，每个200万行，总的数据量大约8GB（202M0.2KB）

总连接数：500

实际测试过程中，对所有测例还使用了1000个连接测试了一轮。1000个连接时相同的测例对于Kunlun-percona和percona， TPS没有明显升降，但是延时普遍增大了；但是mysql由于没有线程池，所有测例TPS都出现了10%以上的下降并且延时大幅增加。显然1000个连接的测试已经大大超过了硬件资源的负载能力，故此处不再展示。因此只展示500个连接的性能数据。

测例说明

每个oltp.lua或者oltp-xa.lua测例的事务中有14个select语句，其中10个单行select点查询，4个使用主键索引的范围查询；还包括4条数据写语句：1个1个单行update语句更新 索引字段，1个单行update语句更新非索引字段，1个单行插入语句，1个单行删除语句。update和delete语句都是用主键定位唯一的目标行。

Oltp-xa.lua与oltp.lua的唯一区别在于oltp-xa使用xa start启动事务，使用两阶段提交（也就是xa prepare和xa commit）来提交事务。由于两个阶段都要刷盘，所以事务提交的开销大约是普通事务提交开销的2倍。这两个测例的其余SQL语句完全相同。

下文中的oltp-xa/oltp read&write就是运行全部14个select语句和4个写语句；这组测例可以全面测试3个mysql分支的数据读写和事务提交性能；oltp-xa/oltp write only就是不运行这14个select语句，只运行4个写语句，侧重测试写入性能和事务提交性能。

类似的，update_non_index_xa.lua与update_non_index.lua的唯一区别是前者总是使用xa prepare/xa commit做两阶段提交。这两个测例中，每个事务都只执行一个单行非索引字段更新，并且使用主键找目标行。由于事务的DML语句开销很小，这两个测例可以最大程度地凸显普通1阶段事务提交与分布式事务两阶段提交的开销的性能和资源消耗的区别。

在所有测例全部测试中，都启用了binlog并且sync_binlog=1。并且所有测例中innodb_flush_trx_at_commit=1。另外，所有测例都使用了group replication并且都没有备机，因为我没有在这方面做性能改进。如果加上备机以后预期事务提交延时会进一步增大若干个毫秒，并且XA事务增加的毫秒数会比非XA事务多一倍，因为XA事务两个阶段都需要等待备机确认收到了事务binlog。在生产机房万兆网和性能强劲的服务器的环境下，group replication导致事务提交增加的毫秒数会非常有限，预期在10毫秒以内。

sysbench的统计不认识两阶段提交事务的提交语句，因此所有的XA测例的TPS会报0。不过由于每个测例的事务中，read/write语句的数目是固定的，于是用QPS除以每个事务的read/write语句数目 就可以从QPS得到TPS，因此下文结果表格中只列出QPS，也就是sysbench报告中的read/write requests这一行的形如 (xxxx.yy per sec.) 的数值。

下面每个测例的结果表格中的‘资源开销(c/d/l)’ 列的数值是用dstat获得的----在测试运行期间运行dstat获取cpu/磁盘的utility，然后粗略计算（眼睛扫一遍然后估算）每个测例运行期间的大约平均的资源开销（utility）。c代表cpu 的开销（utility），是用1-idle 得到的，d代表数据盘的开销（utility），l代表日志盘的开销。Cpu idle和磁盘utility都是dstat的输出列。 资源开销反映了数据库系统的运行效率，它就像汽车的在一定巡航速度下的百公里油耗一样。达到同样的性能的情况下，资源开销越低越好；同样的资源开销情况下，性能越高越好。为了方便将sysbench的结果与dstat的结果对应起来，建议每个sysbench开始之前执行一个date shell命令，用启动时间将两边的结果对应起来，我就是这么做的。

4个延迟指标列都取自sysbench输出结果。所有延迟指标都是越低越好；最大延迟与最小延迟以及平均延迟的差值越低越好，这个差值如果波动很大意味着系统性能不稳定，用户会觉得系统时快时慢，甚至对应用系统的设计也会带来挑战。

测试结果

测试跑了两轮，每个测例两次的结果非常接近。Mysql-8.0.20的oltp-xa write only测例发生了XA事务状态错误，很可能是因为Mysql-8.0.20的XA事务的bug，导致这个测例以及其后的update_non_index测例都没有第二轮结果。

Update_non_index

Update_non_index_xa

Oltp write only

Oltp_xa write only

Oltp read&write

Oltp_xa read&write

测试结果分析

  1. 非XA测例，Kunlun-percona与mysql性能相差无几，但是写入性能二者都比Percona的QPS高10%到16%。

  2. XA测例，Kunlun-percona比mysql的QPS高约11%～15%；事务提交的平均延时和95%延时方面，Kunlun-percona比mysql低约20%；Kunlun-percona比Percona的QPS高50%以上，事务提交的平均延时和95%延时比Percona低50%到66%。所以Kunlun-percona的分布式事务处理性能具有明显优势。如果我对Kunlun-percona的性能改进与mysql-8.0.20的改进不重合的话，很可能未来如果将Kunlun-percona的改动合并到mysql-8.0.2x后可以获得更进一步的性能提升。

  3. 所有测例的最大延时，Kunlun-percona与percona相差不多，而mysql要显著大很多。这主要是因为mysql没有线程池，500个连接对应了500个活跃线程，所以最坏情况下的线程调度的耗时就比较大了。而Kunlun-percona与percona使用线程池，服务500个连接的最多也就几十个线程，线程调度更快开销小很多。最大延时是一个波动范围比较大的指标，只有非常显著的区别才有参考意义。另外，由于测试期间需要定期删除binlog来释放空间导致最大延时进一步变大，因此参考意义不大，未显示在结果表格中。

  4. XA只写测例中Kunlun-percona延时明显比percona和mysql要短很多。percona的平均延时和95%延时比Kunlun-percona高约50%，mysql的平均延时和95%延时比Kunlun-percona高约20%。非XA测试，三者的平均延时和95%延时很接近。

  5. Percona的log 开销明显太大，这也是预期中的----做所有纯写入的测例中都用尽了log盘的带宽，导致log盘成为性能瓶颈。Kunlun-percona与mysql的log开销相差不大，但是mysql log在XA测例的开销比Kunlun-percona略大，说明XA相关的功能，mysql的效率还是偏低，这也是在预期中的。另外，mysql的数据盘开销比Kunlun-percona大。

  6. 数据盘的开销方面，两次测试偏差比较大，这是因为innodb后台线程刷脏页具有较大的随机性。

附录

cmake配置参数和DB实例安装

把Kunlun-percona-8.0.18-bin-rel.tgz 解压缩后，得到percona-8.0.18-bin-rel目录。在percona-8.0.18-bin-rel/INSTALL.Kunlun文件中，就可以找到‘CMake configuration' 这一节。本测试所有3个分支都使用这个配置产生build所需的文件的。这个配置是面向性能最优的。如果要做性能对比测试请务必使用这个cmake命令。

另外，可以使用percona-8.0.18-bin-rel/install 目录中的脚本和模版文件来快速安装mysql-8.0.x以及percona-mysql-8.0.x 的DB实例。具体方法就是把这个install目录copy到percona或者mysql的安装目录里面，然后阅读percona-8.0.18-bin-rel/INSTALL.Kunlun文件的‘Instance Installation’这一节来使用install/install-mysql.py和配置模版文件快速安装DB实例。

配置文件模版中的mysql参数设定是面向最优性能的并且假设了高并发和足够的资源的情况，不建议读者手动修改其中的任何配置。

Sysbench-xa下载地址和md5sum

由于我增加了几个xa测例并且新增加了一些sysbench db性能测试的配置参数，为了方便读者做同样的对比性能测试，我把我使用的sysbench也放到了这里。另外，我把pg的客户端支持也build到这个sysbench中了，因为我自己会用它测试昆仑数据库的计算节点的性能。或许这对很多读者也有用。

Clone this wiki locally