连接池大小调优

介绍

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

了解你的连接池

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

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

  • minPoolSize: 连接池中保留的最小连接数。
  • maxPoolSize: 连接池中保留的最大连接数。
  • maxIdleTime: 最大空闲时间。
  • acquisitionTimeout: 请求超时时间。30秒的默认值远远超出了我们的QoS

配置 Flexy Pool

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

一个企业级的系统必须使用中央监控工具,比如GangliaGraphite。而通过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
[ 转载请保留原文出处、译者和译文链接。]

关于作者: 李 广

(新浪微博:@genslow

查看李 广的更多文章 >>



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部