数据源连接池优化

来自ling
跳转至: 导航搜索

druid

运行原理:

数据库连接池在初始化的时候会创建initialSize个连接,当有数据库操作时,会从池中取出一个连接。如果当前池中正在使用的连接数等于maxActive,则会等待一段时间,等待其他操作释放掉某一个连接,如果这个等待时间超过了maxWait,则会报错;如果当前正在使用的连接数没有达到maxActive,则判断当前是否空闲连接,如果有则直接使用空闲连接,如果没有则新建立一个连接。在连接使用完毕后,不是将其物理连接关闭,而是将其放入池中等待其他操作复用。 同时连接池内部有机制判断,如果当前的总的连接数少于miniIdle,则会建立新的空闲连接,以保证连接数得到miniIdle。如果当前连接池中某个连接在空闲了timeBetweenEvictionRunsMillis时间后仍然没有使用,则被物理性的关闭掉。有些数据库连接的时候有超时限制(mysql连接在8小时后断开),或者由于网络中断等原因,连接池的连接会出现失效的情况,这时候设置一个testWhileIdle参数为true,可以保证连接池内部定时检测连接的可用性,不可用的连接会被抛弃或者重建,最大情况的保证从连接池中得到的Connection对象是可用的。当然,为了保证绝对的可用性,你也可以使用testOnBorrow为true(即在获取Connection对象时检测其可用性),不过这样会影响性能。

数据源配置

如果使用apache dbcp时,且可能遇到连接数瓶颈时,可以调整如下配置:

<!—建议以下值尽量一样,没必要频繁的过期空闲连接(除非比如连接池资源紧缺,可以考虑) -->
<property name="maxIdle" value="80" />
<property name="minIdle" value="80" />
<property name="initialSize" value="80"/>
<property name="maxActive" value="80" />

<!—这个是等待获取连接池连接时间,也不要太大,比如设置在500毫秒 -->
<property name="maxWait" value="500" />
<property name="removeAbandoned" value="false"></property>
<property name="removeAbandonedTimeout" value="300000"></property>
<property name="minEvictableIdleTimeMillis" value="-1" />
<property name="numTestsPerEvictionRun" value="0" />
<property name="timeBetweenEvictionRunsMillis" value="120000" />
<property name="testWhileIdle" value="false"></property>

如果是mysql库,可能存在8小时问题,可以考虑开启过期定时器(numTestsPerEvictionRun=1),定期过期一下连接,timeBetweenEvictionRunsMillis时间可以设置在8小时左右.

另外可以通过如下配置来配置socket连接/读超时:

<property name="connectionProperties" value="oracle.net.CONNECT_TIMEOUT=2000;oracle.jdbc.ReadTimeout=2000"></property>

(此处的连接和读取超时时间,请根据自己业务来考虑大小)

具体配置请参考:http://www.importnew.com/2466.html

ibatis配置

项目使用的是ibatis-sqlmap-2.3.4.726.jar版本,而从2.3.1起: o Removed maxTransactions, maxRequests, maxSessions from configuration, all are now controlled by the resource providers。(即已经移除了maxTransactions, maxRequests, maxSessions配置)

因此我们只需要如下配置:

<settings cacheModelsEnabled="false" enhancementEnabled="true"
lazyLoadingEnabled="false" errorTracingEnabled="true" maxRequests="32"
defaultStatementTimeout="2"/>

defaultStatementTimeout单位是秒;根据业务配置。

如果想只设置某个Statement的超时时间,可以考虑:<insert ……timeout="2">

之前线上报如下错误,原因就是statement执行超时了。 Cause:java.sql.SQLException:ORA-01013:用户请求取消当前的操作

spring事务管理器配置

提供全局的事务级别的超时时间:

<bean id="oracleTransactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="oracleDataSource" />
  <property name="defaultTimeout" value="2"/>
</bean>

总结:

超时设置主要有以下几个:

  1. 连接超时
  2. 读数据超时
  3. Statement超时
  4. 事务级别的超时=N* Statement超时 + GC 暂停time

之前总结过事务超时的一些问题,有兴趣可以参考下: http://jinnianshilongnian.iteye.com/blog/1986023 http://www.importnew.com/2466.html

另一个数据库连接池需要注意的点:

<bean id="msqlDataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">

如果没有加destroy-method ,而且重启次数太频繁,造成重启tomcat 旧的数据库连接池的连接不释放,这样会有好多数据库连接占着一段时间不释放;所以最好加上destroy-method。 //////////////////////乱七八糟//////////////////////////////////////////////////////////////////////////////////////////////////////////// 当超过最大的连接数目的时候,会删除连接。 if (config != null && config.getRemoveAbandoned() && (getNumIdle() < 2) && (getNumActive() > getMaxActive() - 3) ) {

 removeAbandoned();

} 这段代码的作用是失效孤儿连接,即有人拿到连接但是没有close的。

  • 网络阻塞/不稳定时的级联效应(比如我现在写的ssdb-client 在网络出现故障(网络不可用)时 我会设置一个时间,在这个时间内的请求全部tiemout)

连接池内部应该根据当前网络的状态(比如超时次数太多),对于一定时间内的(如100ms)全部timeout,根本不进行await(maxWait)。 还有一个就是当前等待连接池的人数,比如现在等待1000个,那么接下来的等待是没有意义的,这样还会造成滚雪球(ssdb-client采用了这种策略)。

  • 等待超时应该尽可能小点(除非很必要),即使返回错误页,也比等待强。

dbcp的比较容易出问题的地就是 设置的超时时间太长,造成大量的TIMED_WAIT,线程阻塞,而且是滚雪球,一旦出问题很难立即回复,而且这个可以通过[1]说的解决。

  • 大部分数据库client都会有一个取消statement执行的功能(即假设我们设置QueryTimeout=2秒,如果2秒内没返回信息,那么有个任务会主动发送一个取消的sql去取消当前statement的执行)
  1. mysql每个连接会创建一个Timer(每个Timer会创建一个Thread)
  2. 每创建一个Statement会提交一个TimerTask(每个Task在执行时会创建一个Thread)

也就是说假设我们500个连接池,每个连接执行1个statement,最坏的情况下会创建:

500*1+500*1=1000个线程。

假设一个应用中有三个mysql库,那么最坏情况下有:

1000*3=3000个线程创建。

如果我们数据库采用了分库分表或者读写分离,可想而知。在压力大的时候。

假设os对线程释放不是特别快的话,cancel掉的线程可能并不是立即可用(我不确定,熟悉的同学可解释下)。

  • 而oracle采用不同的策略:
  1. 每个ClassLoader一个watchdog 线程(类似于mysql的timer);
  2. 每个Statement一个Task,而线程是在watchdog需要取消时去触发的,即watchdog发现该Statement需要cancel时,调用其某个方法,该方法快速创建线程并运行;

也就是说假设我们500个连接池,每个连接执行1个statement,最坏的情况下会创建:

1+500*1=501个线程。

假设一个应用中有三个mysql库,那么最坏情况下有:

1 + 500*3=1501个线程创建。

  • 解决方案:
  1. 最好的方案是改mysql实现。
  2. 修改底层系统支持的线程数。

//////////////////////乱七八糟////////////////////////////////////////////////////////////////////////////////////////////////////////////

另外dbcp 1.x使用的是commons-pool 1.x,高并发下性能不是很好;考虑升级2.x或者如果新项目可以考虑使用druid或proxool,老项目还是慎重迁移(之前我迁移过是没有问题的,不过还是慎重)。