技術(shù)經(jīng)理：求求你，別再亂改數(shù)據(jù)庫連接池的大小了！

本文實(shí)際上來自 Spring Boot2.0+ 默認(rèn)使用的數(shù)據(jù)庫連接池 HikariCP 的官方 wiki，本文只是對其進(jìn)行的翻譯和整理。原文地址：https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

一、前言

基本上來說，大部分項(xiàng)目都需要跟數(shù)據(jù)庫做交互，那么，數(shù)據(jù)庫連接池的大小設(shè)置成多大合適呢？

一些開發(fā)老鳥可能還會(huì)告訴你：沒關(guān)系，盡量設(shè)置的大些，比如設(shè)置成 200，這樣數(shù)據(jù)庫性能會(huì)高些，吞吐量也會(huì)大些！

你也許會(huì)點(diǎn)頭稱是，真的是這樣嗎？看完這篇文章，也許會(huì)顛覆你的認(rèn)知哦！

你不要騙我

二、正菜開始

可以很直接的說，關(guān)于數(shù)據(jù)庫連接池大小的設(shè)置，每個(gè)開發(fā)者都可能會(huì)在這一環(huán)節(jié)掉進(jìn)坑里。事實(shí)上呢，大部分程序員可能都會(huì)依靠自己的直覺去設(shè)置它的大小，設(shè)置成 100 ？思量許久后，自顧自想，應(yīng)該差不多吧？

三、假設(shè)你的服務(wù)有1萬并發(fā)的訪問

不妨意淫一下，你手里有個(gè)網(wǎng)站，并發(fā)壓力雖然還沒到 Facebook 那個(gè)級別，但是呢？也有個(gè)1萬上下的并發(fā)量！也就是說差不多2萬左右的 TPS。

那么問題來了！這個(gè)網(wǎng)站的數(shù)據(jù)庫連接池應(yīng)該設(shè)置成多大合適呢？

其實(shí)這個(gè)問法本身就是有問題的，我們需要反過來問，正確問法應(yīng)該是：

“這個(gè)網(wǎng)站的數(shù)據(jù)庫連接池應(yīng)該設(shè)置成多小合適呢？”

PS: 這里有一個(gè) Oracle 性能小組發(fā)布的簡短視頻，鏈接地址為 http://www.dailymotion.com/video/x2s8uec，友情提示，需要xx上網(wǎng)才能訪問哦！

oracle性能測試視頻

口述一下，視頻中對 Oracle 數(shù)據(jù)庫進(jìn)行了壓力測試，模擬 9600 個(gè)并發(fā)線程來操作數(shù)據(jù)庫，每兩次數(shù)據(jù)庫操作之間 sleep 550ms，注意，視頻中剛開始設(shè)置的線程池大小為 2048。

讓我們來看看數(shù)據(jù)庫連接池的大小為 2048 性能測試結(jié)果的鬼樣子：

每個(gè)請求要在連接池隊(duì)列里等待 33ms，獲得連接之后，執(zhí)行SQL需要耗時(shí)77ms, CPU 消耗維持在 95% 左右；

接下來，我們將連接池的大小改小點(diǎn)，設(shè)置成 1024，其他測試參數(shù)不變，結(jié)果咋樣？

"這里，獲取連接等待時(shí)長基本不變，但是 SQL 的執(zhí)行耗時(shí)降低了！"

哎呦，有長進(jìn)哦！

接下來，我們再設(shè)置小些，連接池的大小降低到 96，并發(fā)數(shù)等其他參數(shù)不變，看看結(jié)果如何：

每個(gè)請求在連接池隊(duì)列中的平均等待時(shí)間為 1ms, SQL 執(zhí)行耗時(shí)為 2ms.

我去！什么鬼？

我們沒調(diào)整任何東西，僅僅只是將數(shù)據(jù)庫連接池的大小降低了，這樣，就能把之前平均 100ms 響應(yīng)時(shí)間縮短到了 3ms。吞吐量指數(shù)級上升啊！

你這也太溜了！

吃驚

四、為啥有這種效果?

我們不妨想一下，為啥 Nginx 內(nèi)部僅僅使用了 4 個(gè)線程，其性能就大大超越了 100 個(gè)進(jìn)程的 Apache HTTPD 呢？追究其原因的話，回想一下計(jì)算機(jī)科學(xué)的基礎(chǔ)知識(shí)，答案其實(shí)非常明顯。

要知道，即使是單核 CPU 的計(jì)算機(jī)也能“同時(shí)”運(yùn)行著數(shù)百個(gè)線程。但我們其實(shí)都知道，這只不過是操作系統(tǒng)快速切換時(shí)間片，跟我們玩的一個(gè)小把戲罷了。

