连接池大小调优

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

了解你的连接池

第一步是了解你的连接池设置，我目前开发的程序使用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找到合适的连接池大小：

名称	值	描述
minPoolSize	0	连接池启动时最小连接数为0
maxPoolSize	1	连接池启动时最大连接数为1
acquisitionTimeout	1	一个连接请求的超时时间为1秒
maxOverflow	9	最大连接数能增长到10 (初始的 maxPoolSize + maxOverflow)
retryAttempts	30	如果连接池中保留的最大连接数为10并且没有可用的连接, 一个连接请求将会重试30次.

度量指标耗时

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

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，其它设置不变：

名称	值	描述
maxOverflow	4	最大连接数能增长到10 (初始的 maxPoolSize + maxOverflow)

度量指标重载

以下是新的度量指标：

1. concurrentConnectionCount

2. concurrentConnectionRequestCount

3. maxPoolSizeHistogram

4. connectionAcquireMillis

5. retryAttemptsHistogram

6. overallConnectionAcquireMillis

7. connectionLeaseMillis

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

• 连接池保留的最大连接数为5时，重试连接次数不会超过3。
• 从整体连接获取时间的变化可以反映出重试次数变多了。
• 连接的租约时间峰值没多大变化，即便这次它大约是35秒。

结论

即便有意外情况发生，Flexy Pool 提供的故障转移机制也有助于连接池调整优化。
当重试次数达到阀值时就会触发警报，让我们能够尽快介入。