卡顿引起的调查

        也是很倒霉，每次出现问题都是我当值。

        8:33，收到现场反馈：客户端、网页使用体验极差，长时间loading。出现这种问题，在排除硬件设备、网络原因后，无非是应用服务器或数据库原因。

应用服务器接口日志：

       

一个数据库监控页面里面的效果：

        监控图片太多，不一一贴出来了。

        经过检查，当时的数据库sql执行是正常的，没有出现死锁等情况；应用服务器中CPU占有率未达到报警界限。

        由于问题反馈的太突然（30号为第一次出现时间，用户自己内部消化了；31号为用户正式反馈时间，即运维人员进行调查时间），没有开启数据库各执行sql的耗时监控Batch，也不能判断出哪些sql存在问题。

        第二天，开启各监控监管，卡顿情况未发生了。。。

        不过目前怀疑连接池满的原因导致的，反馈时调查，发现很多连接变为空连接，应该是连接池可创建连接为0，剩余请求开始等待，达到最大等待时间抛出异常（emmm...这异常，待商榷！）

        作为一个中间系统，有许多外部系统访问相关接口。可以筛选出这段时间访问的IP，但是可能影响较小、甲方IT人员不重视、相关乙方运维人员不配合，调查仍推进不下去。不过经过用户反馈，那错误已经一周未发生。

        其实我已经相信是外部系统坑我了...问题发生时间都为刚开始上班时间，问题类型都一致，内调结果正常。

        上周六吃夜宵，听一位已离职的同事说：17年发生过这情况，不过经手人是这位同事，他自己偷偷调查蹲守查到。。。

        乙方，难受。