c mysql maxpoolsize_记一次 druid maxPoolSize(maxActive) 配置引起的线上事故

本文记录了一次由于Druid连接池maxPoolSize配置过小导致的线上事故。当设置为10时,大量线程被挂起,服务器性能未充分利用。通过分析线程日志,发现问题集中在数据库连接。调整maxPoolSize为2000后,大部分线程转为RUNNABLE状态,但服务器承载能力成为新的关注点。
摘要由CSDN通过智能技术生成

同事打电话说服务器崩溃了

无法访问、卡死,但是硬件没有问题,cpu在低位,内存、网络也都在正常范围内,Tomcat没有挂掉

回家、打印线程日志,重启系统,暂时先用着,问题其实还在

---> 打印JVM日志命令 (jstack -l $pid > jstack.log)

开始分析线程日志

---> 统计命令(cat jstack.log | grep "java.lang.Thread.State" | sort -nr | uniq -c)

发现大量被挂起的线程

3e17bd419ce7a82bf41d87daae33b4e4.png

一般出现 TIMED_WAITING(parking)是因为调用第三方资源等待响应,导致的线程被挂起

比如:Http请求、RPC请求、中间件(redis、memcached、MQ)长时间等待,占用线程,导致系统卡死无法访问

结合当时正在直播课程、首先怀疑的就是HTTP

然而并没有相关的痕迹,调用链里没有出现http相关的

通过搜索发现、问题集中在获取课程小结,网站配置(业务相关)

·

9f4e2d398845de56f58bee12bc585053.png

导致挂起的位置,基本上都在是连接memcached

于是就怀疑是memcached,但是也不对,如果是memcached长时间无响应,会提示拒绝连接。

继续往上看

8ad763b4453830e45a38a990165f0446.png

druid?

这段报错其实从眼皮底下溜过去很多次,感觉不太可能是druid,不够特殊吧,所有的数据库查询,底端调用肯定是druid连接池,

嗯。。。还是检查一下吧

赫然发现,

maxPoolSize=10

好像找到原因了,验证一下

ad6a489ca0a62a754e6f725a3f03cd9f.png

关掉cc防御

10000个请求发过去

看一下服务器线程

f81344ec1a89d27c3eb662e74fdb41d5.png

挂起了3200

改掉   maxPoolSize =2000

08f9f45bb2e0da895ff54f23851722d0.png

绝大多数都在RUNNABLE了

看一下服务器,内存CPU也上来了

过一阵在看看

2d6fa88828dc7f37e215a44e61a621a9.png

又500多个线程被挂起

但是这是另外一件事情了,服务器承载能力的问题了

结束

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值