简介： 本篇来介绍一下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名词解释EPSEvent Per Second，每秒写入binlog文件的event个数DML EPSDML Event Per Second，每秒写入binlog文件的dml event个数，所谓dml event特指binlog中的TableMapEvent、WriteRowsEvent、UpdateRowsEvent和DeleteRowsEventBPSByte Per Second，每秒写入binlog文件的字节数，后文为表白不便，采纳M/s来作为计量单位TPSTransaction Per Second，每秒钟写入binlog文件的事务个数FPMFile Per Minute，每分钟生成binlog文件的个数，单个文件大小500MDelay Time延迟时间，单位ms测试计划TPCC测试方法参见：https://help.aliyun.com/docum...本测试案例，TPCC外围参数的配置如下：warehouses=2000loadWorkers=500terminals=1024runLoader.sh 中JVM参数配置 -Xms60g -Xmx60grunBenchmark.sh 中JVM参数配置 -Xms60g -Xmx60g场景一：TPCC数据导入测试目标在进行压测数据导入时，DN节点会刹时产生大量物理binlog，借此察看全局binlog的性能指标状况测试形式在每台ECS下面别离部署多份tpcc程序包，同时运行多个./runDatabaseBuild.sh，来结构流量场景二：TPCC交易测试测试目标执行TPCC测试，模仿实在交易场景，考查全局binlog的性能状况(重点关注提早)测试形式调整压测并发度，结构不同的tmpC参考指标，察看全局binlog提早指标。因为8CN+8DN在压力打满的状况下，全局binlog的提早仍然比拟低，所以上面的测试，不局限于8CN+8DNSysbench测试方法参见: https://help.aliyun.com/docum...场景一：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;测试报告先给出汇总后的测试报告，再进行具体介绍，测试数据如下：测试场景参考指标DelayTimeEPSBPSTPCC数据导入4000仓/600并发300ms10w/s350M/sTPCC数据导入8000仓/1200并发700ms15w/s450M/s-500M/sTPCC数据导入12000仓/1800并发1s-60s15w/s450M/s-500M/sSysbench数据导入32Tables/32并发500ms180w/s140M/sSysbench数据导入48Tables/48并发1s210w/s170M/sSysbench数据导入64Tables/64并发1s-70s220w/s180M/sTPCC交易测试50w tpmC400ms60w/s130M/sTPCC交易测试100w tpmC500ms120w/s250M/sTPCC交易测试150w tpmC1s-4s170w/s350M/sSysbench Oltp_write_only20w QPS500ms130w/s125M/sSysbench Oltp_write_only30w QPS600ms180w/s170M/sSysbench Oltp_write_only35w QPS1s-18s210w/s200M/s大事务500M2s24w/s500M/s大事务1G4.8s24w/s500M/s大事务2G7.8s24w/s500M/s大事务3G9.4s24w/s500M/s大事务4G12.5s24w/s500M/s大事务5G(no swap)17s24w/s500M/s大事务5G(with swap)25s22w/s350M/s大事务10G(with swap)55s22w/s350M/s大事务20G(with swap)115s22w/s350M/sTPCC数据导入Test With 2 ClientEPS: 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 ClientEPS: 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 ClientEPS: 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 Tablessysbench --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 prepareEPS: 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)很高但流量并不是很大，各项指标比照见下表：指标项TPCCSysbenchEPS14w/s ~ 16w/s170w/sDML EPS7.5w/s ~ 9w/s60w/sBPS450M/s ~ 500M/s140M/sTPS15000/s30w/sDelay Time700ms500msFPM52个/m ~ 60个/m17个/mTest With 48 Tablessysbench --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 prepareEPS: 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 Tablessysbench --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 prepareEPS: 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 tpmCtpmC: 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 tpmCtpmC: 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 tpmCtpmC: 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_only20w qpssysbench --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 runSysbench: 21w+ qps, 5w+ tps
延迟时间：500ms
EPS:130w+, DML EPS:43w+
BPS: 125M/s
30w qpssysbench --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 runSysbench: 30w qps, 7.5w tps
延迟时间：600ms
EPS:180w+, DML EPS:55w+
BPS: 170M/s
35w qpssysbench --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 runSysbench: 35w~40w qps, 9w~10w tps
延迟时间：18s
EPS: 200w+/s, DML EPS:70w+/s
BPS: 200M/s
综述：35w qps压力下，曾经靠近220w/s的最大EPS能力，压测工夫10分钟，最大提早达到18sLarge Transaction先来介绍几个参数storage.isPersistOn是否开启swap性能，即当内存不足或遇到大事务时，是否反对数据长期swap到磁盘(RocksDB)，默认为truestorage.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性能，并将长久化模式设置为FORCEDelay 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/10...本文为阿里云原创内容，未经容许不得转载。