连接池大小调优

Posted 2021-04-06 ImportNew

编译：ImportNew - 李广

介绍

我之前写过《连接池的好处》和《为什么监控至关重要》两篇文章。这篇文章将讨论如何使用Flexy Pool为你的连接池找到合适的大小。

《连接池的好处》

www.javacodegeeks.com/2014/04/the-anatomy-of-connection-pooling.html

《为什么监控至关重要》

www.javacodegeeks.com/2014/04/flexy-pool-reactive-connection-pooling.html

了解你的连接池

第一步是了解你的连接池设置，我目前开发的程序使用XA事务, 因此我使用Bitronix 事务管理器, 它自带连接池解决方案。

根据Bitronix 连接池文档 我们需要使用以下配置项：

• minPoolSize: 连接池中保留的最小连接数。

• maxPoolSize: 连接池中保留的最大连接数。

• maxIdleTime: 最大空闲时间。

• acquisitionTimeout: 请求超时时间。30秒的默认值远远超出了我们的QoS。

配置 Flexy Pool

Flexy Pool 自带一个默认的度量指标设置，它建立在Coda Hale Metrics之上并提供两种报告机制：

• SLF4J

• JMX

一个企业级的系统必须使用中央监控工具，比如Ganglia 和 Graphite。而通过Flexy Pool 使用多种报告机制是相当容易的。我们的示例将导出报告到CSV文件，你可以自定义默认的度量指标设置。

初始化设置

我们把maxOverflow和retryAttempts的值设置得足够大，让Flexy Pool找到合适的连接池大小：

度量指标耗时

我们的程序是一个批量处理器，通过大数据可以得到以下性能指标：

1. concurrentConnectionCount

2. concurrentConnectionRequestCount

3. maxPoolSizeHistogram

4. connectionAcquireMillis

5. retryAttemptsHistogram

6. overallConnectionAcquireMillis

7. connectionLeaseMillis

在分析了各项指标之后，我们可以得到以下结论：

• 最大连接数应该是8。

• 对于这个最大连接数重试次数为0。

• 在连接池保留的最大连接数达到最大值以后，获取连接的时间趋于稳定。

• 当租约时间达到顶峰50秒的时候，连接数从7增长到8，因此降低租约时间可以帮助我们减少连接数。

如果数据库最大连接数是100，那我们可以并发运行12个程序。

接近目标

假设我们需要运行19个程序而不是12个，这意味着连接数最多是5。降低连接数将会增加连接请求争用和潜在的重试次数。

这次我们把maxOverflow改为4，其它设置不变：

度量指标重载

以下是新的度量指标：

1. concurrentConnectionCount

2. concurrentConnectionRequestCount

3. maxPoolSizeHistogram

4. connectionAcquireMillis

5. retryAttemptsHistogram

6. overallConnectionAcquireMillis

7. connectionLeaseMillis

分析这些指标，我们可以得出结论：

• 连接池保留的最大连接数为5时，重试连接次数不会超过3。

• 从整体连接获取时间的变化可以反映出重试次数变多了。

• 连接的租约时间峰值没多大变化，即便这次它大约是35秒。

结论

即便有意外情况发生，Flexy Pool 提供的故障转移机制也有助于连接池调整优化。

当重试次数达到阀值时就会触发警报，让我们能够尽快介入。

参考

• 《 专业的连接池调整优化 》

  http://vladmihalcea.com/2014/04/30/professional-connection-pool-sizing/

看完本文有收获？请转发分享给更多人

关注「ImportNew」，提升Java技能