NonRegisteringDriver导致频繁fullgc引发的思考
1:HikariCP的连接池配置应该怎么配
先贴上配置说明https://github.com/brettwooldridge/HikariCP
| 参数 | 描述 | 默认值 | 其他 |
|---|---|---|---|
| autoCommit | 自动提交从池中返回的连接 | true | - |
| connectionTimeout | 等待来自池的连接的最大毫秒数 | 30000 | 如果小于250毫秒，则被重置回30秒 |
| idleTimeout | 连接允许在池中闲置的最长时间 | 600000 | 如果idleTimeout+1秒>maxLifetime 且 maxLifetime>0，则会被重置为0（代表永远不会退出）；如果idleTimeout!=0且小于10秒，则会被重置为10秒 |
| maxLifetime | 池中连接最长生命周期 | 1800000 | 如果不等于0且小于30秒则会被重置回30分钟 |
| connectionTestQuery | 如果您的驱动程序支持JDBC4，我们强烈建议您不要设置此属性 | null | - |
| minimumIdle | 池中维护的最小空闲连接数 | 10 | minIdle<0或者minIdle>maxPoolSize,则被重置为maxPoolSize |
| maximumPoolSize | 池中最大连接数，包括闲置和使用中的连接 | 10 | 如果maxPoolSize小于1，则会被重置。当minIdle<=0被重置为DEFAULT_POOL_SIZE则为10;如果minIdle>0则重置为minIdle的值 |
| metricRegistry | 该属性允许您指定一个 Codahale / Dropwizard MetricRegistry 的实例，供池使用以记录各种指标 |
null | - |
| healthCheckRegistry | 该属性允许您指定池使用的Codahale / Dropwizard HealthCheckRegistry的实例来报告当前健康信息 | null | - |
| poolName | 连接池的用户定义名称，主要出现在日志记录和JMX管理控制台中以识别池和池配置 | HikariPool-1 | - |
| initializationFailTimeout | 如果池无法成功初始化连接，则此属性控制池是否将 fail fast |
1 | - |
| isolateInternalQueries | 是否在其自己的事务中隔离内部池查询，例如连接活动测试 | false | - |
| allowPoolSuspension | 控制池是否可以通过JMX暂停和恢复 | false | - |
| readOnly | 从池中获取的连接是否默认处于只读模式 | false | - |
| registerMbeans | 是否注册JMX管理Bean（MBeans） |
false | - |
| catalog | 为支持 catalog 概念的数据库设置默认 catalog |
null | - |
| connectionInitSql | 该属性设置一个SQL语句，在将每个新连接创建后，将其添加到池中之前执行该语句。 | null | - |
| driverClassName | HikariCP将尝试通过仅基于jdbcUrl的DriverManager解析驱动程序，但对于一些较旧的驱动程序，还必须指定driverClassName | null | - |
| transactionIsolation | 控制从池返回的连接的默认事务隔离级别 | null | - |
| validationTimeout | 连接将被测试活动的最大时间量 | 5000 | 如果小于250毫秒，则会被重置回5秒 |
| leakDetectionThreshold | 记录消息之前连接可能离开池的时间量，表示可能的连接泄漏 | 0 | 如果大于0且不是单元测试，则进一步判断：(leakDetectionThreshold < SECONDS.toMillis(2) or (leakDetectionThreshold > maxLifetime && maxLifetime > 0)，会被重置为0 . 即如果要生效则必须>0，而且不能小于2秒，而且当maxLifetime > 0时不能大于maxLifetime |
| dataSource | 这个属性允许你直接设置数据源的实例被池包装，而不是让HikariCP通过反射来构造它 | null | - |
| schema | 该属性为支持模式概念的数据库设置默认模式 | null | - |
| threadFactory | 此属性允许您设置将用于创建池使用的所有线程的java.util.concurrent.ThreadFactory的实例。 | null | - |
| scheduledExecutor | 此属性允许您设置将用于各种内部计划任务的java.util.concurrent.ScheduledExecutorService实例 | null | - |
核心配置如下
idleTimeout
maxLifetime
minimumIdle
maximumPoolSize
默认情况下maximumPoolSize=minimumIdle=10,在这种情况下idleTimeout失效,以maxLifetime作为连接数最长时间
我在一切参数是默认的情况下启动项目空跑了一个小时,4次fullgc
将maxLifetime参数改为31000跑了一个小时同样也是4次fullgc
其实频繁fullgc无非就是因为old区域满了
而在我这次的实际例子中因为线程数被我们无脑的调大到了500,10分钟后在多次ygc后进入老年代,在没改jvm默认配置的情况下老年代就撑不住了(10分钟一次*48小时=480次,接近于jstat360次的统计,因为我们系统半夜是停机的,估计就没那么的ygc了)
目前解决办法:
1.提升jvm内存数
java -server -Xms2g -Xmx2g
2.
maximumPoolSize =30 minimumIdle=9 连接数=（（core_count * 2）+ Effective_spindle_count） 参考https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing idleTimeout=6000 空闲时间设置短一点,让多余空闲连接在ygc直接释放掉
附上上面英文文章的翻译
https://blog.csdn.net/zzzgd_666/article/details/82842839
一句很重点的话:
一个混合了长事务和短事务的系统，通常是任何连接池都难以进行调优的。最好的办法是创建两个连接池，一个服务于长事务，一个服务于短事务
3.其他参数默认不变
至于手动调用system.gc这个解决办法纯粹就是瞎扯淡,system.gc会导致fullgc,本来我们要解决的目的就是减少fullgc的次数,结果为了解决这个问题反而加大fullgc的次数,岂不是本末倒置么
补充:
当初我们调大连接数的目的是因为很多慢查询导致连接数被完全占用
现在看来可以还可以通过以下两个方式解决(为实践)
SQL 执行超时时间 JDBC 可以直接使用 Statement.setQueryTimeout Spring 可以使用 @Transactional(timeout=10)
