技術經理：求求你，別再亂改數據庫鏈接池的大小了！

文章翻譯整理自: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

歡迎關注我的微信公衆號: 小哈學Java, 文末分享阿里 P8 高級架構師吐血總結的 《Java 核心知識整理&面試.pdf》資源連接！！

我的網站: https://www.exception.site/essay/how-to-set-the-size-of-database-connection-pool

目錄

• 1、筆者前言
• 2、正菜開始
• 3、假設你的服務有1萬併發的訪問
• 4、爲啥有這種效果?
• 5、其餘應該考慮到的因素
• 6、鏈接數計算公式
• 7、結論：你須要的是一個小鏈接池，和一個等待鏈接的線程隊列
• 8、額外須要注意的點

1、筆者前言

基本上來講，大部分項目都須要跟數據庫作交互，那麼，數據庫鏈接池的大小設置成多大合適呢？

一些開發老鳥可能還會告訴你：不要緊，儘可能設置的大些，好比設置成 200，這樣數據庫性能會高些，吞吐量也會大些！

你也許會點頭稱是，真的是這樣嗎？看完這篇文章，也許會顛覆你的認知哦！

2、正菜開始

能夠很直接的說，關於數據庫鏈接池大小的設置，每一個開發者均可能在一環節掉進坑裏，事實上呢，大部分程序員可能都會依靠本身的直覺去設置它的大小，設置成 100 ？思量許久後，自顧自想，應該差很少吧？

3、假設你的服務有1萬併發的訪問

不妨意淫一下，你手裏有個網站，併發壓力雖然還沒到 Facebook 那個級別，可是呢？也有個1萬上下的併發量！也就是說差很少2萬左右的 TPS。

那麼問題來了！這個網站的數據庫鏈接池應該設置成多大合適呢？

其實這個問法自己就是有問題的，咱們須要反過來問，正確問法應該是：

「這個網站的數據庫鏈接池應該設置成多小合適呢？」

PS: 這裏有一個 Oracle 性能小組發佈的簡短視頻，連接地址爲 http://www.dailymotion.com/video/x2s8uec

口述一下，視頻中對 Oracle 數據庫進行了壓力測試，模擬 9600 個併發線程來操做數據庫，每兩次數據庫操做之間 sleep 550ms，注意，視頻中剛開始設置的線程池大小爲 2048。

讓咱們來看看數據庫鏈接池的大小爲 2048 性能測試結果的鬼樣子：

每一個請求要在鏈接池隊列裏等待 33ms，得到鏈接以後，執行SQL須要耗時77ms, CPU 消耗維持在 95% 左右；

接下來，咱們將鏈接池的大小改小點，設置成 1024，其餘測試參數不變，結果咋樣？

"這裏，獲取鏈接等待時長基本不變，可是 SQL 的執行耗時下降了！"

哎呦，有長進哦！

接下來，咱們再設置小些，鏈接池的大小下降到 96，併發數等其餘參數不變，看看結果如何：

每一個請求在鏈接池隊列中的平均等待時間爲 1ms, SQL 執行耗時爲 2ms.

我去！什麼鬼？

咱們沒調整任何東西，僅僅只是將數據庫鏈接池的大小下降了，這樣，就能把以前平均 100ms 響應時間縮短到了 3ms。吞吐量指數級上升啊！

你這也太溜了！

4、爲啥有這種效果?

咱們不妨想一下，爲啥 Nginx 內部僅僅使用了 4 個線程，其性能就大大超越了 100 個進程的 Apache HTTPD 呢？追究其緣由的話，回想一下計算機科學的基礎知識，答案其實很是明顯。

要知道，即便是單核 CPU 的計算機也能「同時」運行着數百個線程。但咱們其實都知道，這只不過是操做系統快速切換時間片，跟咱們玩的一個小把戲罷了。

一核 CPU同一時刻只能執行一個線程，而後操做系統切換上下文，CPU 核心快速調度，執行另外一個線程的代碼，不停反覆，給咱們形成了全部進程同時運行假象。

其實，在一核 CPU 的機器上，順序執行A和B永遠比經過時間分片切換「同時」執行A和B要快，其中緣由，學過操做系統這門課程的童鞋應該很清楚。一旦線程的數量超過了 CPU 核心的數量，再增長線程數系統就只會更慢，而不是更快，由於這裏涉及到上下文切換耗費的額外的性能。

說到這裏，你應該恍然大悟了 ……

5、其餘應該考慮到的因素

上小節中說到了主要緣由，但其實沒有這麼簡單，咱們還須要考慮到一些其餘的因素。

當咱們在尋找數據庫的性能瓶頸時，大體可歸爲三類：

• CPU
• 磁盤 IO
• 網絡 IO

也許你會說，還有內存這一因素？內存的確是須要考慮的，可是比起磁盤IO和網絡IO，稍顯微不足道，這裏就不加了。

假設咱們不考慮磁盤 IO 和網絡 IO，就很好定論了，在一個 8 核的服務器上，數據庫鏈接數/線程數設置爲 8 可以提供最優的性能，若是再增長鏈接數，反而會由於上下文切換致使性能降低。

