内容简介:蓝寅,开源分布式中间件DBLE项目负责人;持续专注于数据库方面的技术, 始终在一线从事开发;对数据复制,读写分离,分库分表的有深入的理解与实践。用benchmarksql_for_mysql对原生MyCat-1.6.1和DBLE-2.17.07版做性能测试对比,发现DBLE性能只到原生版MyCat的70%左右。分析过程主要有以下内容:包括现象,收集数据,分析猜测原因,验证猜测的方式来进行。
作者简介
蓝寅,开源分布式中间件DBLE项目负责人;持续专注于数据库方面的技术, 始终在一线从事开发;对数据复制,读写分离,分库分表的有深入的理解与实践。
问题起因:
用benchmarksql_for_mysql对原生MyCat-1.6.1和DBLE-2.17.07版做性能测试对比,发现DBLE性能只到原生版MyCat的70%左右。
问题分析过程:
分析过程主要有以下内容:包括现象,收集数据,分析猜测原因,验证猜测的方式来进行。
开源分布式中间件DBLE:
社区官网,获取DBLE快速入门指南及最新资讯:
https://opensource.actionsky.comGitHub主页,查看官方文档:
https://github.com/actiontech...社区技术交流群,迅速获取官方支持:
QQ群:669663113
**1.分析瓶颈
1.1 先对两者进行一个CPU占用的堆栈分析**
通过对CPU火焰图的比较,发现DBLE用在纯 排序 上的CPU占用在15%以上,而MyCat在排序上没有看到明显的CPU占用。( 复盘时的思考:这里有明显的可疑之处,应当及早观察两者是否公平)
1.2 首先猜测可能的原因
- a.由于MyCat对以下这条用例实现有bug:具体方式是直接原句下发 SQL 到节点,收到各个节点的结果后直接做加法;而DBLE则是改写为select distinct s_i_id 收集全部结果集,然后在中间件做去重和统计的工作。所以两者在这个case上的对比是不公平的。
- b.排序本身算法选择的问题
1.3 对猜测原因的验证
- a.去除有bug的case,并未看到性能有提升,而且考虑这条用例在所有用例出现的概率只有4%,涉及到的数据也不多,所以应该不是性能问题的主因。
- b.去除有排序的case,看到两者性能接近,确定是排序的问题。
2.猜测原因
2.1 猜测一:源码实现原因
2.1.1 猜测描述
梳理DBLE源码排序逻辑的实现细节,是多路归并的排序,理论上是最优选择。
实际上具体的实现上有可优化的空间,如下图, N个数的K路排序的初始化值理论最优复杂度是O(N),而这里变成了O(NlogK2) 。
2.1.2 验证猜测
为了快速将排序的因素排除,将cmp函数直接返回1再次做测试。结果提升了10%的性能,所以虽然cmp是有性能问题,但导致性能如此大还有其他原因。(复盘:新版本已优化此处10%的性能差异)
2.2 猜测二:回到排序SQL
查看B-SQL源码,有3个排序SQL,其中有2个排序SQL的排序列不在select 项中,这本来应该引发MyCat的bug的,但我们在返回集和抓包中都没有发现。再仔细阅读源码,原来B-SQL通过hard code的方式使得压力永远跑不到这两个代码路径上,这样我们又排除了2个干扰因素,问题集中到剩下的那个排序上了。
将排序除去,64数据量,64并发,DBLE的性能是MyCat的96%。
证明确实和排序有关。
3.分析多并发压力排序性能的原因
3.1 猜测 排序算法 在特殊场景下的适用性
3.1.1 猜测描述
由于MyCat排序采用的是timsort, 时间复杂度的可能最优是O(n)。
而DBLE的多路归并排序在B-SQL这个场景下时间复杂度最差情况是O(n*(k-1)).
猜测timSort排序在B-SQL多并发场景下可能会优于多路归并。
3.1.2 验证猜测
用B-SQL压测并统计函数调用次数。
结论:
在B-SQL场景下:
- 两者平均每个排序调用的cmp函数的次数并没有发生明显的异化
- 每个排序cmp次数虽然没有大的差异,但总的调用次数却相差很大,DBLE大约是MyCat的5倍
4. 分析DBLE排序时cmp函数次数调用多的原因
问题集中在了为什么DBLE会有更多次的比较函数调用。
4.1 验证压力下发的SQL是否与cmp函数调用相符是否下发的SQL就不公平
4.1.1收集数据
- 用抓包的方式分别抓取B-SQL发给MyCat和DBLE的包,结果发现 DBLE的所有SQL中排序这条SQL的发生次数是MyCat的10倍左右。
- 再次用yourkit查看调用次数和CPU分布验证,发现调用次数确实符合抓包的结论,CPU分布也是DBLE分了大量的时间用于排序,而MyCat对排序的分配几乎可以忽略。这也与最一开始的火焰图结论一样。
- 用wireshark分析DBLE抓包结果,发现某些连接执行一段时间之后大量的重复出现排序+delete的query请求直到压力结束,举例如下图。
4.1.2 分析原因
分析B-SQL源码这里发现只有delete的数据为0才会引发死循环。
4.1.3 验证测试
在引发死循环的原因找到之前,先修改代码验证测试。无论result是否是0都设置newOrderRemoved=true使得B-SQL跳出死循环。
验证测试,DBLE性能终于符合预期,变为MyCat的105%。
至此,B-SQL有排序引发DBLE性能下降的原因找到了, 某种场景下B-SQL对DBLE执行delete,影响行数为0,导致此时会有死循环,发送了大量排序请求,严重降低了DBLE性能 ,并且并发压力越大越容易出现,但也有一定几率不会触发。
5.分析哪种场景下delete行数为0
5.1隔离级别测试
因为对隔离级别并不熟悉,花了很长时间才想到原因,在 MySQL 上做了一个实验:
也就是说,在并发情况下确实有可能有死循环出现。
5.2 分析为什么只有在DBLE上有这个问题而在MyCat上没有这个问题
原因是DBLE和MyCat的默认隔离级别都是REPEATED_READ, 但MyCat的实现有bug,除非客户端显式使用set语句,MyCat后端连接使用的隔离级别都是下属结点上的默认隔离级别 ;而DBLE会在获取后端连接后同步上下文,使得session级别的隔离级别和DBLE配置相同。而后端的四个结点中除了1台是REPEATED_READ,其他三个结点都是READ_COMMITTED。这样同样的并发条件,DBLE100%会触发,而MyCat只有25%的概率触发。
5.3 验证测试
将DBLE上的配置添加
性能比是1:0.75.符合期望,性能原因全部找到。
6. 吐槽
最后吐槽一下B-SQL,找了官方的B-SQL4.1版和5.0版,4.1版并未对此情况做任何改进,仍有可能陷入死循环影响测试。
而5.0的对应代码处有这么一段注释,不知道PGSQL是否这里真的会触发异常,但MySQL并不会触发异常,仍有可能陷入死循环。
7.性能原因回顾
1.cmp函数时候初始化值的问题,影响部分性能,非主要性能瓶颈,新版本已改进。
2.同时触发了MyCat和B-SQL的两个bug,导致测试的性能数据负负得正;
- Mycat bug:配置的隔离级别不生效问题
- B-SQL bug:RR隔离级别下,delete死循环问题
需要将MySQL结点都改为READ_COMMITED,再将配置改为
8.收获
1.测试环境的搭建无论是配置参数还是各个节点的状态都要同步,保证公平。
2.性能分析 工具 的使用。
3.性能测试可能一次的结果具有偶然性,需要多次验证。
4.当有矛盾的结论时候,可能就快接近问题的真相了,需要持续关注。
开源分布式中间件DBLE
- 社区官网: https://opensource.actionsky....
- GitHub主页: https://github.com/actiontech...
- 技术交流群:669663113
开源数据传输中间件DTLE
- 社区官网: https://opensource.actionsky....
- GitHub主页: https://github.com/actiontech...
- 技术交流群:852990221
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 【深度好文】深度分析如何获取方法参数名
- 司法鉴定牵手深度学习:Kaggle 相机型号识别大赛深度分析
- 深度分析ConcurrentHashMap原理分析
- Redis GEO & 实现原理深度分析
- 针对越南APT攻击样本深度分析
- 趋势分析之深度学习
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
我的第一本编程书
[日]平山尚 / 张沈宇 / 人民邮电出版社 / 2016-7 / 79.00元
写这本书之前,作者一直在摸索一种最有利于入门者学编程的方法,并应用到教学当中。经过两年的教学实践,他确信他的方法是有效的,于是便有了这本书。这本书面向的是完全没有接触过编程的读者。作者将门槛设置得非常低,读者不需要懂得变量、函数这些名词(这些名词在书中也不会出现),不需要会英语,完全不需要查阅其他书籍,只需要小学算术水平即可。这本书给初学者非常平缓的学习曲线,有利于为之后的进阶学习打下坚实的基础。一起来看看 《我的第一本编程书》 这本书的介绍吧!