druid版本_使用arthas解决由于druid版本造成的慢sql问题

故事背景

最近在一个技术交流群里遇到一个小兄弟请求问题，看着平淡无奇的问题，我建议查看mysql-server连接数是否正常，以及当前是否有活跃的慢连接在操作数据库。经过几次确认之后发现并没有什么异常。最后使用阿里开源的神器arthas。网址https://arthas.aliyun.com/doc/ 在我的指导下，小兄弟查看了占用cpu最高的http线程，并通过arthas的trace命令分析到druid的一处代码特别耗时。基本问题已经定位到了，但是怎么解决问题，不仅仅需要技巧还需要点运气，我建议他去github的druid仓库issue下去搜索有没有类似问题。在输入了关键字”loadClass”之后，果真有人遇到了类似问题，也贴出了解决方案。最终在我的指导下，小兄弟问题得到了解决。作为交换，小兄弟答应我给我写一遍完整的故障流程。于是，故事开始…..以下内容来自这位网友的投稿

项目背景

随着业务的扩展，组内的项目越来越多。经常是一个Tomcat里放好将近15个war包。随之而来的是Tomcat严重的宕机事故。痛定思痛之后决定采用Nginx代理解决问题。在部署方案上从原来的Ha代理转变为Ha代理到Nginx，再由Nginx代理到各个服务。其中将业务相关的应用全部独立部署，基础服务暂时保留在Tomcat中。决定了部署方案之后，在灰度环境做了各种测试。均没有发现问题。各种服务独立部署并确定无误之后，将Ha的代理切到Nginx上。随之而来的是部分Java应用接口响应缓慢。接口响应时间平均1.5秒。
部署方案更换的变化点
1.从原来的Tomcat单个端口转变为了多个端口
2.Ha代理从原来直接代理到6台服务器到目前代理到nginx，nginx再做路由转发。
注意：Ha代理是通过Cookie路由，通过Cookie的标志让登录的用户，在登录期间能够始终访问到一台机器。新的部署方案直接抛弃了这种方式，接口路由全部采用权重。
期待
部署方案的改变是为了让服务更稳定。系统的业务部分都是单节点部署，Nginx采用主备。相比之前Tomcat容器中的多线程，目前的多进程应该具有更好的稳定性和输出能力。
问题的发现和解决

1、网络原因？
在业务系统全部切换到Nginx之后，产品经理反映系统缓慢，部分Java系统的业务无法正常进行。
分析：可能是网络问题。
原因：通过F12查看页面的接口和静态资源文件的传输记录。发现很多Js的响应达到了1秒，甚至有的Js脚本的传输花了10秒。但还是比之前慢了很多，但是每晚7点以后网络总是反应较缓慢。对产品经理解释一波之后，已经晚上9点30，大家各回各家。
复盘：真的是网络问题吗？如果是网络问题，那么同机