你們都知道，數據庫一般把數據存儲在磁盤上，而磁盤呢，一般是由一些旋轉着的金屬碟片和一個裝在步進馬達上的讀寫頭組成的。讀/寫頭同一時刻只能出如今一個位置，當它須要再次執行讀寫操做時，它必須「尋址」到另一個位置才能完成任務。因此呢？這裏就有了尋址的耗時，此外還有旋轉耗時，讀寫頭須要等待磁盤碟片上的目標數據「旋轉到位」才能進行讀寫操做。使用緩存固然是可以提高性能的，但上述原理仍然適用。

在這段（"I/O等待"）時間內，線程是處於「阻塞」等待狀態，也就是說沒幹啥正事！此時操做系統能夠將這個空閒的CPU 核心用於服務其餘線程。

這裏咱們能夠總結一下，當你的線程處理的是 I/O 密集型業務時，即可以讓線程/鏈接數設置的比 CPU核心大一些，這樣就可以在一樣的時間內，完成更多的工做，提高吞吐量。

那麼問題又來了？

大小設置成多少合適呢？

這要取決於磁盤，若是你使用的是 SSD 固態硬盤，它不須要尋址，也不須要旋轉碟片。打住打住！！！你千萬可別理所固然的認爲：「既然SSD速度更快，咱們把線程數的大小設置的大些吧！！」

結論正好相反！無需尋址和沒有旋迴耗時的確意味着更少的阻塞，因此更少的線程（更接近於CPU核心數）會發揮出更高的性能。只有當阻塞密集時，更多的線程數才能發揮出更好的性能。

上面咱們已經說過了磁盤 IO, 接下來咱們談談網絡 IO！

網絡 IO 其實也是很是類似的。經過以太網接口讀寫數據時也會形成阻塞，10G帶寬會比1G帶寬的阻塞耗時少一些，而 1G 帶寬又會比 100M 帶寬的阻塞少一些。一般狀況下，咱們把網絡 IO 放在第三順位來考慮，然而有些人會在性能計算中忽略網絡 IO 帶來的影響。

上圖是 PostgreSQL 的基準性能測試數據，從圖中咱們能夠看到，TPS 在鏈接數達到 50 時開始變緩。回過頭來想下，在上面 Oracle 的性能測試視頻中，測試人員們將鏈接數從 2048 降到了 96，實際上 96 仍是過高了，除非你的服務器 CPU 核心數有 16 或 32。

6、鏈接數計算公式

下面公式由 PostgreSQL 提供，不過底層原理是不變的，它適用於市面上絕大部分數據庫產品。還有，你應該模擬預期的訪問量，並經過下面的公式先設置一個偏合理的值，而後在實際的測試中，經過微調，來尋找最合適的鏈接數大小。

鏈接數 = ((核心數 * 2) + 有效磁盤數)

核心數不該包含超線程(hyper thread)，即便打開了超線程也是如此，若是熱點數據全被緩存了，那麼有效磁盤數實際是0，隨着緩存命中率的降低，有效磁盤數也逐漸趨近於實際的磁盤數。另外須要注意，這一公式做用於SSD 的效果如何，還沒有明瞭。

好了，按照這個公式，若是說你的服務器 CPU 是 4核 i7 的，鏈接池大小應該爲 ((4 * 2) + 1) = 9。

取個整, 咱們就設置爲 10 吧。你這個行不行啊？10 也過小了吧！

你要是以爲不太行的話，能夠跑個性能測試看看，咱們能夠保證，它能輕鬆支撐 3000 用戶以 6000 TPS 的速率併發執行簡單查詢的場景。你還能夠將鏈接池大小超過 10，那時，你會看到響應時長開始增長，TPS 開始降低。

7、結論：你須要的是一個小鏈接池，和一個等待鏈接的線程隊列

假設說你有 10000 個併發訪問，而你設置了鏈接池大小爲 10000，你怕是石樂志哦。

改爲 1000，過高？改爲 100？仍是太多了。

你僅僅須要一個大小爲 10 數據庫鏈接池，而後讓剩下的業務線程都在隊列裏等待就能夠了。

鏈接池中的鏈接數量大小應該設置成：數據庫可以有效同時進行的查詢任務數（一般狀況下來講不會高於 2*CPU核心數）。

你應該常常會看到一些用戶量不是很大的 web 應用中，爲應付大約十來個的併發，卻將數據庫鏈接池設置成 100， 200 的狀況。請不要過分配置您的數據庫鏈接池的大小。

8、額外須要注意的點

實際上，鏈接池的大小的設置仍是要結合實際的業務場景來講事。

好比說，你的系統同時混合了長事務和短事務，這時，根據上面的公式來計算就很難辦了。正確的作法應該是建立兩個鏈接池，一個服務於長事務，一個服務於"實時"查詢，也就是短事務。

還有一種狀況，比方說一個系統執行一個任務隊列，業務上要求同一時間內只容許執行必定數量的任務，這時，咱們就應該讓併發任務數去適配鏈接池鏈接數，而不是鏈接數大小去適配併發任務數。

Ref

https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

免費分享 | 面試&學習福利資源

最近在網上發現一個不錯的 PDF 資源《Java 核心知識&面試.pdf》分享給你們，不光是面試，學習，你都值得擁有！！！

獲取方式: 關注公衆號: 小哈學Java, 後臺回覆資源，既可免費無套路獲取資源連接，下面是目錄以及部分截圖：

重要的事情說兩遍，關注公衆號: 小哈學Java, 後臺回覆資源，既可免費無套路獲取資源連接 ！！！

歡迎關注微信公衆號: 小哈學Java