您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“怎么配置數(shù)據(jù)庫(kù)鏈接池,使速度加快”的有關(guān)知識(shí),在實(shí)際案例的操作過(guò)程中,不少人都會(huì)遇到這樣的困境,接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧!希望大家仔細(xì)閱讀,能夠?qū)W有所成!
1萬(wàn)并發(fā)用戶訪問(wèn)
想象你有一個(gè)網(wǎng)站,壓力雖然還沒(méi)到Facebook那個(gè)級(jí)別,但也有個(gè)1萬(wàn)上下的并發(fā)訪問(wèn)——也就是說(shuō)差不多2萬(wàn)左右的TPS。那么這個(gè)網(wǎng)站的數(shù)據(jù)庫(kù)連接池應(yīng)該設(shè)置成多大呢?結(jié)果可能會(huì)讓你驚訝,因?yàn)檫@個(gè)問(wèn)題的正確問(wèn)法是:
“這個(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問(wèn)數(shù)據(jù)庫(kù)的操作之間sleep 550ms,一開(kāi)始設(shè)置的中間件線程池大小為2048:
初始的配置
壓測(cè)跑起來(lái)之后是這個(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%左右(這張圖里沒(méi)截到CPU)
接下來(lái),把中間件連接池減到1024(并發(fā)什么的都不變),性能數(shù)據(jù)變成了這樣:
連接池降到1024后
獲取鏈接等待時(shí)長(zhǎng)沒(méi)怎么變,但是執(zhí)行SQL的耗時(shí)減少了。
下面這張圖,上半部分是wait,下半部分是吞吐量
wait和吞吐量
能看到,中間件連接池從2048減半之后,吐吞量沒(méi)變,但wait事件減少了一半。
接下來(lái),把數(shù)據(jù)庫(kù)連接池減到96,并發(fā)線程數(shù)仍然是9600不變。
96個(gè)連接時(shí)的性能數(shù)據(jù)
隊(duì)列平均等待1ms,執(zhí)行SQL平均耗時(shí)2ms。
wait事件幾乎沒(méi)了,吞吐量上升。
沒(méi)有調(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)該]知道這只不過(guò)是操作系統(tǒng)用時(shí)間分片玩的一個(gè)小把戲。一顆CPU核心同一時(shí)刻只能執(zhí)行一個(gè)線程,然后操作系統(tǒng)切換上下文,核心開(kāi)始執(zhí)行另一個(gè)線程的代碼,以此類推。給定一顆CPU核心,其順序執(zhí)行A和B永遠(yuǎn)比通過(guò)時(shí)間分片“同時(shí)”執(zhí)行A和B要快,這是一條計(jì)算機(jī)科學(xué)的基本法則。一旦線程的數(shù)量超過(guò)了CPU核心的數(shù)量,再增加線程數(shù)系統(tǒng)就只會(huì)更慢,而不是更快。
這幾乎就是真理了……
有限的資源
上面的說(shuō)法只能說(shuō)是接近真理,但還并沒(méi)有這么簡(jiǎn)單,有一些其他的因素需要加入。當(dāng)我們尋找數(shù)據(jù)庫(kù)的性能瓶頸時(shí),總是可以將其歸為三類:CPU、磁盤(pán)、網(wǎng)絡(luò)。把內(nèi)存加進(jìn)來(lái)也沒(méi)有錯(cuò),但比起磁盤(pán)和網(wǎng)絡(luò),內(nèi)存的帶寬要高出好幾個(gè)數(shù)量級(jí),所以就先不加了。
如果我們無(wú)視磁盤(pán)和網(wǎng)絡(luò),那么結(jié)論就非常簡(jiǎn)單。在一個(gè)8核的服務(wù)器上,設(shè)定連接/線程數(shù)為8能夠提供最優(yōu)的性能,再增加連接數(shù)就會(huì)因上下文切換的損耗導(dǎo)致性能下降。
數(shù)據(jù)庫(kù)通常把數(shù)據(jù)存儲(chǔ)在磁盤(pán)上,磁盤(pán)又通常是由一些旋轉(zhuǎn)著的金屬碟片和一個(gè)裝在步進(jìn)馬達(dá)上的讀寫(xiě)頭組成的。讀/寫(xiě)頭同一時(shí)刻只能出現(xiàn)在一個(gè)地方,然后它必須“尋址”到另外一個(gè)位置來(lái)執(zhí)行另一次讀寫(xiě)操作。所以就有了尋址的耗時(shí),此外還有旋回耗時(shí),讀寫(xiě)頭需要等待碟片上的目標(biāo)數(shù)據(jù)“旋轉(zhuǎn)到位”才能進(jìn)行操作。使用緩存當(dāng)然是能夠提升性能的,但上述原理仍然成立。
在這一時(shí)間段(即"I/O等待")內(nèi),線程是在“阻塞”著等待磁盤(pán),此時(shí)操作系統(tǒng)可以將那個(gè)空閑的CPU核心用于服務(wù)其他線程。所以,由于線程總是在I/O上阻塞,我們可以讓線程/連接數(shù)比CPU核心多一些,這樣能夠在同樣的時(shí)間內(nèi)完成更多的工作。
那么應(yīng)該多多少呢?這要取決于磁盤(pán)。較新型的SSD不需要尋址,也沒(méi)有旋轉(zhuǎn)的碟片??蓜e想當(dāng)然地認(rèn)為“SSD速度更快,所以我們應(yīng)該增加線程數(shù)”,恰恰相反,無(wú)需尋址和沒(méi)有旋回耗時(shí)意味著更少的阻塞,所以更少的線程[更接近于CPU核心數(shù)]會(huì)發(fā)揮出更高的性能。只有當(dāng)阻塞創(chuàng)造了更多的執(zhí)行機(jī)會(huì)時(shí),更多的線程數(shù)才能發(fā)揮出更好的性能。
網(wǎng)絡(luò)和磁盤(pán)類似。通過(guò)以太網(wǎng)接口讀寫(xiě)數(shù)據(jù)時(shí)也會(huì)形成阻塞,10G帶寬會(huì)比1G帶寬的阻塞少一些,1G帶寬又會(huì)比100M帶寬的阻塞少一些。不過(guò)網(wǎng)絡(luò)通常是放在第三位考慮的,有些人會(huì)在性能計(jì)算中忽略它們。
上圖是PostgreSQL的benchmark數(shù)據(jù),可以看到TPS增長(zhǎng)率從50個(gè)連接數(shù)開(kāi)始變緩。在上面Oracle的視頻中,他們把連接數(shù)從2048降到了96,實(shí)際上96都太高了,除非服務(wù)器有16或32顆核心。
計(jì)算公式
下面的公式是由PostgreSQL提供的,不過(guò)我們認(rèn)為可以廣泛地應(yīng)用于大多數(shù)數(shù)據(jù)庫(kù)產(chǎn)品。你應(yīng)該模擬預(yù)期的訪問(wèn)量,并從這一公式開(kāi)始測(cè)試你的應(yīng)用,尋找最合適的連接數(shù)值。
連接數(shù) = ((核心數(shù) * 2) + 有效磁盤(pán)數(shù))
核心數(shù)不應(yīng)包含超線程(hyper thread),即使打開(kāi)了hyperthreading也是。如果活躍數(shù)據(jù)全部被緩存了,那么有效磁盤(pán)數(shù)是0,隨著緩存命中率的下降,有效磁盤(pán)數(shù)逐漸趨近于實(shí)際的磁盤(pán)數(shù)。這一公式作用于SSD時(shí)的效果如何尚未有分析。
按這個(gè)公式,你的4核i7數(shù)據(jù)庫(kù)服務(wù)器的連接池大小應(yīng)該為((4 * 2) + 1) = 9。取個(gè)整就算是是10吧。是不是覺(jué)得太小了?跑個(gè)性能測(cè)試試一下,我們保證它能輕松搞定3000用戶以6000TPS的速率并發(fā)執(zhí)行簡(jiǎn)單查詢的場(chǎng)景。如果連接池大小超過(guò)10,你會(huì)看到響應(yīng)時(shí)長(zhǎng)開(kāi)始增加,TPS開(kāi)始下降。
筆者注:
這一公式其實(shí)不僅適用于數(shù)據(jù)庫(kù)連接池的計(jì)算,大部分涉及計(jì)算和I/O的程序,線程數(shù)的設(shè)置都可以參考這一公式。我之前在對(duì)一個(gè)使用Netty編寫(xiě)的消息收發(fā)服務(wù)進(jìn)行壓力測(cè)試時(shí),最終測(cè)出的最佳線程數(shù)就剛好是CPU核心數(shù)的一倍。
公理:你需要一個(gè)小連接池,和一個(gè)充滿了等待連接的線程的隊(duì)列
如果你有10000個(gè)并發(fā)用戶,設(shè)置一個(gè)10000的連接池基本等于失了智。1000仍然很恐怖。即是100也太多了。你需要一個(gè)10來(lái)個(gè)連接的小連接池,然后讓剩下的業(yè)務(wù)線程都在隊(duì)列里等待。連接池中的連接數(shù)量應(yīng)該等于你的數(shù)據(jù)庫(kù)能夠有效同時(shí)進(jìn)行的查詢?nèi)蝿?wù)數(shù)(通常不會(huì)高于2*CPU核心數(shù))。
我們經(jīng)常見(jiàn)到一些小規(guī)模的web應(yīng)用,應(yīng)付著大約十來(lái)個(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ù),而不是反過(guò)來(lái)。
“怎么配置數(shù)據(jù)庫(kù)鏈接池,使速度加快”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實(shí)用文章!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。