共计 11918 个字符，预计需要花费 30 分钟才能阅读完成。
简介：本篇来介绍一下 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… 本文为阿里云原创内容，未经容许不得转载。
