BUG作者:许晓

Bug标题:Dubbo超时机制导致的雪崩连接

Bug影响:Dubbo服务提供者出现无法获取Dubbo服务处理线程异常,后端DB爆出拿不到数据库连接池,导致前端响应时间异常飙高,系统处理能力下降,核心基础服务无法提供正常服务。

Bug发现过程:

线 上,对于高并发的服务化接口应用,时常会出现Dubbo连接池爆满情况,通常,我们理所应当的认为,这是客户端并发连接过高所致,一方面调整连接池大小, 一方面考虑去增加服务接口的机器,当然也会考虑去优化服务接口的应用。很自然的,当我们在线上压测一个营销页面(为大促服务,具备高并发)时,我们遇到了 这种情况。而通过不断的深入研究,我发现了一个特别的情况。

场景描述:

alt

 

压力从Jmeter压至前端web应用marketingfront,场景是批量获取30个产品的信息。wsproductreadserver有一个批量接口,会循环从tair中获取产品信息,若缓存不存在,则命中db。

压测后有两个现象:

1)Dubbo的服务端爆出大量连接拿不到的异常,还伴随着无法获取数据库连接池的情况

​​​​alt

2)Dubbo Consumer端有大量的Dubbo超时和重试的异常,且重试3次后,均失败。

3)Dubbo Consumer端的最大并发时91个

alt

Dubbo Provider端的最大并发却是600个,而服务端配置的dubbo最大线程数即为600。alt

这个时候,出于性能测试的警觉性,发现这两个并发数极为不妥。

按照正常的请求模式,DubboConsumer和DubboProvider展示出来的并发应该是一致的。此处为何会出现服务端的并发数被放大6倍,甚至有可能不止6倍,因为服务端的dubbo连接数限制就是600。

此处开始发挥性能测试各种大胆猜想:

1)是否是因为服务端再dubboServerHandle处理请求时,开启了多线程,而这块儿的多线程会累计到Dubbo的连接上,dragoon采集的这个数据可以真实的反应目前应用活动的线程对系统的压力情况;

2)压测环境不纯洁?我的小伙伴们在偷偷和我一起压测?(这个被我生生排除了,性能测试基本环境还是要保持独立性)

3)是否是因为超时所致?这里超时会重试3次,那么顺其自然的想,并发有可能最多会被放大到3倍,3*91=273<<600….还是不止3倍?

有了猜想,就得小心求证!

首先通过和dubbo开发人员