Skip to main content
 Web开发网 » 数据库教程

Percona Server MySQL 5.7新引擎MyRocks性能基准测试

2021年08月11日7200百度已收录

本文中,我们将通过基准测试来给大家展示MyRocks引擎的性能。

Percona Server MySQL 5.7新引入的一个数据库引擎。关于他性能可能还是还待探索,所以今天我们就一起来看看它在相对高端的服务器和SSD存储下的性能表现。

我们想要检查它对于给定的数据库不同大小的可用内存情况表现。它与之前Percona官方发布的InnoDB基准测试相同的条件下,我们使用sysbench-tpcc基准测试,用InnoDB作为基准,然后用其对MyRocks和InnoDB两种引擎进行对比测试。

作为基准测试,我将使用100个TPC-C仓库,以及一组10个表格(从行递增调整瓶颈)。这应该提供大约90GB的数据大小(加载到InnoDB时),大致相当于1000个数据仓库的数据量。

为了改变内存大小,我们将InnoDB的innodb_buffer_pool_size从5GB更改为100GB,MyRocks的 rocksdb_block_cache_size也做同样修改。

对于MyRocks,我们将使用LZ4作为存盘的默认压缩。 MyRocks存储引擎中的数据大小为21GB。需要注意的是是,在MyRocks中未压缩的数据存储上限70GB。

这两种引擎,均未使用FOREIGN KEYS,因为MyRocks目前还不支持。

MyRocks不支持Percona Server中实现的REPEATABLE-READ模式中的"SELECT .. FOR UPDATE"语句。但是,在此基准测试中使用了"SELECT .. FOR UPDATE"。必须使用READ-COMMITTED模式。

还要提及的最重要的设置是启用二进制日志,原因如下:

1、任何重要的生产系统都都会启用二进制日志

2、如果禁用的二进制日志,MyRocks会受到的非最优事务协调器的影响

我们对二进制日志使用了以下设置:

binlog_format ='ROW'

binlog_row_image = minimal

sync_binlog = 10000(我没有使用0,因为这会在二进制日志转存到硬盘时候时候导致严重的卡顿)

虽然我并不是MyRocks调优的完整专家,但我使用了此页面的调优建议:github上 /facebook/mysql-5.6/wiki/my.cnf-tuning。同时Facebook-MyRocks工程团队还为我们提供了关于MyRocks最佳设置配置。

结果展示内存性能让我们回顾一下不同内存大小的结果。

这第一张图显示吞吐量抖动。这有助于了解吞吐量结果的分布情况。吞吐量每1秒测量一次,图表上显示运行2000秒后的所有测量结果(每次运行的总长度为3600秒)。所以我们展示了每次运行的最后1600秒(去除准备热身阶段):

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第1张

为了更好地量化结果,让我们对比看boxplot图。理解箱型图的最快方法是看中间线。它代表测量的中位数。

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第2张

内存吞吐变化在我们给出结果总结之前,让我们来看看InnoDB和MyRocks的吞吐量变化。我们100GB内存分配的结果将放大到的1秒分辨率图表:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第3张

我们可以看到,MyRocks在定期1秒性能下降中变化很大。目前,我们还不知道导致吞吐量变化的原因。

因此,让我们来看看不同内存设置下每个引擎的平均吞吐量(结果以tps为单位,而且越多越好):

Memory, GB

InnoDB

MyRocks

5

849.0664

4205.714

10

1321.9

4298.217

20

1808.236

4333.424

30

2275.403

4394.413

40

2968.101

4459.578

50

3867.625

4503.215

60

4756.551

4571.163

70

5527.853

4576.867

80

5984.642

4616.538

90

5949.249

4620.87

100

5961.2

4599.143

这是MyRocks与InnoDB行为不同的地方。 InnoDB从额外的内存中受益良多,直到增加到工作数据集的大小。之后,内存增加被限制。

于此对比,有趣的是MyRocks并没有从额外的内存中获益。

