首页 > 数据库 > > 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模式下每个事务包含
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时较高, 这也符合预期
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波谷有重合,这个原因详见https://blog.csdn.net/ashic/article/details/88547014
仅从qps上看, MGR被完虐
仅从响应时间上看, MGR被完虐
qps还是pxc稳一些
响应时间上MGR挽回了一些颜面, 线很稳, 但原因是因为MGR关了流控
这里使用sysbench在220节点跑io压测, 制造短板节点, 在进行一轮测试.
可以看到,与没有短板时不同的是关闭流控时性能明显优于其他三种流控阈值场景
但随着并发数增加, 关闭流控时波谷越来越大, 其他三种流控阈值场景的qps也越来越低
响应时间方面 ,16线程时, 关闭流控响应时间却比其他三种流控阈值场景都高, 之后随着并发增大, 可以看到关闭流控后响应时间非常稳定, 而其他三种流控阈值场景响应时间基本在1s左右
对于复制延迟, 随着流控阈值越来越大, 延迟涨幅也越来越大
128线程时qps最高, 接近10W. 有一点值得注意的是即便关了流控, 还是周期性会有一些明显的波谷,
可看到,有短板的场景下, PXC的qps略低于MGR, 但是抖动较小, 当然最平稳的还是关闭流控的MGR
PXC响应时间略高于关闭了流控的MGR
复制延迟方面, 不是PXC性能好, 是PXC流控限制了qps, 所以没延迟
基本和read write差不多了
可能是伪结论
只有在有明显短板时, 关闭了流控的MGR性能优于PXC. 但是在这种情况下关闭流控, 短板节点就不能作为读节点了, 复制延迟越来越大, 优点是不会因为短板而影响整个集群. 而PXC如果遇到短板节点影响了整个集群的节点怎么办呢?只能关闭这个拖后腿的节点了. 当问题解决想要再次重新加入集群时就可能需要做SST
性能方面是上面的情况, 那么对于运维方面呢? 优秀的数据库因当时稳定的, 可控的, 可诊断的. 从这三点来看:
总之, 还需要再多测测.
原始数据和图表自取:
链接:https://pan.baidu.com/s/1WwXjG34uxN-eZG42bwRWXQ 密码:nu0m
老文章了, 如有不正确的地方尽管指出, 共同进步
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/29492784/viewspace-3157394/ ,如需转载,请注明出处,否则将追究法律责任。