DBCP连接池调优

最近还是在折腾框架的性能调优，前天给mysql加了查询缓存（http://captain.iteye.com/blog/253260），初步见效，无奈今天当数据量到100万以上，400用户并发操作的时候，每次到10分钟左右，tomcat又报错了，还是那天杀的jdbc begin failed，查了无数解决办法，最后定位在数据库连接池和jvm gc回收的冲突上，apache dbcp官方这样解释的

Intermittent dB Connection Failures

    Tomcat runs within a JVM. The JVM periodically performs garbage collection (GC) to remove java objects which are no longer being used. When the JVM performs GC execution of code within Tomcat freezes. If the maximum time configured for establishment of a dB connection is less than the amount of time garbage collection took you can get a db conneciton failure.

    To collect data on how long garbage collection is taking add the -verbose:gc argument to your CATALINA_OPTS environment variable when starting Tomcat. When verbose gc is enabled your $CATALINA_BASE/logs/catalina.out log file will include data for every garbage collection including how long it took.

    When your JVM is tuned correctly 99% of the time a GC will take less than one second. The remainder will only take a few seconds. Rarely, if ever should a GC take more than 10 seconds.

    Make sure that the db connection timeout is set to 10-15 seconds. For the DBCP you set this using the parameter maxWait.

也就是说，连接池等待时间设置得过短，还没热身呢就被gc干掉了，仔细分析了其官方对各个参数的说明：

 <!-- Maximum number of dB connections in pool. Make sure you
         configure your mysqld max_connections large enough to handle
         all of your db connections. Set to 0 for no limit.
         -->
    <parameter>
      <name>maxActive</name>
      <value>100</value>
    </parameter>

    <!-- Maximum number of idle dB connections to retain in pool.
         Set to 0 for no limit.
         -->
    <parameter>
      <name>maxIdle</name>
      <value>30</value>
    </parameter>

    <!-- Maximum time to wait for a dB connection to become available
         in ms, in this example 10 seconds. An Exception is thrown if
         this timeout is exceeded.  Set to -1 to wait indefinitely.
         -->
    <parameter>
      <name>maxWait</name>
      <value>10000</value>
    </parameter>

一怒，直接将maxwait=-1，一直等把，反正资源、硬件啥的绝对没问题，重新跑loadrunner脚本，1小时压力测试，通过，据这个帖子说maxwait过大容易引起连接池泄露（http://swingchen.iteye.com/blog/145088），明天接着优化这参数，好歹有眉目了。