連接池大小調優
介紹
我之前寫過連接池的好處和為什么監控至關重要兩篇文章。這篇文章將討論如何使用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