PolarDB-X 全局Binlog解讀之性能篇(上)

簡介： 本篇來介紹一下PolarDB-X全局binlog在性能方面的一些設計和思考，先通過幾個實際的測試案例來展示全局binlog的性能情況，然後結合這些案例來深入講解全局binlog關於優化的故事。

本篇來介紹一下PolarDB-X全局binlog在性能方面的一些設計和思考，先通過幾個實際的測試案例來展示全局binlog的性能情況，然後結合這些案例來深入講解全局binlog關於優化的故事。

測試準備

準備一個PolarDB-X 2.0實例，本文測試所用實例版本爲5.4.14-16576195，實例配置如下：

• 實例拓撲：8CN + 8DN + 2CDC
• 單CN節點規格：32核128GB
• 單DN節點規格：32核128GB
• 單CDC節點規格：16核32GB

準備兩臺ECS壓測機，機器配置：64核128G

名詞解釋

• EPS

Event Per Second，每秒寫入binlog文件的event個數

• DML EPS

DML Event Per Second，每秒寫入binlog文件的dml event個數，所謂dml event特指binlog中的TableMapEvent、WriteRowsEvent、UpdateRowsEvent和DeleteRowsEvent

• BPS

Byte Per Second，每秒寫入binlog文件的字節數，後文爲表達方便，採用M/s來作爲計量單位

• TPS

Transaction Per Second，每秒鐘寫入binlog文件的事務個數

• FPM

File Per Minute，每分鐘生成binlog文件的個數，單個文件大小500M

• Delay Time

延遲時間，單位ms

測試方案

TPCC

測試方法參見：https://help.aliyun.com/document_detail/405018.html
本測試案例，TPCC核心參數的配置如下：

• warehouses=2000
• loadWorkers=500
• terminals=1024
• runLoader.sh 中JVM參數配置 -Xms60g -Xmx60g
• runBenchmark.sh 中JVM參數配置 -Xms60g -Xmx60g

場景一：TPCC數據導入

• 測試目的

在進行壓測數據導入時，DN節點會瞬時產生大量物理binlog，藉此觀察全局binlog的性能指標情況

• 測試方式

在每臺ECS上面分別部署多份tpcc程序包，同時運行多個./runDatabaseBuild.sh，來構造流量

場景二：TPCC交易測試

• 測試目的

執行TPCC測試，模擬真實交易場景，考察全局binlog的性能情況(重點關注延遲)

• 測試方式

調整壓測併發度，構造不同的tmpC參考指標，觀察全局binlog延遲指標。由於8CN+8DN在壓力打滿的情況下，全局binlog的延遲依然比較低，所以下面的測試，不侷限於8CN+8DN

Sysbench

測試方法參見: https://help.aliyun.com/document_detail/405017.html

場景一：Sysbench數據導入

• 測試目的

在進行壓測數據導入時，DN節點會瞬時產生大量物理binlog，藉此觀察全局binlog的性能指標情況

• 測試方式

調整--tables和--threads的參數值，測試不同壓力狀態下全局binlog的性能指標

場景二：Sysbench oltp_write_only

• 測試目的

執行sysbench oltp_write_only，測試混合寫入場景下，全局binlog性能情況

• 測試方式

執行oltp_write_only，構造不同qps參考指標，觀察全局binlog延遲情況

Large Transaction

• 測試目的

測試超大事務場景下，CDC的性能情況和穩定性，重點關注延遲時間

• 測試方式

參考如下腳本，構造不同大小的事務，進行測試，按如下腳本，每插入20w條數據可以構造一個500M大小的事務

