MGR vs PXC Benchmark

MGR vs PXC Benchmark

本次测试将MGR与PXC进行对比, 意在比较MGR自身不同流控阈值下性能表现以及观察MGR与PXC相同负载下的性能表现. 测试工具使用sysbench 1.1.0-431660d

基础环将信息如下表所示, 在三个测试服务器部署了3306, 3307两套集群

Host IP MGR PXC
data-191 192.168.8.191 3306 3307
data-219 192.168.8.219 3306 3307
data-220 192.168.8.220 3306 3307

这里我们不关心buffer size和iops

本次测试一个不严谨的地方是,pxc使用percona server5.2.0, MGR使用mysql server5.7.22

下文将展示测试结果和说明测试方法, 尽量客观展示测试事实(语文不太好, 见谅)

下文中:

25000表示MGR默认流控阈值下的测试情况

50000表示MGR默认流控阈值一倍下的测试情况

one_node_threshold_50000表示阈值5W关闭一个节点的流控下的测试情况

threshold_disable表示所有节点关闭流控下的测试情况


OLTP_WRITE_ONLY模式不同流控阈值下MGR表现

OLTP_WRITE_ONLY模式下每个事务包含

1个 index_updates UPDATE sbtest%u SET k=k+1 WHERE id=?

1个 non_index_updates UPDATE sbtest%u SET c=? WHERE id=?

1个 deletes DELETE FROM sbtest%u WHERE id=?

1个 inserts INSERT INTO sbtest%u (id, k, c, pad) VALUES (?, ?, ?, ?)

16线程压力下, 四种流控阈值场景下qps相差不多, 响应时间在阈值25000时较高, 这也符合预期

mgr_oltp_write_only_qps

latency

32 qps接近6W

64线程. 可以看到关闭流控和只关闭一个节点的流控的情况下qps差不多, 对于25000和5000可以看到qps一直在上下起伏震荡

128线程. 受内存或iops的限制可以看到对比64线程one_node_threshold_50000和threshold_disabled qps并没有再增高,响应时间稍有增高. 观察25000和5000可以发现在压测开始时,两者qps都能达到10W, 由于流控, qps迅速下降,然后就一直在5W左右震荡

256线程. one_node_threshold_50000和threshold_disabled qps并没有再增高,观察25000和5000可以发现在压测开始时,两者qps都能达到10W(比前两者的还高)之后又由于流控, qps迅速下降,然后就一直在5W左右震荡

对于响应时间one_node_threshold_disabled和threshold_disabled在20ms左右而25000和5000几个波峰达到了800ms+

这里还有一个有趣的现象, 16-256的各个负载下qps波谷有重合, 这个目前还不清楚是什么原因导致的

OLTP_READ_WRITE 模式MGR与PXC性能对比

仅从qps上看, MGR被完虐

仅从响应时间上看, MGR被完虐

OLTP_WRITE_ONLY模式MGR PXC性能对比

qps还是pxc稳一些

响应时间上MGR挽回了一些颜面, 线很稳, 但原因是因为MGR关了流控

集群中有短板节点场景下的测试

这里使用sysbench在220节点跑io压测, 制造短板节点, 在进行一轮测试.

OLTP_WRITE_ONLY模式不同流控阈值下MGR表现

可以看到,与没有短板时不同的是关闭流控时性能明显优于其他三种流控阈值场景

但随着并发数增加, 关闭流控时波谷越来越大, 其他三种流控阈值场景的qps也越来越低

响应时间方面 ,16线程时, 关闭流控响应时间却比其他三种流控阈值场景都高, 之后随着并发增大, 可以看到关闭流控后响应时间非常稳定, 而其他三种流控阈值场景响应时间基本在1s左右

对于复制延迟, 随着流控阈值越来越大, 延迟涨幅也越来越大

128线程时qps最高, 接近10W. 有一点值得注意的是即便关了流控, 还是周期性会有一些明显的波谷, 原因还不确定可能需要针对性进一步测试

OLTP_READ_WRITE 模式MGR与PXC性能对比

可看到,有短板的场景下, PXC的qps略低于MGR, 但是抖动较小, 当然最平稳的还是关闭流控的MGR

PXC响应时间略高于关闭了流控的MGR

复制延迟方面, 不是PXC性能好, 是PXC流控限制了qps, 所以没延迟

OLTP_WRITE_ONLY模式MGR PXC性能对比

基本和read write差不多了

结论?

可能是伪结论

只有在有明显短板时, 关闭了流控的MGR性能优于PXC. 但是在这种情况下关闭流控, 短板节点就不能作为读节点了, 复制延迟越来越大, 优点是不会因为短板而影响整个集群. 而PXC如果遇到短板节点影响了整个集群的节点怎么办呢?只能关闭这个拖后腿的节点了. 当问题解决想要再次重新加入集群时就可能需要做SST

性能方面是上面的情况, 那么对于运维方面呢? 优秀的数据库因当时稳定的, 可控的, 可诊断的. 从这三点来看:

  • 稳定: PXC有年头了, 有很多案例了. MGR还需要时间验证
  • 可控:
    • 对流控的处理, MGR显然由于PXC, 可以关闭流控
    • 增加节点, DBA只需哪一个my.cnf启动新节点指定doner即可, 剩下的事交给PXC自己去做SST. 而对于MGR, 需要DBA自己去拿备份恢复(好像也不能明确指定一个doner?)
  • 可诊断: MGR(5.7)的相关视图,status的还太少, 比如触发流控时,是没有status或日志信息的

总之, 还需要再多测测.

本次测试的数据

原始数据和图表自取:

链接:https://pan.baidu.com/s/1WwXjG34uxN-eZG42bwRWXQ 密码:nu0m

Powered by Hexo and Hexo-theme-hiker

Copyright © 2013 - 2018 Fan() All Rights Reserved.

访客数 : | 访问量 :

#