网易cetus读写分离--压力测试

Posted 2021-05-02 破产DBA

前篇介绍了cetus读写分离的使用用法，做了简单的测试, 发现cetus是简单易用的，且对资源利用率很高，本文将对cetus进行双节点主从读写分离测试，使用sysbench生产12张1500万数据表做基准压力测试，获取不同并发线程场景下的QPS，TPS，及语句执行时长。在读写模式下由于事务的因素，事务中的语句会直接发往主库，故无法完全复现生产场景，仅做基准压力测试，仅用作参考。

测试说明：
没有cetus那么豪华的装备，只测试基础情况，1个cetus节点，2个mysql（主从），对于最大测试线程数也只到1000线程。

所有文件已上传至百度网盘：https://pan.baidu.com/s/1DGtcoea56bNaNtToAM0Sog

测试的方方面面可能有所纰漏，请大家多多指教。微信：fanmeng168

测试环境

测试软件

本次使用的是老少皆宜的sysbench (版本1.0.9)，对只读做非事务测试，读写做事务级的测试。 本想使用TPCC来做，但TPCC得手动修改代码才能做非事务的查询，考虑到cetus自己已经做了基于TPCC修改版的压力测试，我就不再重复用TPCC了。 附官方github压力测试URL ： 

https://github.com/Lede-Inc/cetus/blob/master/doc/cetus-test.md

---

测试方法

测试数据量:

表数量：12
单标数据量：1500万
理由: 经过多伦测试发现表数量太小不能反映真实情况，太大了会“压力超标”测试出的结果就没任何参考价值，多轮测试发现在8C/64G/200G配置的情况下使用12表，1500万单表数据量是比较有意义的，再多一表多一点数据量磁盘空间就可能会不足，内存命中率会下降，我想生产环境也不会让这种事发生。

测试流程

使用sysbench不同的lua脚本测试在不同线程并行的情况下，在一定时间范围内TPS,QPS,执行时间（95%语句或事物）

• 4个测试场景

连接cetus只读
连接主库只读
连接cetus读写
连接主库读写

• 31种线程级别

为模拟各种负载情况，测试了便利31中线程执行：
4 8 12 16 32 64 86 98 112 128 164 180 200 220 
250 280 300 350 400 450 500 550 600 650 700 750 
800 850 900 950 1000

• 4个测试间隔处理

为避免各单元测试间发生影响，特配置：

• 只读测试间sleep 20s

• 读写测试间sleep 120s，避免主从延迟造成影响下一个cetus测试

• 正式测试前预热60s，将数据尽可能都缓冲到内存，不缓存对结果影响很大

• 单次测试后调用脚本清除cache，释放swap

• 单次测试持续时间300s， 之前想过测更长时间比如半小时，但持续一段时间发现半小时与5分钟结果没有太大差异，再加上测试时间实在太长 31线程4个模式300s,加上sleep时间，差不多要13个小时，如果单次设置到半小时，则总时长将在64小时，臣妾实在是做不到.......，故做此配置。

  
  

• 2个脚本

sysbench批量脚本
执行时直接放后台执行 nohup sh sysbench_bench.sh &
结果处理
从sysbench结果文件中获取TPS,QPS nohup sh analyze_log.sh &

脚本文件已上传到百度网盘： 

https://pan.baidu.com/s/1DGtcoea56bNaNtToAM0Sog

只读模式测试

趋势

从大趋势上可以看到在只读模式下，通过cetus与通过单库master相比几乎是成比例增加：

1. 98线程后cetus的QPS可达单实例的两倍多

2. sql的完成时间随着线程数的cetus相对稳定，而单实例随着线程的增加呈现出增加的趋势，且QPS也有下降的趋势。

总结

从大趋势上可以看到在只读模式下，通过cetus与通过单库master相比几乎是成比例增加：

在只读模式下，cetus的线程池，TCP流式性能发挥的淋漓尽致，只读模式下扩充节点性能几乎是线性提升。

读写模式下测试

分析说明：

由于cetus在使用事务的情况下，会强制走主库，在sysbench的参数中也没有指定skip_trx=on，因为写操作一般都需要加上事务，跳过事务的话跟实际使用有很大差异，所以sysbench的结果与预想的差距很大也是意料之中，需要特别说明的是即使是全事务操作，cetus也比只使用主库也有部分提升，TPS相比但主库增长100左右，QPS增长大概是在2000左右，在实际业务测试肯定会比这要好的多，毕竟并不是所有业务所有sql执行都是走的事务，具体可以参考cetus基于tpcc修改版本的测试，我相信分库后，相当于把写扩展了，性能会更好些，后续将持续测试。

