1.问题描述

XX银行在2012-9-21凌晨出现与Card服务相关的交易缓慢，正常时段的交易时间在1s左右，出现故障的时间段的大多数交易在10s以上甚至达到20s-30s，部分交易超时。

    2.日志分析

2.1.Server日志分析

从局方获得的Card01的Server日志是从<Sep 20, 2012 9:35:52 PM >开始，<Sep 21, 2012 4:56:20 AM >截止，这期间出现下列信息2631次。

此信息提醒连接池"card",达到上限。

此种现象在Card02、Card03、Card04中都存在。

Test "SELECT 1 FROM DUAL"在Card01中第一次出现的时间是2012-9-21 凌晨3:57:53 

此错误是连接池和数据库之间的连接断开，连接池尝试和数据库之间建立连接的测试。日志中其他地方出现的关于Test "SELECT 1 FROM DUAL"的Error信息均为此原因。此时产生的原因是因为数据库服务器重启，连接池和数据库之间的连接断开导致。

Server 重启时间：Sep 21, 2012 4:53:27 AM。

2.2.域日志分析

域日志中的现象同Server日志。

2.3.access.log分析

Access.log中的记录的信息对以上错误信息没有帮助。

3.故障总结

3.1.连接达到上限

产生此现象的原因是：连接池中的连接被耗尽，即连接池里的连接数已不满足生产需要。

3.2.连接池测试和数据库的连接

Test "SELECT 1 FROM DUAL"第一次出现的时间是2012-9-21 凌晨3:57:53 ，此时间点是数据库服务器在做重启的工作，连接池和数据库之间的连接断开，weblogic尝试重新连接数据库的测试，是重启数据库服务器正常的现象。

4.建议

连接达到上限的原因：1.连接泄露

    2.业务量增大，现有连接数不满足业务需求。

4.1.针对连接泄露

根据生产需要，给"Inactive Connection Timeout"（不活跃的连接超时时间）设置一个合适的数值，这个数值是保证不活跃的连接在超过此时间后被强制放回连接池。

4.2.针对业务量增大，连接数不够用

根据生产需要，适当增大"Maximum Capacity的值。

补充：

每当用户请求一个连接时，系统首先检查空闲池内有没有空闲连接。如果有，就把建立时间最长（通过容器的顺序存放实现）的那个连接分配给他（实际是先做连接是否有效的判断，如果可用就分配给用户，如不可用就把这个连接从空闲池删掉，重新检测空闲池是否还有连接）；如果没有则检查当前所开连接池是否达到连接池所允许的最大连接数,如果没有达到，就新建一个连接，如果已经达到，就等待一定的时间（timeout）。如果在等待的时间内有连接被释放出来就可以把这个连接分配给等待的用户，如果等待时间超过预定时间timeout,则返回空值（null）。系统对已经分配出去正在使用的连接只做计数，当使用完后再返还给空闲池。

如果连接池中的连接达到上限，新的请求连接就会等待连接池中出现可用的空闲的连接。即新的请求连接不能及时获得，会等待空闲的可用连接，当获得到可用的连接时才会对请求做处理，这样就会出现请求的连接被延迟处理，导致处理的时间过长。