MySQL中ScaleFlux性能报告 总结多线程synchronized

2020-08-19 13:53:23

最近作者有一个针对 ScaleFlux 的产品也叫做 CSD 2000 进行压测的机会。本文中作者将介绍使用 Intel SSD 和 ScaleFlux 存储设备进行压测的对比结果。

一、我们为什么需要不一样的 ScaleFlux?

答案很简单,它为我们提供了内置的压缩功能和支持原子写特性。对于很多工作场景尤其是数据库类型的业务而言,这些功能和特性非常重要。

因为内置的磁盘压缩功能相同的磁盘容量,我们可以存储更多的数据在 ScaleFlux 存储设备上。(引申:大规模数据存储的情况下,耗费的机器数量更少,机架位也更少。)

作者基于不同的数据集大小,不同数据库 schema 数据量进行多次测试。需要说明的是在这些测试场景中我并不打算压测这些卡的性能极限,而是对比相同容量下 ScaleFlux 存储设备 和 Intel SSD 的性能表现。

存储设备配置: ScaleFlux – CSD 2000 4TB Intel – P4610 3.2TB 服务器配置: Application server: Supermicro; SYS-6019U-TN4RT 48xIntel(R) Xeon(R) Gold 6126 CPU @ 2.60GHz 190G RAM Database Server: Inspur; SA5212M4 32xIntel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz 64G RAM

在 Application server 运行 sysbench 压测工具,在 Database Server 运行 Percona Server for MySQL 8.0.19 。

作者禁用了 binary, slow query logging 和 adaptive hash,使用比较小的 BPS 配置,为了减少数据缓存,尽量让 sql 请求访问磁盘。另外就是测试了关闭和开启 doublewrite 的性能表现。

数据库的配置如下:

innodb_buffer_pool_size=8G innodb_log_file_size = 2G max_connections=500 slow_query_log=off disable_log_bin innodb_doublewrite=ON/OFF tmpdir = /var/lib/mysql/ innodb_adaptive_hash_index=off innodb_flush_method=O_DIRECT innodb_purge_threads=32 sync_binlog=0 max_prepared_stmt_count=4000000

做了哪些测试

首先作者做了标准的 OLTP read_only,write_only 和 read-write 测试,然后作者修改分表结构,

CREATE TABLE `sbtest1` ( `id` int NOT NULL AUTO_INCREMENT, `k` int NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', `data1` varchar(255) DEFAULT NULL, `data2` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`), KEY `k_1` (`k`), KEY `idx_data1` (`data1`) ) ENGINE=InnoDB AUTO_INCREMENT=9999948 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

新增加了 data1 和 data2 两个 varchar 字段,使用一本书(Gutenberg project)中的内容行记录进行填充。

为什么这样做?因为这也是 ScaleFlux 的优势之处,他们声称如果数据可以被压缩,那么 ScaleFluxIntel 的性能要好很多。

作者还修改了 OLTP lua 脚本来适配新的表结构,

index_updates = { "UPDATE %s%u SET k=?,data1=? WHERE id=?", t.INT,,t.INT}, non_index_updates = { "UPDATE %s%u SET c=?,data2=? WHERE id=?", ,,t.INT}, inserts = { "INSERT INTO %s%u (id, k, c, pad, data1, data2) VALUES (?, ?, ?, ?, ?, ?)", t.INT, t.INT, , , , }, index_selects = { "SELECT id,data2 FROM %s%u WHERE data1=?", }, update_based_on_data1 = { "UPDATE %s%u SET data2=? WHERE data1=?", ,},

压测的配置如下:

default lua scripts – 100 tables – 10ML rows each – 220G

default lua scripts – 1000 tables – 10ML rows – 2.3T

modified lua scripts – 100 tables – 10ML rows each – 440G

modified lua scripts – 540 tables – 10ML rows each – 2.5T

modified lua scripts – 540 tables – 20ML rows each – 4.7T

talk is cheap,我们来看看结果对比图吧。

Default Sysbench – Read/Write – 220G Datasize

在默认配置下,使用 100 张表,每个表 100w 条记录,数据集大小为 220G。从结果图中我们可以看到 Intel SSD 略微领先。ScaleFlux 存储设备在并发度为 96 之后有领先的优势。

需要说明都是 ScaleFlux 支持原子写,所以作者关闭了 InnoDB Double Write Buffer。而针对 Intel SSD 不支持原子写,InnoDB Double Write Buffer 是开启的。

Modified Sysbench – Read/Write – 440G Datasize

该场景下,作者使用了添加 2 个字段的压测模型。数据量扩大到 440G,而且使测试数据适合压缩。

从结果上看,和 ScaleFlux 声明的一样,在数据可压测的情况下,MySQL 在 ScaleFlux设备上的性能明显优于 Intel SSD,在高并发场景下,性能优势明显。

再次说明 Intel SSD 上的 MySQL 未关闭 InnoDB Double Write Buffer,而是用 ScaleFlux 设备的 MySQL 是关闭了 InnoDB Double Write Buffer 的。

我们来看一下 Intel SSD 的 MySQL 也关闭 InnoDB Double Write Buffer 的测试结果。

在同时开启或者关闭 Double Write 特性的对比测试中,使用 ScaleFlux 存储设备的 MySQL 都表现比较明显。

需要注意的是,我们不推荐在任何不支持原子写的设备上关闭 InnoDB Double Write。

Modified Sysbench – Read/Write – 2.5T Datasize

两个设备都有 3.2T 的存储容量,作者压测的数据使用了 2.5T。作者使用修改的表结构重建了 sysbench 的表。从结果上来看 ScaleFlux 存储设备上的 MySQL 性能优势比较明显。一个影响性能的因素是 SSD 存在写放大。当数据量达到一定容量比例,SSD 会进行类似垃圾回收的任务,耗费资源,影响 SSD 的写能力。

Disk Latency

从图中可以查看到 ScaleFlux 存储设备的响应时间非常稳定而 Intel 设备的响应时间则波动比较大。

CPU Usage

ScaleFlux – Read/Write – Modified Sysbench – 540 tables – 2.5T

Intel – Read/Write – Modified Sysbench – 540 tables – 2.5T

我们可以看到 Intel 设备的 iowait 比较高 31.52%,而 ScaleFlux 设备的 iowait 则是 11.46%,明显低于 Intel 设备。

Disk Operations

从系统层的监控数据来看测试期间的 IOPS 表现。ScaleFlux 存储设备提供更高的 IOPS 大约是 Intel 的 2 倍。更高的 IOPS 意味着 MySQL 的 QPS/TPS 更高,性能更好。下面的图也说明了这一点。

InnoDB Row Operations

从上面这张图中我们看到 Innodb 层的统计数据,每分钟 inserted/updated/deleted 多少行记录。

因为 InnoDB 关闭了 double write,使用 ScaleFlux 存储设备的 MySQL 写性能是 Intel 的接近两倍。

关闭