分析sysbench读写模式源码： 

oltp_read_write.lua做的操作是1个select，2个update，1个delete

require("oltp_common")

function prepare_statements()   #参数指定skip_trx，此处表示会使用事务
   if not sysbench.opt.skip_trx then
      prepare_begin()
      prepare_commit()   end
   
   # 语句1： 1个主键查询"SELECT c FROM sbtest%u WHERE id=?"
   prepare_point_selects()   #参数未指定range_selects，不执行
   if sysbench.opt.range_selects then
      prepare_simple_ranges()
      prepare_sum_ranges()
      prepare_order_ranges()
      prepare_distinct_ranges()   end
   
   # 语句2:1个索引键所在列的更新："UPDATE sbtest%u SET k=k+1 WHERE id=?"
   prepare_index_updates()   
   #  语句3：1个非索引键列的更新："UPDATE sbtest%u SET c=? WHERE id=?"
   prepare_non_index_updates()   
   #  语句4:1个基于索引的删除："DELETE FROM sbtest%u WHERE id=?",
   prepare_delete_inserts()end

---

测试总结

1. 只读模式下cetus性能优越，性能几乎线性提升

2. 读写模式下，本次并没有测试出cetus真实结果，因为sysbench读写测试所有sql都是事务的，这种情况无法使用从库，不过性能竟然比直接连master还要好些。

3. 后续将测试下加去掉部分事务的方式测试下，不过这对底层存储性能需求很高，目前使用的机器iops在3400左右，在开启并行复制，去掉从库log-bin后在300线程下延迟会比较大，从库的频繁上线下线对性能影响很大，后续将考虑测试使用1万iops以上的ssd来继续测试。

4. cetus的分表应该能有效扩展数据库写操作，后期也会继续进行测试实践。

测试的方方面面可能有所纰漏，请大家多多指教。微信：fanmeng168

---

附Mysql主要配置

#1.基础配置

character-set-server= utf8mb4

collation-server= utf8mb4_general_ci

init_connect='SET NAMESutf8mb4'

transaction_isolation='READ-COMMITTED'

 

#2.连接及超时配置

max_connect_errors= 1000

max_connections=3500

 

#max_prepared_stmt_count 参数限制了同一时间在mysqld上所有session中prepared 语句的上限。

#取值范围为“0 -1048576”，默认为16382，此处设置到最大值，否则容易报错。

max_prepared_stmt_count=1048576

interactive_timeout= 1800

wait_timeout= 1800

#back_log表示如果MySql的连接数达到max_connections时，新来的请求将会被存在堆栈中

#以等待某一连接释放资源，该堆栈的数量即back_log，如果等待连接的数量超过back_log

#将不被授予连接资源。建议配置值=(max_connections/ 5), max 900

back_log =330

 

innodb_lock_wait_timeout= 30

max_allowed_packet= 128M

 

#3.缓存及磁盘相关

##redo

innodb_log_group_home_dir= /lhdata/mysql/redo

innodb_log_files_in_group= 3

innodb_log_file_size= 1024M

 

innodb_buffer_pool_size= 56320M

innodb_flush_method= O_DIRECT

 

##主库开启binlog，从库关闭log-bin

log-bin=/lhdata/mysql/binlog/mysql-node2_3306__mysql-bin

#log_slave_updates

 

binlog_cache_size= 524288

binlog_format= ROW

#记录dml前后所有字段的值

binlog_row_image= full

#在binlog中记录原始sql语句

binlog_rows_query_log_events=1

 

#关闭general_log

#general_log = on

master_info_repository= TABLE

relay_log_info_repository= TABLE

 

relay_log_recovery= 1

slave_skip_errors= ddl_exist_errors

 

#配置脏也刷新的速率

innodb_io_capacity_max=10000

innodb_io_capacity=10000

 

#关键配置，设置slave同步并行

slave_parallel_type=LOGICAL_CLOCK

slave_parallel_workers=10

 

innodb_file_per_table= 1

innodb_purge_threads= 1

 

##配置读写线程数

innodb_write_io_threads= 8

innodb_read_io_threads= 8

#双1配置

innodb_flush_log_at_trx_commit= 1

sync_binlog= 1

 

##关闭query_Cache

query_cache_size= 0

query_cache_type= 0

 

##myisam not use

#read_buffer_size = 131072

#read_rnd_buffer_size = 262144

 

##when order by,group by

sort_buffer_size= 2097152