資料庫連接池到底應該設多大？這篇文章可能會顛覆你的認知

• 2019 年 11 月 28 日
• 筆記

本文轉載自簡書:https://www.jianshu.com/p/a8f653fc0c54?from=singlemessage 作者:Kelgon。其中內容95%譯自這篇文章：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

背景

資料庫連接池大小往往是一個很容易被大家所忽略的參數，通常這個參數也和公司或者組內文化有關係，以前在美團的時候基本所有的項目連接池大小都設置20， 當時也沒有考慮為什麼會這麼設置，反正就跟著大伙兒用。後來來到了猿輔導，發現大家使用的連接池是tomcat-jdbc，並沒有針對連接池大小做特殊配置，使用的是默認的100。

在日常的時候無論設置成20，設置成100對於我們基本感覺不到有什麼差別，但是前段時間對系統進行了打壓，我們明顯發現在一定壓力下資料庫的壓力很大，於是我們對資料庫連接池進行了調整，經過逐漸的減少連接池大小，以及等待時間，發現資料庫連接池減少至20是一個比較合適的值。當然這個值並不適合所有業務，這一塊需要經過各自業務的打壓，根據資訊統計出一個較為合適的值。當然有關資料庫連接池的介紹可以看下面的文章。

接下來是作者原正文

資料庫連接池的配置是開發者們常常搞出坑的地方，在配置資料庫連接池時，有幾個可以說是和直覺背道而馳的原則需要明確。

1萬並發用戶訪問

想像你有一個網站，壓力雖然還沒到Facebook那個級別，但也有個1萬上下的並發訪問——也就是說差不多2萬左右的TPS。那麼這個網站的資料庫連接池應該設置成多大呢？結果可能會讓你驚訝，因為這個問題的正確問法是：

「這個網站的資料庫連接池應該設置成多小呢？」 下面這個影片是Oracle Real World Performance Group發布的，請先看完： http://www.dailymotion.com/video/x2s8uec

（因為這影片是英文解說且沒有字幕，我替大家做一下簡單的概括：） 影片中對Oracle資料庫進行壓力測試，9600並發執行緒進行資料庫操作，每兩次訪問資料庫的操作之間sleep 550ms，一開始設置的中間件執行緒池大小為2048：

初始化配置

壓測跑起來之後是這個樣子的：

2048連接時的性能數據 每個請求要在連接池隊列里等待33ms，獲得連接後執行SQL需要77ms

此時資料庫的等待事件是這個熊樣的：

各種buffer busy waits，資料庫CPU在95%左右（這張圖裡沒截到CPU）

接下來，把中間件連接池減到1024（並發什麼的都不變），性能數據變成了這樣：

獲取鏈接等待時長沒怎麼變，但是執行SQL的耗時減少了。 下面這張圖，上半部分是wait，下半部分是吞吐量

能看到，中間件連接池從2048減半之後，吐吞量沒變，但wait事件減少了一半。

接下來，把資料庫連接池減到96，並發執行緒數仍然是9600不變。

96個連接時的性能數據 隊列平均等待1ms，執行SQL平均耗時2ms。

image.png wait事件幾乎沒了，吞吐量上升。

沒有調整任何其他東西，僅僅只是縮小了中間件層的資料庫連接池，就把請求響應時間從100ms左右縮短到了3ms。

But why?

為什麼nginx只用4個執行緒發揮出的性能就大大超越了100個進程的Apache HTTPD？回想一下電腦科學的基礎知識，答案其實是很明顯的。

即使是單核CPU的電腦也能「同時」運行數百個執行緒。但我們都[應該]知道這只不過是作業系統用時間分片玩的一個小把戲。一顆CPU核心同一時刻只能執行一個執行緒，然後作業系統切換上下文，核心開始執行另一個執行緒的程式碼，以此類推。給定一顆CPU核心，其順序執行A和B永遠比通過時間分片「同時」執行A和B要快，這是一條電腦科學的基本法則。一旦執行緒的數量超過了CPU核心的數量，再增加執行緒數系統就只會更慢，而不是更快。

這幾乎就是真理了……

有限的資源

上面的說法只能說是接近真理，但還並沒有這麼簡單，有一些其他的因素需要加入。當我們尋找資料庫的性能瓶頸時，總是可以將其歸為三類：CPU、磁碟、網路。把記憶體加進來也沒有錯，但比起磁碟和網路，記憶體的頻寬要高出好幾個數量級，所以就先不加了。