基本上,MyRocks按预期执行写优化引擎。有关更多详细信息,请参阅我的文章"三种基本数据结构如何影响存储和检索"。

总之,当工作数据集适合(或几乎适合)可用内存时,InnoDB的性能会更好(与其本身相比),而MyRocks可以在小内存上运行(并且胜过InnoDB)。

IO和CPU使用率值得关注的是每个引擎的资源利用率。我们对每次运行都进行了vmstat测量,以便分析IO和CPU使用情况。

写性能首先,让我们回顾一下每秒写入的数量(以KB/秒为单位)。注意,这些写操作也包括二进制日志写入,而不仅仅是存储引擎写入。

Memory, GB

InnoDB

MyRocks

5

244754.4

87401.54

10

290602.5

89874.55

20

311726

93387.05

30

313851.7

93429.92

40

316890.6

94044.94

50

318404.5

96602.42

60

276341.5

94898.08

70

217726.9

97015.82

80

184805.3

96231.51

90

187185.1

96193.6

100

184867.5

97998.26

我们还计算了各存储引擎每次执行的写入次数:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第4张

上面的图显示了InnoDB和MyRocks之间的本质区别。 MyRocks是一个写优化的引擎,每个事务使用的写入量不变。

相比较InnoDB,写入的数量很大程度上取决于内存大小。我们拥有的内存越少,它需要执行的写入就越多。

读性能下表显示了以每秒KB为单位的读取。

Memory, GB

InnoDB

MyRocks

5

218343.1

171957.77

10

171634.7

146229.82

20

148395.3

125007.81

30

146829.1

110106.87

40

144707

97887.6

50

132858.1

87035.38

60

98371.2

77562.45

70

42532.15

71830.09

80

3479.852

66702.02

90

3811.371

64240.41

100

1998.137

62894.54

我们可以将其转换为每个事务的读取次数:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第5张

这张图显示了MyRocks的读取放大。分配更多内存有助于减少IO读取,但不如InnoDB那么明显。

CPU使用率让我们在看看两个存储引擎的CPU使用情况。先是InnoDB:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第6张

该图表显示,对于5GB内存大小,InnoDB大部分时间用于IO等待(绿色区域),并且CPU使用率(蓝色区域)随着更多内存的增加而增加。

做为对比MyRocks的情况:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第7张

其详细表格数据如下:

Memory, GB

engine

us

sys

wa

id

5

InnoDB

8

2

57

33

5

MyRocks

56

11

18

15

10

InnoDB

12

3

57

28

10

MyRocks

57

11

18

13

20

InnoDB

16

4

55

25

20

MyRocks

58

11

19

11

30

InnoDB

20

5

50

25

30

MyRocks

59

11

19

10

40

InnoDB

26

7

44

24

40

MyRocks

60

11

20

9

50

InnoDB

35

8

38

19

50

MyRocks

60

11

21

7

60

InnoDB

43

10

36

10

60

MyRocks

61

11

22

6

70

InnoDB

51

12

34

4

70

MyRocks

61

11

23

5

80

InnoDB

55

12

31

1

80

MyRocks

61

11

23

5

90

InnoDB

55

12

32

1

90

MyRocks

61

11

23

4

100

InnoDB

55

12

32

1

100

MyRocks

61

11

24

4

我们可以看到无论分配了多少内存,MyRocks都使用了很多CPU(用户+系统态)。这导致MyRocks性能受限于CPU性能而非可用内存的限制。

MyRocks目录大小随着MyRocks写入所有更改并压缩成SST文件,可以看到基准测试期间数据目录大小如何变化,以便我们估算存储需求。下面是数据目录大小的图表:

Percona Server MySQL 5.7新引擎MyRocks性能基准测试  基准 性能 MyRocks 引擎 第8张

我们可以看到,数据目录从开始时的20GB变为基准期间的31GB。观察数据增长直到压缩,然后缩小呈现周期性的规律变化。

结论总之,我可以说MyRocks性能随着数据集大小与内存的比例增加而增加,在5GB内存分配的情况下,性能比InnoDB高出近5倍。吞吐量变化是值得关注的问题,但我们希望这一点在未来得到改善。

MyRocks不需要大量内存,并且在使用大部分CPU资源时显示稳定地写入IO。

我们认为这特性可能会使MyRocks成为云数据库实例的绝佳选择,而内存和IO都消费都会比较合算。 MyRocks部署可以让云部署更便宜。

我们将跟进更多基于云计算的基准测试。

附件原始结果,脚本和测试配置我的目标是提供完全可重复的基准测试。为此,我们在GitHub分享相关信息包括我们使用的所有脚本和设置:

Github链接:Percona-Lab-results/201803-sysbench-tpcc-myrocks

MyRocks设置rocksdb_max_open_files=-1

rocksdb_max_background_jobs=8

rocksdb_max_total_wal_size=4G

rocksdb_block_size=16384

rocksdb_table_cache_numshardbits=6

# rate limiter

rocksdb_bytes_per_sync=16777216

rocksdb_wal_bytes_per_sync=4194304

rocksdb_compaction_sequential_deletes_count_sd=1

rocksdb_compaction_sequential_deletes=199999

rocksdb_compaction_sequential_deletes_window=200000

rocksdb_default_cf_options="write_buffer_size=256m;target_file_size_base=32m;max_bytes_for_level_base=512m;max_write_buffer_number=4;level0_file_num_compaction_trigger=4;level0_slowdown_writes_trigger=20;level0_stop_writes_trigger=30;max_write_buffer_number=4;block_based_table_factory={cache_index_and_filter_blocks=1;filter_policy=bloomfilter:10:false;whole_key_filtering=0};level_compaction_dynamic_level_bytes=true;optimize_filters_for_hits=true;memtable_prefix_bloom_size_ratio=0.05;prefix_extractor=capped:12;compaction_pri=kMinOverlappingRatio;compression=kLZ4Compression;bottommost_compression=kLZ4Compression;compression_opts=-14:4:0"

rocksdb_max_subcompactions=4

rocksdb_compaction_readahead_size=16m

rocksdb_use_direct_reads=ON

rocksdb_use_direct_io_for_flush_and_compaction=ON

InnoDB设置# files

innodb_file_per_table

innodb_log_file_size=15G

innodb_log_files_in_group=2

innodb_open_files=4000

# buffers

innodb_buffer_pool_size= 200G

innodb_buffer_pool_instances=8

innodb_log_buffer_size=64M

# tune

innodb_doublewrite= 1

innodb_support_xa=0

innodb_thread_concurrency=0

innodb_flush_log_at_trx_commit= 1

innodb_flush_method=O_DIRECT_NO_FSYNC

innodb_max_dirty_pages_pct=90

innodb_max_dirty_pages_pct_lwm=10

innodb_lru_scan_depth=1024

innodb_page_cleaners=4

join_buffer_size=256K

sort_buffer_size=256K

innodb_use_native_aio=1

innodb_stats_persistent = 1

#innodb_spin_wait_delay=96

# perf special

innodb_adaptive_flushing = 1

innodb_flush_neighbors = 0

innodb_read_io_threads = 4

innodb_write_io_threads = 2

innodb_io_capacity=2000

innodb_io_capacity_max=4000

innodb_purge_threads=4

硬件和系统配置列表

超微服务器:

CPU:

Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz

2 sockets / 28 cores / 56 threads

内存: 256GB of RAM

硬盘: 三星 SM863 1.9TB Enterprise SSD

文件系统: ext4

数据库:Percona-Server-5.7.21-20

操作系统: Ubuntu 16.04.4, linux内核 4.13.0-36-generic

本文虫虫译自percona官方博客,作者是percona联合创始人Vadim Tkachenko和CTO。(原文链接见percona最新blog,此处略)。

评论列表暂无评论
发表评论
微信