最近作者有一個(gè)針對 ScaleFlux 的產(chǎn)品也叫做 CSD 2000 進(jìn)行壓測的機(jī)會(huì)。本文中作者將介紹使用 Intel SSD 和 ScaleFlux 存儲(chǔ)設(shè)備進(jìn)行壓測的對比結(jié)果。
一、我們?yōu)槭裁葱枰灰粯拥?ScaleFlux？
答案很簡單，它為我們提供了內(nèi)置的壓縮功能和支持原子寫特性。對于很多工作場景尤其是數(shù)據(jù)庫類型的業(yè)務(wù)而言，這些功能和特性非常重要。
因?yàn)閮?nèi)置的磁盤壓縮功能相同的磁盤容量，我們可以存儲(chǔ)更多的數(shù)據(jù)在 ScaleFlux 存儲(chǔ)設(shè)備上。（引申：大規(guī)模數(shù)據(jù)存儲(chǔ)的情況下，耗費(fèi)的機(jī)器數(shù)量更少，機(jī)架位也更少。）
作者基于不同的數(shù)據(jù)集大小，不同數(shù)據(jù)庫 schema 數(shù)據(jù)量進(jìn)行多次測試。需要說明的是在這些測試場景中我并不打算壓測這些卡的性能極限，而是對比相同容量下 ScaleFlux 存儲(chǔ)設(shè)備 和 Intel SSD 的性能表現(xiàn)。
存儲(chǔ)設(shè)備配置: ScaleFlux – CSD 2000 4TB Intel – P4610 3.2TB 服務(wù)器配置: 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 運(yùn)行 sysbench 壓測工具，在 Database Server 運(yùn)行 Percona Server for MySQL 8.0.19 。
作者禁用了 binary, slow query logging 和 adaptive hash，使用比較小的 BPS 配置，為了減少數(shù)據(jù)緩存，盡量讓 sql 請求訪問磁盤。另外就是測試了關(guān)閉和開啟 doublewrite 的性能表現(xiàn)。
數(shù)據(jù)庫的配置如下：
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
做了哪些測試
首先作者做了標(biāo)準(zhǔn)的 OLTP read_only,write_only 和 read-write 測試，然后作者修改分表結(jié)構(gòu)，
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 兩個(gè) varchar 字段，使用一本書（Gutenberg project）中的內(nèi)容行記錄進(jìn)行填充。
為什么這樣做？因?yàn)檫@也是 ScaleFlux 的優(yōu)勢之處，他們聲稱如果數(shù)據(jù)可以被壓縮，那么 ScaleFluxIntel 的性能要好很多。
作者還修改了 OLTP lua 腳本來適配新的表結(jié)構(gòu)，
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，我們來看看結(jié)果對比圖吧。
Default Sysbench – Read/Write – 220G Datasize
在默認(rèn)配置下，使用 100 張表，每個(gè)表 100w 條記錄，數(shù)據(jù)集大小為 220G。從結(jié)果圖中我們可以看到 Intel SSD 略微領(lǐng)先。ScaleFlux 存儲(chǔ)設(shè)備在并發(fā)度為 96 之后有領(lǐng)先的優(yōu)勢。
需要說明都是 ScaleFlux 支持原子寫，所以作者關(guān)閉了 InnoDB Double Write Buffer。而針對 Intel SSD 不支持原子寫，InnoDB Double Write Buffer 是開啟的。
Modified Sysbench – Read/Write – 440G Datasize
該場景下，作者使用了添加 2 個(gè)字段的壓測模型。數(shù)據(jù)量擴(kuò)大到 440G，而且使測試數(shù)據(jù)適合壓縮。
從結(jié)果上看，和 ScaleFlux 聲明的一樣，在數(shù)據(jù)可壓測的情況下，MySQL 在 ScaleFlux設(shè)備上的性能明顯優(yōu)于 Intel SSD，在高并發(fā)場景下，性能優(yōu)勢明顯。
再次說明 Intel SSD 上的 MySQL 未關(guān)閉 InnoDB Double Write Buffer，而是用 ScaleFlux 設(shè)備的 MySQL 是關(guān)閉了 InnoDB Double Write Buffer 的。
我們來看一下 Intel SSD 的 MySQL 也關(guān)閉 InnoDB Double Write Buffer 的測試結(jié)果。
在同時(shí)開啟或者關(guān)閉 Double Write 特性的對比測試中，使用 ScaleFlux 存儲(chǔ)設(shè)備的 MySQL 都表現(xiàn)比較明顯。
需要注意的是，我們不推薦在任何不支持原子寫的設(shè)備上關(guān)閉 InnoDB Double Write。
Modified Sysbench – Read/Write – 2.5T Datasize
兩個(gè)設(shè)備都有 3.2T 的存儲(chǔ)容量，作者壓測的數(shù)據(jù)使用了 2.5T。作者使用修改的表結(jié)構(gòu)重建了 sysbench 的表。從結(jié)果上來看 ScaleFlux 存儲(chǔ)設(shè)備上的 MySQL 性能優(yōu)勢比較明顯。一個(gè)影響性能的因素是 SSD 存在寫放大。當(dāng)數(shù)據(jù)量達(dá)到一定容量比例，SSD 會(huì)進(jìn)行類似垃圾回收的任務(wù)，耗費(fèi)資源，影響 SSD 的寫能力。
Disk Latency
從圖中可以查看到 ScaleFlux 存儲(chǔ)設(shè)備的響應(yīng)時(shí)間非常穩(wěn)定而 Intel 設(shè)備的響應(yīng)時(shí)間則波動(dòng)比較大。
CPU Usage
ScaleFlux – Read/Write – Modified Sysbench – 540 tables – 2.5T
Intel – Read/Write – Modified Sysbench – 540 tables – 2.5T
我們可以看到 Intel 設(shè)備的 iowait 比較高 31.52%，而 ScaleFlux 設(shè)備的 iowait 則是 11.46%，明顯低于 Intel 設(shè)備。
Disk Operations
從系統(tǒng)層的監(jiān)控?cái)?shù)據(jù)來看測試期間的 IOPS 表現(xiàn)。ScaleFlux 存儲(chǔ)設(shè)備提供更高的 IOPS 大約是 Intel 的 2 倍。更高的 IOPS 意味著 MySQL 的 QPS/TPS 更高，性能更好。下面的圖也說明了這一點(diǎn)。
InnoDB Row Operations
從上面這張圖中我們看到 Innodb 層的統(tǒng)計(jì)數(shù)據(jù)，每分鐘 inserted/updated/deleted 多少行記錄。
因?yàn)?InnoDB 關(guān)閉了 double write，使用 ScaleFlux 存儲(chǔ)設(shè)備的 MySQL 寫性能是 Intel 的接近兩倍。