一核 CPU同一時(shí)刻只能執(zhí)行一個(gè)線程，然后操作系統(tǒng)切換上下文，CPU 核心快速調(diào)度，執(zhí)行另一個(gè)線程的代碼，不停反復(fù)，給我們造成了所有進(jìn)程同時(shí)運(yùn)行假象。

其實(shí)，在一核 CPU 的機(jī)器上，順序執(zhí)行A和B永遠(yuǎn)比通過時(shí)間分片切換“同時(shí)”執(zhí)行A和B要快，其中原因，學(xué)過操作系統(tǒng)這門課程的童鞋應(yīng)該很清楚。一旦線程的數(shù)量超過了 CPU 核心的數(shù)量，再增加線程數(shù)系統(tǒng)就只會(huì)更慢，而不是更快，因?yàn)檫@里涉及到上下文切換耗費(fèi)的額外的性能。

說到這里，你應(yīng)該恍然大悟了 ……

我懂了

五、其他應(yīng)該考慮到的因素

上小節(jié)中說到了主要原因，但其實(shí)沒有這么簡單，我們還需要考慮到一些其他的因素。

當(dāng)我們在尋找數(shù)據(jù)庫的性能瓶頸時(shí)，大致可歸為三類：

CPU

磁盤 IO

網(wǎng)絡(luò) IO

也許你會(huì)說，還有內(nèi)存這一因素？內(nèi)存的確是需要考慮的，但是比起磁盤IO和網(wǎng)絡(luò)IO，稍顯微不足道，這里就不加了。

假設(shè)我們不考慮磁盤 IO 和網(wǎng)絡(luò) IO，就很好定論了，在一個(gè) 8 核的服務(wù)器上，數(shù)據(jù)庫連接數(shù)/線程數(shù)設(shè)置為 8 能夠提供最優(yōu)的性能，如果再增加連接數(shù)，反而會(huì)因?yàn)樯舷挛那袚Q導(dǎo)致性能下降。

大家都知道，數(shù)據(jù)庫通常把數(shù)據(jù)存儲(chǔ)在磁盤上，而磁盤呢，通常是由一些旋轉(zhuǎn)著的金屬碟片和一個(gè)裝在步進(jìn)馬達(dá)上的讀寫頭組成的。讀/寫頭同一時(shí)刻只能出現(xiàn)在一個(gè)位置，當(dāng)它需要再次執(zhí)行讀寫操作時(shí)，它必須“尋址”到另外一個(gè)位置才能完成任務(wù)。所以呢？這里就有了尋址的耗時(shí)，此外還有旋轉(zhuǎn)耗時(shí)，讀寫頭需要等待磁盤碟片上的目標(biāo)數(shù)據(jù)“旋轉(zhuǎn)到位”才能進(jìn)行讀寫操作。使用緩存當(dāng)然是能夠提升性能的，但上述原理仍然適用。

在這段（"I/O等待"）時(shí)間內(nèi)，線程是處于“阻塞”等待狀態(tài)，也就是說沒干啥正事！此時(shí)操作系統(tǒng)可以將這個(gè)空閑的CPU 核心用于服務(wù)其他線程。

這里我們可以總結(jié)一下，當(dāng)你的線程處理的是 I/O 密集型業(yè)務(wù)時(shí)，便可以讓線程/連接數(shù)設(shè)置的比 CPU核心大一些，這樣就能夠在同樣的時(shí)間內(nèi)，完成更多的工作，提升吞吐量。

那么問題又來了？

大小設(shè)置成多少合適呢？

這要取決于磁盤，如果你使用的是 SSD 固態(tài)硬盤，它不需要尋址，也不需要旋轉(zhuǎn)碟片。打住打住！！！你千萬可別理所當(dāng)然的認(rèn)為：“既然SSD速度更快，我們把線程數(shù)的大小設(shè)置的大些吧！！”

結(jié)論正好相反！無需尋址和沒有旋回耗時(shí)的確意味著更少的阻塞，所以更少的線程（更接近于CPU核心數(shù)）會(huì)發(fā)揮出更高的性能。只有當(dāng)阻塞密集時(shí)，更多的線程數(shù)才能發(fā)揮出更好的性能。

上面我們已經(jīng)說過了磁盤 IO, 接下來我們談?wù)劸W(wǎng)絡(luò) IO！

網(wǎng)絡(luò) IO 其實(shí)也是非常相似的。通過以太網(wǎng)接口讀寫數(shù)據(jù)時(shí)也會(huì)造成阻塞，10G帶寬會(huì)比1G帶寬的阻塞耗時(shí)少一些，而 1G 帶寬又會(huì)比 100M 帶寬的阻塞少一些。通常情況下，我們把網(wǎng)絡(luò) IO 放在第三順位來考慮，然而有些人會(huì)在性能計(jì)算中忽略網(wǎng)絡(luò) IO 帶來的影響。

