資料庫連線池 隨筆

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

1萬併發使用者訪問，想象你有乙個**，壓力雖然還沒到facebook那個級別，但也有個1萬上下的併發訪問——也就是說差不多2萬左右的tps。那麼這個**的資料庫連線池應該設定成多大呢？結果可能會讓你驚訝，因為這個問題的正確問法是：

「這個**的資料庫連線池應該設定成多小呢？」

初始的配置

2048連線時的效能資料

每個請求要在連線池佇列裡等待33ms，獲得連線後執行sql需要77ms

接下來，把中介軟體連線池減到1024（併發什麼的都不變），連線池降到1024後獲取鏈結等待時長沒怎麼變，但是執行sql的耗時減少了。

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

96個連線時的效能資料

佇列平均等待1ms，執行sql平均耗時2ms。wait事件幾乎沒了，吞吐量上公升。

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

為什麼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提供的，不過我們認為可以廣泛地應用於大多數資料庫產品。你應該模擬預期的訪問量，並從這一公式開始測試你的應用，尋找最合適的連線數值。

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

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

注：這一公式其實不僅適用於資料庫連線池的計算，大部分涉及計算和i/o的程式，執行緒數的設定都可以參考這一公式。我之前在對乙個使用netty編寫的訊息收發服務進行壓力測試時，最終測出的最佳執行緒數就剛好是cpu核心數的一倍。

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

請注意連線池的大小最終與系統特性相關。

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

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

資料庫連線池配置隨筆

資料庫連線池 Redis連線池

基本原理 在內部物件池中，維護一定數量的資料庫連線，並對外暴露資料庫連線的獲取和返回方法。如外部使用者可通過getconnection方法獲取資料庫連線，使用完畢後再通過releaseconnection方法將連線返回，注意此時的連線並沒有關閉，而是由連線池管理器 並為下一次使用做好準備。2.作用 ...

資料庫連線池

實現資料連線池,讓系統有更高有執行效率 using system using system.data using system.data.sqlclient using system.collections using system.threading public class dataaccess...

資料庫連線池

資料庫連線池概述 資料庫連線是一種關鍵的有限的昂貴的資源，這一點在多使用者的網頁應用程式中體現得尤為突出。對資料庫連線的管理能顯著影響到整個應用程式的伸縮性和健壯性，影響到程式的效能指標。資料庫連線池正是針對這個問題提出來的。資料庫連線池負責分配 管理和釋放資料庫連線，它允許應用程式重複使用乙個現有...