如果我們無視磁碟和網路，那麼結論就非常簡單。在一個8核的伺服器上，設定連接/執行緒數為8能夠提供最優的性能，再增加連接數就會因上下文切換的損耗導致性能下降。資料庫通常把數據存儲在磁碟上，磁碟又通常是由一些旋轉著的金屬碟片和一個裝在步進馬達上的讀寫頭組成的。讀/寫頭同一時刻只能出現在一個地方，然後它必須「定址」到另外一個位置來執行另一次讀寫操作。所以就有了定址的耗時，此外還有旋迴耗時，讀寫頭需要等待碟片上的目標數據「旋轉到位」才能進行操作。使用快取當然是能夠提升性能的，但上述原理仍然成立。

在這一時間段（即"I/O等待"）內，執行緒是在「阻塞」著等待磁碟，此時作業系統可以將那個空閑的CPU核心用於服務其他執行緒。所以，由於執行緒總是在I/O上阻塞，我們可以讓執行緒/連接數比CPU核心多一些，這樣能夠在同樣的時間內完成更多的工作。

那麼應該多多少呢？這要取決於磁碟。較新型的SSD不需要定址，也沒有旋轉的碟片。可別想當然地認為「SSD速度更快，所以我們應該增加執行緒數」，恰恰相反，無需定址和沒有旋迴耗時意味著更少的阻塞，所以更少的執行緒[更接近於CPU核心數]會發揮出更高的性能。只有當阻塞創造了更多的執行機會時，更多的執行緒數才能發揮出更好的性能。

網路和磁碟類似。通過乙太網介面讀寫數據時也會形成阻塞，10G頻寬會比1G頻寬的阻塞少一些，1G頻寬又會比100M頻寬的阻塞少一些。不過網路通常是放在第三位考慮的，有些人會在性能計算中忽略它們。

上圖是PostgreSQL的benchmark數據，可以看到TPS增長率從50個連接數開始變緩。在上面Oracle的影片中，他們把連接數從2048降到了96，實際上96都太高了，除非伺服器有16或32顆核心。

計算公式

下面的公式是由PostgreSQL提供的，不過我們認為可以廣泛地應用於大多數資料庫產品。你應該模擬預期的訪問量，並從這一公式開始測試你的應用，尋找最合適的連接數值。

連接數 = ((核心數 * 2) + 有效磁碟數)

核心數不應包含超執行緒(hyper thread)，即使打開了hyperthreading也是。如果活躍數據全部被快取了，那麼有效磁碟數是0，隨著快取命中率的下降，有效磁碟數逐漸趨近於實際的磁碟數。這一公式作用於SSD時的效果如何尚未有分析。

按這個公式，你的4核i7資料庫伺服器的連接池大小應該為((4 * 2) + 1) = 9。取個整就算是是10吧。是不是覺得太小了？跑個性能測試試一下，我們保證它能輕鬆搞定3000用戶以6000TPS的速率並發執行簡單查詢的場景。如果連接池大小超過10，你會看到響應時長開始增加，TPS開始下降。

筆者註： 這一公式其實不僅適用於資料庫連接池的計算，大部分涉及計算和I/O的程式，執行緒數的設置都可以參考這一公式。我之前在對一個使用Netty編寫的消息收發服務進行壓力測試時，最終測出的最佳執行緒數就剛好是CPU核心數的一倍。

公理：你需要一個小連接池，和一個充滿了等待連接的執行緒的隊列

如果你有10000個並發用戶，設置一個10000的連接池基本等於失了智。1000仍然很恐怖。即是100也太多了。你需要一個10來個連接的小連接池，然後讓剩下的業務執行緒都在隊列里等待。連接池中的連接數量應該等於你的資料庫能夠有效同時進行的查詢任務數（通常不會高於2*CPU核心數）。

我們經常見到一些小規模的web應用，應付著大約十來個的並發用戶，卻使用著一個100連接數的連接池。這會對你的資料庫造成極其不必要的負擔。

請注意

連接池的大小最終與系統特性相關。

比如一個混合了長事務和短事務的系統，通常是任何連接池都難以進行調優的。最好的辦法是創建兩個連接池，一個服務於長事務，一個服務於短事務。

再例如一個系統執行一個任務隊列，只允許一定數量的任務同時執行，此時並發任務數應該去適應連接池連接數，而不是反過來。

最後

在實際業務場景中，最佳的鏈接池數量大小最佳通常可能不能簡單使用計算公式，首先是我們資料庫不是只為某台機器提供鏈接，他會為多台機器，多個服務同時提供，所以通過核心數計算可能不是一個很好的方法。最佳的連接池還是需要通過不斷壓測來得到最佳的大小。當然這裡需要注意的是，如果你以前使用了很大的鏈接池，並且使用了大事務(事務裡面有I/O操作)，再你減小了鏈接池大小之後，你需要特別當心，很有可能會觸發鏈接池不足的異常，所以再優化之前需要幹掉你的大事務。

如果大家覺得這篇文章對你有幫助，你的關注和轉發是對我最大的支援，O(∩_∩)O: