共計(jì) 2828 個(gè)字符，預(yù)計(jì)需要花費(fèi) 8 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“怎么配置數(shù)據(jù)庫(kù)鏈接池，使速度加快”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1 萬(wàn)并發(fā)用戶訪問

想象你有一個(gè)網(wǎng)站，壓力雖然還沒到 Facebook 那個(gè)級(jí)別，但也有個(gè) 1 萬(wàn)上下的并發(fā)訪問 mdash; mdash; 也就是說差不多 2 萬(wàn)左右的 TPS。那么這個(gè)網(wǎng)站的數(shù)據(jù)庫(kù)連接池應(yīng)該設(shè)置成多大呢？結(jié)果可能會(huì)讓你驚訝，因?yàn)檫@個(gè)問題的正確問法是：

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

Oracle 數(shù)據(jù)庫(kù)進(jìn)行壓力測(cè)試，9600 并發(fā)線程進(jìn)行數(shù)據(jù)庫(kù)操作，每?jī)纱卧L問數(shù)據(jù)庫(kù)的操作之間 sleep 550ms，一開始設(shè)置的中間件線程池大小為 2048：

初始的配置

壓測(cè)跑起來之后是這個(gè)樣子的：

2048 連接時(shí)的性能數(shù)據(jù)

每個(gè)請(qǐng)求要在連接池隊(duì)列里等待 33ms，獲得連接后執(zhí)行 SQL 需要 77ms

此時(shí)數(shù)據(jù)庫(kù)的等待事件是這個(gè)熊樣的：

各種 buffer busy waits

各種 buffer busy waits，數(shù)據(jù)庫(kù) CPU 在 95% 左右（這張圖里沒截到 CPU）

接下來，把中間件連接池減到 1024（并發(fā)什么的都不變），性能數(shù)據(jù)變成了這樣：

連接池降到 1024 后

獲取鏈接等待時(shí)長(zhǎng)沒怎么變，但是執(zhí)行 SQL 的耗時(shí)減少了。

下面這張圖，上半部分是 wait，下半部分是吞吐量

wait 和吞吐量

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

接下來，把數(shù)據(jù)庫(kù)連接池減到 96，并發(fā)線程數(shù)仍然是 9600 不變。

96 個(gè)連接時(shí)的性能數(shù)據(jù)

隊(duì)列平均等待 1ms，執(zhí)行 SQL 平均耗時(shí) 2ms。

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

沒有調(diào)整任何其他東西，僅僅只是縮小了中間件層的數(shù)據(jù)庫(kù)連接池，就把請(qǐng)求響應(yīng)時(shí)間從 100ms 左右縮短到了 3ms。

But why?

為什么 nginx 只用 4 個(gè)線程發(fā)揮出的性能就大大超越了 100 個(gè)進(jìn)程的 Apache HTTPD？回想一下計(jì)算機(jī)科學(xué)的基礎(chǔ)知識(shí)，答案其實(shí)是很明顯的。

即使是單核 CPU 的計(jì)算機(jī)也能“同時(shí)”運(yùn)行數(shù)百個(gè)線程。但我們都 [應(yīng)該] 知道這只不過是操作系統(tǒng)用時(shí)間分片玩的一個(gè)小把戲。一顆 CPU 核心同一時(shí)刻只能執(zhí)行一個(gè)線程，然后操作系統(tǒng)切換上下文，核心開始執(zhí)行另一個(gè)線程的代碼，以此類推。給定一顆 CPU 核心，其順序執(zhí)行 A 和 B 永遠(yuǎn)比通過時(shí)間分片“同時(shí)”執(zhí)行 A 和 B 要快，這是一條計(jì)算機(jī)科學(xué)的基本法則。一旦線程的數(shù)量超過了 CPU 核心的數(shù)量，再增加線程數(shù)系統(tǒng)就只會(huì)更慢，而不是更快。

這幾乎就是真理了 hellip; hellip;

有限的資源

上面的說法只能說是接近真理，但還并沒有這么簡(jiǎn)單，有一些其他的因素需要加入。當(dāng)我們尋找數(shù)據(jù)庫(kù)的性能瓶頸時(shí)，總是可以將其歸為三類：CPU、磁盤、網(wǎng)絡(luò)。把內(nèi)存加進(jìn)來也沒有錯(cuò)，但比起磁盤和網(wǎng)絡(luò)，內(nèi)存的帶寬要高出好幾個(gè)數(shù)量級(jí)，所以就先不加了。

如果我們無視磁盤和網(wǎng)絡(luò)，那么結(jié)論就非常簡(jiǎn)單。在一個(gè) 8 核的服務(wù)器上，設(shè)定連接 / 線程數(shù)為 8 能夠提供最優(yōu)的性能，再增加連接數(shù)就會(huì)因上下文切換的損耗導(dǎo)致性能下降。

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

在這一時(shí)間段（即 I/ O 等待）內(nèi)，線程是在“阻塞”著等待磁盤，此時(shí)操作系統(tǒng)可以將那個(gè)空閑的 CPU 核心用于服務(wù)其他線程。所以，由于線程總是在 I / O 上阻塞，我們可以讓線程 / 連接數(shù)比 CPU 核心多一些，這樣能夠在同樣的時(shí)間內(nèi)完成更多的工作。