CREATE TABLE `t_1`
(`id` bigint(20) NOT NULL AUTO_INCREMENT,
`c_bit_1` bit(1) DEFAULT NULL,
`c_bit_8` bit(8) DEFAULT NULL,
`c_bit_16` bit(16) DEFAULT NULL,
`c_bit_32` bit(32) DEFAULT NULL,
`c_bit_64` bit(64) DEFAULT NULL,
`c_tinyint_1` tinyint(1) DEFAULT NULL,
`c_tinyint_4` tinyint(4) DEFAULT NULL,
`c_tinyint_8` tinyint(8) DEFAULT NULL,
`c_tinyint_8_un` tinyint(8) unsigned DEFAULT NULL,
`c_smallint_1` smallint(1) DEFAULT NULL,
`c_smallint_16` smallint(16) DEFAULT NULL,
`c_smallint_16_un` smallint(16) unsigned DEFAULT NULL,
`c_mediumint_1` mediumint(1) DEFAULT NULL,
`c_mediumint_24` mediumint(24) DEFAULT NULL,
`c_mediumint_24_un` mediumint(24) unsigned DEFAULT NULL,
`c_int_1` int(1) DEFAULT NULL,
`c_int_32` int(32) DEFAULT NULL,
`c_int_32_un` int(32) unsigned DEFAULT NULL,
`c_bigint_1` bigint(1) DEFAULT NULL,
`c_bigint_64` bigint(64) DEFAULT NULL,
`c_bigint_64_un` bigint(64) unsigned DEFAULT NULL,
`c_decimal` decimal DEFAULT NULL,
`c_decimal_pr` decimal(10,3) DEFAULT NULL,
`c_float` float DEFAULT NULL,
`c_float_pr` float(10,3) DEFAULT NULL,
`c_float_un` float(10,3) unsigned DEFAULT NULL,
`c_double` double DEFAULT NULL,
`c_double_pr` double(10,3) DEFAULT NULL,
`c_double_un` double(10,3) unsigned DEFAULT NULL,
`c_date` date DEFAULT NULL COMMENT 'date',
`c_datetime` datetime DEFAULT NULL,
`c_timestamp` timestamp DEFAULT CURRENT_TIMESTAMP,
`c_time` time DEFAULT NULL,
`c_year` year DEFAULT NULL,
`c_year_4` year(4) DEFAULT NULL,
`c_char` char(50) DEFAULT NULL,
`c_varchar` varchar(50) DEFAULT NULL,
`c_binary` binary(200) DEFAULT NULL,
`c_varbinary` varbinary(200) DEFAULT NULL,
`c_blob_tiny` tinyblob DEFAULT NULL,
`c_blob` blob DEFAULT NULL,
`c_blob_medium` mediumblob DEFAULT NULL,
`c_blob_long` longblob DEFAULT NULL,
`c_text_tiny` tinytext DEFAULT NULL,
`c_text` text DEFAULT NULL,
`c_text_medium` mediumtext DEFAULT NULL,
`c_text_long` longtext DEFAULT NULL,
`c_enum` enum('a','b','c') DEFAULT NULL,
`c_set` set('a','b','c') DEFAULT NULL,
`c_testcase` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`) )ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='10000000' dbpartition by hash(`id`) tbpartition by hash(`id`) tbpartitions 8;

INSERT t_1 (c_bit_1 , c_bit_8 , c_bit_16 , c_bit_32 , c_bit_64 , c_tinyint_1 , c_tinyint_4 , c_tinyint_8 , c_tinyint_8_un , c_smallint_1 , c_smallint_16 , c_smallint_16_un , c_mediumint_1 , c_mediumint_24 , c_mediumint_24_un , c_int_1 , c_int_32 , c_int_32_un , c_bigint_1 , c_bigint_64 , c_bigint_64_un , c_decimal , c_decimal_pr , c_float , c_float_pr , c_float_un , c_double , c_double_pr , c_double_un , c_date , c_datetime , c_timestamp , c_time , c_year , c_year_4 , c_char , c_varchar , c_binary , c_varbinary , c_blob_tiny , c_blob , c_blob_medium , c_blob_long , c_text_tiny , c_text , c_text_medium , c_text_long , c_enum , c_set , c_testcase) 
VALUES( 
b'1' , b'11111111' , b'1111111111111111' , b'11111111111111111111111111111111' , b'1111111111111111111111111111111111111111111111111111111111111111' , '82' , '-101' , '-75' ,'253' , '14497' , '5070' , '9427' , '-5888259' , '-1845105' , '2350597' , '-2147483648' , '-2147483648' , '3653062473' , '-816854218224922624' , '7292572323853307904' , '2902765992697493504' , '-1613793319' , '1223077.292' , '9.1096275E8' , '-5839673.5' , '2648.644' , '4.334081673614155E9' , '6973286.176' , '7630560.182' , '2019-02-15' , '2019-02-15 14:54:41' , '2019-02-15 14:54:41' , '20:12:46' , '2019' , '2019', 'xxx','int a = max(4,5)','xxxxxxx','varchar a = ','xxkdkwjsjdfdsk','varchar a = ',';sdjfaljdljfsljldjlsjdljflsjdlfjsaljdlfhahdljflajdlfasdf','int a = max(4,5)','xxx','sdjflshdflsjlfa;;dfjadjfahdfhklsajdfklsafasjlfjls',repeat('a',1024),repeat('a',1024), 'a', 'a', 'caseNo1');

INSERT t_1 ( c_bit_1 ,  c_bit_8 ,  c_bit_16 ,  c_bit_32 ,  c_bit_64 ,  c_tinyint_1 ,  c_tinyint_4 ,  c_tinyint_8 ,  c_tinyint_8_un ,  c_smallint_1 ,
c_smallint_16 ,  c_smallint_16_un ,  c_mediumint_1 ,  c_mediumint_24 ,  c_mediumint_24_un ,  c_int_1 ,  c_int_32 ,  c_int_32_un ,  c_bigint_1 ,  c_bigint_64
,  c_bigint_64_un ,  c_decimal ,  c_decimal_pr ,  c_float ,  c_float_pr ,  c_float_un ,  c_double ,  c_double_pr ,  c_double_un ,  c_date ,  c_datetime ,  c_timestamp ,  c_time ,  c_year ,  c_year_4 ,  c_char ,  c_varchar ,  c_binary ,  c_varbinary ,  c_blob_tiny ,  c_blob ,  c_blob_medium ,  c_blob_long ,  c_text_tiny ,  c_text ,  c_text_medium ,  c_text_long ,  c_enum ,  c_set ,  c_testcase) select c_bit_1 ,  c_bit_8 ,  c_bit_16 ,  c_bit_32 ,  c_bit_64 ,  c_tinyint_1 ,  c_tinyint_4 ,  c_tinyint_8 ,  c_tinyint_8_un ,  c_smallint_1 ,  c_smallint_16 ,  c_smallint_16_un ,  c_mediumint_1 ,  c_mediumint_24 ,  c_mediumint_24_un ,  c_int_1 ,  c_int_32 ,  c_int_32_un ,  c_bigint_1 ,  c_bigint_64 ,  c_bigint_64_un ,  c_decimal ,  c_decimal_pr ,  c_float ,  c_float_pr ,  c_float_un ,  c_double ,  c_double_pr ,  c_double_un ,  c_date ,  c_datetime ,  c_timestamp ,  c_time ,  c_year ,  c_year_4 ,  c_char ,  c_varchar ,  c_binary ,  c_varbinary ,  c_blob_tiny ,  c_blob ,  c_blob_medium ,  c_blob_long ,  c_text_tiny ,  c_text ,  c_text_medium ,  c_text_long ,  c_enum ,  c_set ,  c_testcase from t_1;

測試報告

先給出彙總後的測試報告，再進行詳細介紹，測試數據如下：

測試場景	參考指標	DelayTime	EPS	BPS
TPCC數據導入	4000倉/600併發	300ms	10w/s	350M/s
TPCC數據導入	8000倉/1200併發	700ms	15w/s	450M/s-500M/s
TPCC數據導入	12000倉/1800併發	1s-60s	15w/s	450M/s-500M/s
Sysbench數據導入	32Tables/32併發	500ms	180w/s	140M/s
Sysbench數據導入	48Tables/48併發	1s	210w/s	170M/s
Sysbench數據導入	64Tables/64併發	1s-70s	220w/s	180M/s
TPCC交易測試	50w tpmC	400ms	60w/s	130M/s
TPCC交易測試	100w tpmC	500ms	120w/s	250M/s
TPCC交易測試	150w tpmC	1s-4s	170w/s	350M/s
Sysbench Oltp_write_only	20w QPS	500ms	130w/s	125M/s
Sysbench Oltp_write_only	30w QPS	600ms	180w/s	170M/s
Sysbench Oltp_write_only	35w QPS	1s-18s	210w/s	200M/s
大事務	500M	2s	24w/s	500M/s
大事務	1G	4.8s	24w/s	500M/s
大事務	2G	7.8s	24w/s	500M/s
大事務	3G	9.4s	24w/s	500M/s
大事務	4G	12.5s	24w/s	500M/s
大事務	5G(no swap)	17s	24w/s	500M/s
大事務	5G(with swap)	25s	22w/s	350M/s
大事務	10G(with swap)	55s	22w/s	350M/s
大事務	20G(with swap)	115s	22w/s	350M/s

TPCC數據導入

Test With 2 Client

• EPS: 10w/s，DML EPS: 6w/s

• BPS: 350M/s，FPM: 40個/m

• TPS: 11000/s

• Delay Time: 300ms

• 另附CDC進程GC情況：內存使用率不高、GC平穩、無老年代GC

綜述：兩個client場景下(4000倉/600併發)，寫入吞吐平均值約350M/s，延遲時間在300ms左右，完全無壓力

Test With 4 Client

• EPS: 14w/s ~ 16w/s，DML EPS: 7.5w/s ~ 9w/s

• BPS: 450M/s ~ 500M/s，FPM: 52個/m ~ 60個/m

• TPS: 15000/s

• Delay Time: 700ms，最大延遲抖動10S

• 另附CDC進程GC情況：老年代內存使用率略有提升、GC平穩、無老年代GC

綜述：四個client場景下(8000倉/1200併發)，基本無壓力，寫入吞吐在450M/s～500M/s，延遲時間總體上可以維持在1S以下，最大延遲抖動10S且有一定的持續時間，其它大部分指標相比兩個client場景基本可以達到翻倍

Test With 6 Client

• EPS: 14w/s ~ 16w/s，DML EPS: 8w/s ~ 9w/s

• BPS: 450M/s ~ 500M/s，FPM: 55個/m ~ 60個/m

• TPS: 15000/s

• Delay Time: 延遲呈遞增趨勢，最大延遲1分鐘

• 另附CDC進程GC情況：緩衝區開始出現積壓，老年代使用率提升明顯

• 另附CDC文件寫入線程CPU使用率情況

綜述：六個client場景下(12000倉/1800併發)，延遲開始出現增長，數據導入時長20min，觸發最大延遲60S，其它指標和4個Client場景下相比基本持平，主要瓶頸點在文件寫入線程，CPU使用率已經達到了100%，每秒500M左右的寫入速度目前是全局binlog能支持的最大吞吐，後序進一步的優化進展會在本文持續更新，敬請關注

Sysbench數據導入

Test With 32 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='32' --threads='32' --table-size='10000000' oltp_point_select prepare

• EPS: 180w/s，DML EPS: 60w/s

• BPS: 140M/s，FPM: 17個/m

• TPS: 30w/s

• Delay Time: 500ms,最大延遲抖動2s

綜述：32張表並行插入場景下，延遲基本可以控制在1s以內。相比TPCC導數據，Sysbench場景下EPS指標呈現了數十倍的提升，但BPS指標則要低很多，主要是因爲Sysbench的表比較小，插入邏輯也簡單直接，所以數據插入的rps(record per second)很高但流量並不是很大，各項指標對比見下表：

指標項	TPCC	Sysbench
EPS	14w/s ~ 16w/s	170w/s
DML EPS	7.5w/s ~ 9w/s	60w/s
BPS	450M/s ~ 500M/s	140M/s
TPS	15000/s	30w/s
Delay Time	700ms	500ms
FPM	52個/m ~ 60個/m	17個/m

Test With 48 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='48' --threads='48' --table-size='10000000' oltp_point_select prepare

• EPS: 210w/s，DML EPS: 接近70w/s

• BPS: 170M/s

• TPS: 36w/s，FPM: 20個/m

• Delay Time: 1s，最大延遲10s

綜述：48張表並行插入場景下，各項指標有了小幅度提升，延遲時間總體在1s左右，最大10s。

Test With 64 Tables

sysbench --config-file='sysb.conf' --create-table-options='dbpartition by hash(`id`) tbpartition by hash(id) tbpartitions 8'  --tables='64' --threads='64' --table-size='10000000' oltp_point_select prepare

• EPS: 220w/s，DML EPS: 接近75w/s

• BPS: 180M/s

• TPS: 37w/s，FPM: 21個/m

• Delay Time: 最大延遲70s

綜述：64張表並行插入場景下，各項指標有了小幅度提升，延遲時間開始增大，最大延遲時間70s。因涉及全局排序和事務合併，以及需要對每個event進行checksum的計算，目前全局binlog可支持的最大EPS在220w/S左右，後序進一步的優化進展會在本文持續更新，敬請關注

TPCC交易測試

50w-55w tpmC

• tpmC: 50w/m ~ 55w/m

• EPS: 60w/s，DML EPS: 37w/s ~ 40w/s

• BPS: 130M/s，FPM: 15個/m

• TPS: 18000/s

• Delay Time: 400ms

綜述：tpmC 50w/m ~ 55w/m，Tps 18000/s, 全局binlog延遲400ms左右, DML EPS平均在37w/s左右，BPS 130M/s左右

100w-105w tpmC

• tpmC: 100w/m ~ 105w/m

• EPS: 120w/s，DML EPS: 75w/s

• BPS: 250M/s，FPM: 30個/m

• TPS: 35000/s

• Delay Time: 500ms

綜述：tpmC 100w/m~105w/m，Tps 35000/s, 全局binlog延遲500ms左右, DML EPS平均在75w/s左右，BPS 250M/s左右

145w-150w tpmC

• tpmC: 145w/m ~ 150w/m

• EPS: 170w/s，DML EPS: 100w/s

• BPS: 350M/s，FPM: 42個/m

• TPS: 50000/s

• Delay Time: 1s ~ 4s。前段和後段延遲在1.5s左右，中段延遲在4s左右，但中段tpmC其實並沒有前段高，原因在於在壓力打滿情況下，偶發抖動都會導致延遲時間的變化，多次複測並不是每次都會達到4s延遲，這裏取一個最壞的測試結果，150w tpmC場景下常規延遲時間大概在2s左右

綜述：tpmC 145w/m ~ 150w/m，Tps 50000/s, 全局binlog延遲1s-4s左右，EPS 170w/s，DML EPS平均在100w/s左右，BPS 350M/s左右

Sysbench oltp_write_only

20w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=300 oltp_write_only run

• Sysbench: 21w+ qps, 5w+ tps

• 延遲時間：500ms

• EPS:130w+, DML EPS:43w+

• BPS: 125M/s

30w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=512 oltp_write_only run

• Sysbench: 30w qps, 7.5w tps

• 延遲時間：600ms

• EPS:180w+, DML EPS:55w+

• BPS: 170M/s

35w qps

sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all'  --tables='16' --table-size='10000000' --threads=800 oltp_write_only run

• Sysbench: 35w~40w qps, 9w~10w tps

• 延遲時間：18s

• EPS: 200w+/s, DML EPS:70w+/s

• BPS: 200M/s

綜述：35w qps壓力下，已經接近220w/s的最大EPS能力，壓測時間10分鐘，最大延遲達到18s

Large Transaction

先來介紹幾個參數

• storage.isPersistOn

是否開啓swap功能，即當內存不足或遇到大事務時，是否支持數據臨時swap到磁盤(RocksDB)，默認爲true

• storage.persist.mode

持久化模式，可選配置有兩個：AUTO和FORCE。AUTO模式下，系統會根據內存使用率自動判斷是否需要將數據swap到磁盤；FORCE模式下，系統會強制將數據swap到磁盤

• storage.persistNewThreshold

內存中新增數據觸發swap的閾值，即內存使用率達到多大之後，新增數據會被swap到磁盤，默認85%

• storage.persistAllThreshold

內存中存量數據觸發swap的閾值，即內存使用率達到多大之後，存量數據會被swap到磁盤，默認95%

5G Close Persist

單個事務大小5G，關閉swap功能，本測試場景，老年代內存14G，即使考慮到數據膨脹，足夠放下5G數據

• Delay Time: 所有數據完成排序時延遲7s，所有數據輸出到全局binlog文件時延遲17s

• Task進程內存: 老年代使用率顯著提升

綜述：關閉持久化，全內存模式下，5G數據在17S內完成同步，老年代內存使用率顯著提升

5G Force Persist

單個事務大小5G，開啓swap功能，並將持久化模式設置爲FORCE

• Delay Time: 所有數據完成排序時延遲10s，所有數據輸出到全局binlog文件時延遲25s

• CDC進程內存情況: 由於採用強制持久化機制，內存佔用無起伏

綜述：相比close persist模式，強制持久化模式下，延遲增加了8s，老年代內存佔用無明顯起伏

10G Auto Persist With 4G Memory

單個事務大小10G，開啓swap功能，並將持久化模式設置爲AUTO，Task進程內存設置爲4G(無法放下10G數據)，評測系統的自動持久化能力

• Delay Time: 所有數據完成排序時延遲23s，所有數據輸出到全局binlog文件時延遲55s

• Task進程內存: 老年代並未顯著上漲

• Swap日誌：單個局部事務大小超過閾值，直接觸發了swap

綜述：AUTO模式下，對於大事務的落盤，系統採取了更加積極主動的方式，即使內存使用率還未觸發swap閾值，當單個局部事務大小超過閾值之後，也會直接觸發swap，並且性能還算不錯。之所以引入這種策略，主要原因是：

• 出現大事務時，大概率會觸發內存不足，直接觸發swap，免去老年代GC的成本
• swap操作雖然會有一定的損耗，但總體上的延遲還不錯，優先考慮穩定性

20G Auto Persist With 4G Memory

單個事務大小20G，開啓swap功能，並將持久化模式設置爲AUTO，Task進程內存設置爲4G(無法放下20G數據)，評測系統的自動持久化能力

• Delay Time: 所有數據完成排序時延遲49s，所有數據輸出到全局binlog文件時延遲115s

• Task進程內存: 老年代小幅上漲

• Swap日誌：單個局部事務大小超過閾值，直接觸發了swap

總結

本文基於TPCC、Sysbench和Large Transaction3個場景，對全局Binlog的性能和穩定性情況進行了詳細介紹，綜合來看：

• 寫入吞吐可以達到500M/S(30G/min)左右，EPS指標可以達到220W/S左右，且內存使用率維持在較低的水位
• TPCC場景，在150w tpmC壓力下，延遲時間可以控制在4s以內，大部分時間段延遲時間保持在2s左右
• Sysbench場景，30w QPS壓力下，延遲時間可以維持在1s以內，更高壓力下由於已經觸達220w/s的EPS能力，延遲時間開始增長(繼續提升EPS的上限是全局binlog後續的一個重點目標)
• Large Transaction場景，依託自動swap能力，使用很小的內存可以穩定的同步超大事務，且能保持還不錯的性能(繼續優化swap的讀寫能力，延遲時間還有進一步的降低空間)

優化無止境，如果對PolarDB-X充滿興趣，可持續關注我們，最新的優化進展會持續更新。本文是全局Binlog性能解讀系列的上篇，下篇將從原理層面展開深入介紹，敬請關注。

歡迎關注PolarDB-X知乎機構號，閱讀更多技術好文。

原文鏈接：https://click.aliyun.com/m/1000362576/

本文爲阿里雲原創內容，未經允許不得轉載。