连接池大小调优
介绍
我之前写过连接池的好处和为什么监控至关重要两篇文章。这篇文章将讨论如何使用Flexy Pool为你的连接池找到合适的大小。
了解你的连接池
第一步是了解你的连接池设置，我目前开发的程序使用XA事务, 因此我使用Bitronix 事务管理器, 它自带连接池解决方案。
根据Bitronix 连接池文档 我们需要使用以下配置项：
- minPoolSize: 连接池中保留的最小连接数。
- maxPoolSize: 连接池中保留的最大连接数。
- maxIdleTime: 最大空闲时间。
- acquisitionTimeout: 请求超时时间。30秒的默认值远远超出了我们的QoS。
配置 Flexy Pool
Flexy Pool 自带一个默认的度量指标设置，它建立在Coda Hale Metrics之上并提供两种报告机制：
一个企业级的系统必须使用中央监控工具，比如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 提供的故障转移机制也有助于连接池调整优化。
当重试次数达到阀值时就会触发警报，让我们能够尽快介入。
参考:专业的连接池调整优化 摘自 JCG 小伙伴 Vlad Mihalcea 的博客。
原文链接： javacodegeeks 翻译： ImportNew.com - 李 广
译文链接： http://www.importnew.com/12342.html