Long Long 前
这个故事,并没有童话故事里王子和公主幸福的各种浪。那么就随我,揭示故事发生的原因。
事情的起因:
某项目的开发同学突然要求我们从28800年代
应用端测试环境的
恩。报错很明显。这个问题百度后的解决方案大部分都是要求数据库端更改连接等待超时时间。那么这种解决方法是否可行呢?
遗憾的是,这是不可行的。
主要原因还是性能考量.Wait_timeout
在高并发场景中,由于我们的连接数已经封顶,过长的
所以为了避免出现这种情况,
既然不允许更改数据库参数,但是问题还在,那么如何定位问题的真正原因呢?这里我将根据我在处理这个问题时的思路,引导大家掌握基本的排障方法。
问题定位:
连接出现问题,那么肯定要涉及到两个主要的部分:数据库和
1只,是否使用了连接池?如果不是,是否有在代码里显式关闭连接吗?
2只连接池是否配置了连接自动回收机制(如
开发同学给出的答案是:
1只确实使用了连接池(
2只经过和运维相关同学协调,发现
解决方案:
好吧
Tomcat 1只;
2只如果上述方法不能解决,那么可以尝试更换
3只如果更换