那么應(yīng)該多多少呢？這要取決于磁盤。較新型的 SSD 不需要尋址，也沒有旋轉(zhuǎn)的碟片。可別想當(dāng)然地認(rèn)為“SSD 速度更快，所以我們應(yīng)該增加線程數(shù)”，恰恰相反，無需尋址和沒有旋回耗時(shí)意味著更少的阻塞，所以更少的線程 [更接近于 CPU 核心數(shù)] 會(huì)發(fā)揮出更高的性能。只有當(dāng)阻塞創(chuàng)造了更多的執(zhí)行機(jī)會(huì)時(shí)，更多的線程數(shù)才能發(fā)揮出更好的性能。

網(wǎng)絡(luò)和磁盤類似。通過以太網(wǎng)接口讀寫數(shù)據(jù)時(shí)也會(huì)形成阻塞，10G 帶寬會(huì)比 1G 帶寬的阻塞少一些，1G 帶寬又會(huì)比 100M 帶寬的阻塞少一些。不過網(wǎng)絡(luò)通常是放在第三位考慮的，有些人會(huì)在性能計(jì)算中忽略它們。

上圖是 PostgreSQL 的 benchmark 數(shù)據(jù)，可以看到 TPS 增長(zhǎng)率從 50 個(gè)連接數(shù)開始變緩。在上面 Oracle 的視頻中，他們把連接數(shù)從 2048 降到了 96，實(shí)際上 96 都太高了，除非服務(wù)器有 16 或 32 顆核心。

計(jì)算公式

下面的公式是由 PostgreSQL 提供的，不過我們認(rèn)為可以廣泛地應(yīng)用于大多數(shù)數(shù)據(jù)庫(kù)產(chǎn)品。你應(yīng)該模擬預(yù)期的訪問量，并從這一公式開始測(cè)試你的應(yīng)用，尋找最合適的連接數(shù)值。

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

核心數(shù)不應(yīng)包含超線程(hyper thread)，即使打開了 hyperthreading 也是。如果活躍數(shù)據(jù)全部被緩存了，那么有效磁盤數(shù)是 0，隨著緩存命中率的下降，有效磁盤數(shù)逐漸趨近于實(shí)際的磁盤數(shù)。這一公式作用于 SSD 時(shí)的效果如何尚未有分析。

按這個(gè)公式，你的 4 核 i7 數(shù)據(jù)庫(kù)服務(wù)器的連接池大小應(yīng)該為((4 * 2) + 1) = 9。取個(gè)整就算是是 10 吧。是不是覺得太小了？跑個(gè)性能測(cè)試試一下，我們保證它能輕松搞定 3000 用戶以 6000TPS 的速率并發(fā)執(zhí)行簡(jiǎn)單查詢的場(chǎng)景。如果連接池大小超過 10，你會(huì)看到響應(yīng)時(shí)長(zhǎng)開始增加，TPS 開始下降。

筆者注：

這一公式其實(shí)不僅適用于數(shù)據(jù)庫(kù)連接池的計(jì)算，大部分涉及計(jì)算和 I / O 的程序，線程數(shù)的設(shè)置都可以參考這一公式。我之前在對(duì)一個(gè)使用 Netty 編寫的消息收發(fā)服務(wù)進(jìn)行壓力測(cè)試時(shí)，最終測(cè)出的最佳線程數(shù)就剛好是 CPU 核心數(shù)的一倍。

公理：你需要一個(gè)小連接池，和一個(gè)充滿了等待連接的線程的隊(duì)列

如果你有 10000 個(gè)并發(fā)用戶，設(shè)置一個(gè) 10000 的連接池基本等于失了智。1000 仍然很恐怖。即是 100 也太多了。你需要一個(gè) 10 來個(gè)連接的小連接池，然后讓剩下的業(yè)務(wù)線程都在隊(duì)列里等待。連接池中的連接數(shù)量應(yīng)該等于你的數(shù)據(jù)庫(kù)能夠有效同時(shí)進(jìn)行的查詢?nèi)蝿?wù)數(shù)（通常不會(huì)高于 2 *CPU 核心數(shù)）。

我們經(jīng)常見到一些小規(guī)模的 web 應(yīng)用，應(yīng)付著大約十來個(gè)的并發(fā)用戶，卻使用著一個(gè) 100 連接數(shù)的連接池。這會(huì)對(duì)你的數(shù)據(jù)庫(kù)造成極其不必要的負(fù)擔(dān)。

請(qǐng)注意

連接池的大小最終與系統(tǒng)特性相關(guān)。

比如一個(gè)混合了長(zhǎng)事務(wù)和短事務(wù)的系統(tǒng)，通常是任何連接池都難以進(jìn)行調(diào)優(yōu)的。最好的辦法是創(chuàng)建兩個(gè)連接池，一個(gè)服務(wù)于長(zhǎng)事務(wù)，一個(gè)服務(wù)于短事務(wù)。

再例如一個(gè)系統(tǒng)執(zhí)行一個(gè)任務(wù)隊(duì)列，只允許一定數(shù)量的任務(wù)同時(shí)執(zhí)行，此時(shí)并發(fā)任務(wù)數(shù)應(yīng)該去適應(yīng)連接池連接數(shù)，而不是反過來。

“怎么配置數(shù)據(jù)庫(kù)鏈接池，使速度加快”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！