转载

一次tomcat连接池配置引发的DB高CPU故障小记

早上来之后，发现一台DB的CPU变得很高，Alert不断报连接错误，很快连plsqldev客户端也连不上了，无监听器服务了；
从sqlplus上做了一个AWR，load与Db_time这一个小时内变得很高,CPU73%是在sys端，us端很小，没有发现很耗时的SQL，Time modal下，主要是DB_CPU，conn管理其次，但比例却不高；
总而言之，问题应该就是因为客户端不断地发起连接，导致CPU都用在连接创建了；
但是，从v$session上只能查到目前已经连上DB的app server,netstat也是，却不好定位到哪几台机器在不停地发起连接，这可能需要tcpdump了，但这个操作不熟，tool到用时发现不熟，没招；
好了应用端有了发现，昨晚新切的几台tomcat的validationQuery发现设置为"select 1",这个明显是不适用于oracle的，一看到这个，心里基本上有了底，这个是校验连接是否存活的检测，估计当客户端申请连接时，连接池会用这个SQL去查现有的连接是否可用，但运行这个SQL肯定会收不到正确的结果，所以就认为不可用，从而发起新的连接，为什么上线后验证不能发现？应该是验证时连接数少，初始化的10个就够用了，也就没有暴露问题，而今天早上，大量用户上来了，申请大量的连接，而这个错误导致无法重用现有的连接，只有不断地创建；
更改后，重启各应用服务器，很快就不再报连接错误了；问题确实是这个问题，而原因也定位是应用管理员直接拷贝配置文件，结果拷错了，源头应该来源于MYSQL的配置；
通过这个故障，有好几个地方需要总结与加强的：
1、是配置文件的校验与检查，这个自动化工具是很容易做到的，不能太相信运维人员的手工操作；
2、这个问题的定位或许可以更快速与准确，因为这种解析错误的SQL，是可以从v$kglob、10035事件、或systemstate dump中找到的，所以，加强这几个操作的熟练程度，是有助于提升定位速度的；
在这个问题上，tcpdump估计也不好使，抓出来的可能都是正常的连接，恐怕也发现不了这种连接的规律；

总之，很有感触的两点是：要加强工具的熟练程度，以便在出问题时能快速使用；二是校验胜于救火，预防方为上策啊；

正文到此结束