内容简介:上周末做了活动期间大量的限流告警提示。于是拜托运维大神先添加机器,暂时顶住压力。扩容一波增加了一些机器。然后,然后就看到了更多的接口响应超时告警。what ? 线程池耗尽。
上周末做了活动期间大量的限流告警提示。于是拜托运维大神先添加机器,暂时顶住压力。扩容一波增加了一些机器。然后,然后就看到了更多的接口响应超时告警。
2019-06-22 23:32:07,957 WARN [New I/O server worker #1-9] com.alibaba.dubbo.common.threadpool.support.AbortPolicyWithReport:warn:54 [DUBBO] Thread pool is EXHAUSTED! Thread Name: DubboServerHandler-172.***:62075, Pool Size: 200 (active: 200, core: 200, max: 200, largest: 200), Task: 771 (completed: 571), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://172.***:62075!, dubbo version: 2.5.3, current host: 172.16.6.3
Thread pool is EXHAUSTED!
问题排查
what ? 线程池耗尽。
1.客户端调用重试次数太多?
检查发现所有请求设置的重试次数都为0.
2.接口响应超时时间设置的过长?
单次请求超时时间3s.
3.是不是有线程阻塞?
打开 Arthas。
thread -b
thread
发现所有的SimpleAsyncTaskExecutor全部都是阻塞状态。那么它们在做什么呢?
插曲
运维重启了服务之后SimpleAsyncTaskExecutor 线程逐渐变成阻塞状态。(刚刚是全部为阻塞)
继续查看其中一个
thread 378
owned by DubboServerHandler 继续往下看
thread 146
整理一下,目前的结论是并非死锁,是数据库查询这里出了异常。奇怪,如果数据库有问题别的同类 服务为什么没有告警?
请运维大神排查,果然应用于数据库不在同一个网段,没有添加到ip白名单。
结论
扩容忽略了数据库链接。设置白名单问题修复。
思考
按照上面的排查看是与数据库连接出了问题,那这些跟Dubbo的dispatcher策略有没有关系呢? 网上搜索到了解决方案:(没有验证) 修改dubbo provider的dispatcher策略,设置为message
<dubbo:protocol name=“dubbo” port=“8888” threads=“500” dispatcher=“message” />
dispatcher默认为all,所有的请求,均会分发给业务线程池处理。 dubbo默认的业务线程池大小是200,等待队列长度为0, 当线程池全部满了之后,后续的请求会丢弃。 但丢弃的请求也会交给业务线程池处理, 此时可能出现服务端已拒绝,但consumer一直在等待,直到超时
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 内存耗尽后 Redis 会发生什么?
- mysql自动增量主键耗尽
- 全球IPv4地址正式耗尽!
- 多线程Django程序耗尽数据库连接的问题
- 全球 IPv4 地址耗尽,IPv6 来了
- EF Core 小坑:DbContextPool 会引起数据库连接池连接耗尽
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Android编程权威指南
[美] Bill Phillips、[美] Brian Hardy / 王明发 / 人民邮电出版社 / 2014-4 / CNY 99.00元
权威、全面、实用、易懂,是本书最大的特色。本书根据美国大名鼎鼎的Big Nerd Ranch训练营的Android培训讲义编写而成,已经为微软、谷歌、Facebook等行业巨头培养了众多专业人才。作者巧妙地把Android开发所需的庞杂知识、行业实践、编程规范等融入一本书中,通过精心编排的应用示例、循序渐进的内容组织,以及循循善诱的语言,深入地讲解了Android开发的方方面面。如果学完一章之后仍......一起来看看 《Android编程权威指南》 这本书的介绍吧!