PostgreSQL的benchmark數(shù)據(jù)

上圖是 PostgreSQL 的基準(zhǔn)性能測試數(shù)據(jù)，從圖中我們可以看到，TPS 在連接數(shù)達(dá)到 50 時(shí)開始變緩。回過頭來想下，在上面 Oracle 的性能測試視頻中，測試人員們將連接數(shù)從 2048 降到了 96，實(shí)際上 96 還是太高了，除非你的服務(wù)器 CPU 核心數(shù)有 16 或 32。

六、連接數(shù)計(jì)算公式

下面公式由 PostgreSQL 提供，不過底層原理是不變的，它適用于市面上絕大部分?jǐn)?shù)據(jù)庫產(chǎn)品。還有，你應(yīng)該模擬預(yù)期的訪問量，并通過下面的公式先設(shè)置一個(gè)偏合理的值，然后在實(shí)際的測試中，通過微調(diào)，來尋找最合適的連接數(shù)大小。

連接數(shù) = ((核心數(shù) * 2) + 有效磁盤數(shù))

核心數(shù)不應(yīng)包含超線程(hyper thread)，即使打開了超線程也是如此，如果熱點(diǎn)數(shù)據(jù)全被緩存了，那么有效磁盤數(shù)實(shí)際是0，隨著緩存命中率的下降，有效磁盤數(shù)也逐漸趨近于實(shí)際的磁盤數(shù)。另外需要注意，這一公式作用于SSD 的效果如何，尚未明了。

好了，按照這個(gè)公式，如果說你的服務(wù)器 CPU 是 4核 i7 的，連接池大小應(yīng)該為((4*2)+1)=9。

取個(gè)整, 我們就設(shè)置為 10 吧。你這個(gè)行不行啊？10 也太小了吧！

行不行啊

你要是覺得不太行的話，可以跑個(gè)性能測試看看，我們可以保證，它能輕松支撐 3000 用戶以 6000 TPS 的速率并發(fā)執(zhí)行簡單查詢的場景。你還可以將連接池大小超過 10，那時(shí)，你會(huì)看到響應(yīng)時(shí)長開始增加，TPS 開始下降。

七、結(jié)論：你需要的是一個(gè)小連接池，和一個(gè)等待連接的線程隊(duì)列

假設(shè)說你有 10000 個(gè)并發(fā)訪問，而你設(shè)置了連接池大小為 10000，你怕是石樂志哦。

改成 1000，太高？改成 100？還是太多了。

你僅僅需要一個(gè)大小為 10 數(shù)據(jù)庫連接池，然后讓剩下的業(yè)務(wù)線程都在隊(duì)列里等待就可以了。

連接池中的連接數(shù)量大小應(yīng)該設(shè)置成：數(shù)據(jù)庫能夠有效同時(shí)進(jìn)行的查詢?nèi)蝿?wù)數(shù)（通常情況下來說不會(huì)高于 2*CPU核心數(shù)）。

你應(yīng)該經(jīng)常會(huì)看到一些用戶量不是很大的 web 應(yīng)用中，為應(yīng)付大約十來個(gè)的并發(fā)，卻將數(shù)據(jù)庫連接池設(shè)置成 100， 200 的情況。請不要過度配置您的數(shù)據(jù)庫連接池的大小。

八、額外需要注意的點(diǎn)

實(shí)際上，連接池的大小的設(shè)置還是要結(jié)合實(shí)際的業(yè)務(wù)場景來說事。

比如說，你的系統(tǒng)同時(shí)混合了長事務(wù)和短事務(wù)，這時(shí)，根據(jù)上面的公式來計(jì)算就很難辦了。正確的做法應(yīng)該是創(chuàng)建兩個(gè)連接池，一個(gè)服務(wù)于長事務(wù)，一個(gè)服務(wù)于"實(shí)時(shí)"查詢，也就是短事務(wù)。

還有一種情況，比方說一個(gè)系統(tǒng)執(zhí)行一個(gè)任務(wù)隊(duì)列，業(yè)務(wù)上要求同一時(shí)間內(nèi)只允許執(zhí)行一定數(shù)量的任務(wù)，這時(shí)，我們就應(yīng)該讓并發(fā)任務(wù)數(shù)去適配連接池連接數(shù)，而不是連接數(shù)大小去適配并發(fā)任務(wù)數(shù)。

Ref

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

本文轉(zhuǎn)載自微信公眾號JavaGuide

任務(wù)調(diào)度 數(shù)據(jù)庫

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。