?昨天一個(gè)微信群里在討論一個(gè)數(shù)據(jù)庫(kù)連接數(shù)?的計(jì)算公式，截圖看不太清楚。我來(lái)描述一下。說(shuō)是PG提供了一個(gè)連接數(shù)計(jì)算公式：連接數(shù)=核心數(shù)*2+有效磁盤數(shù)量。其中核心數(shù)不應(yīng)該包含超線程數(shù)量，而是物理核的數(shù)量。

這是一個(gè)十分典型的極限測(cè)試估算連接數(shù)的公式，主要目的是規(guī)避CPU方面存在的瓶頸。這種設(shè)置思路往往不會(huì)使用在普通的生產(chǎn)系統(tǒng)上，因?yàn)椴还苁荗LTP系統(tǒng)還是OLAP系統(tǒng)，作為數(shù)據(jù)庫(kù)服務(wù)器來(lái)說(shuō)，會(huì)話會(huì)有大量的工作會(huì)產(chǎn)生在IO上，包括網(wǎng)絡(luò)IO和磁盤IO，真正使用CPU的比例實(shí)際上并不高。對(duì)于OLTP系統(tǒng)來(lái)說(shuō)大量的CPU使用都是小于一個(gè)時(shí)間片（大部分UNIX系統(tǒng)都是一個(gè)厘秒）的，很少會(huì)把一個(gè)時(shí)間片用滿，因?yàn)閿?shù)據(jù)庫(kù)應(yīng)用中，會(huì)話大部分都在等待某些等待事件，比如IO，LWLOCK，LOCK,IPC等，一個(gè)會(huì)話ONCPU狀態(tài)的比例很低，因此使用CPU數(shù)量來(lái)作為會(huì)話數(shù)的設(shè)置基礎(chǔ)實(shí)際上并沒(méi)有任何科學(xué)依據(jù)。

從另外一個(gè)角度來(lái)說(shuō)，CPU之間也是有差異的，哪怕核數(shù)相同的CPU，其處理能力也不能同日而語(yǔ)，三五年前的同樣核數(shù)的CPU，其處理能力可能不到現(xiàn)在的1/3，花費(fèi)同樣CPU時(shí)間能夠完成的任務(wù)也會(huì)相差極大。簡(jiǎn)單的用CPU作為設(shè)置連接數(shù)的依據(jù)顯然是不合理的。在現(xiàn)在的絕大多數(shù)OLTP系統(tǒng)中，數(shù)據(jù)庫(kù)服務(wù)器的CPU資源都是十分充足的，大部分系統(tǒng)的主要問(wèn)題并不出現(xiàn)在CPU資源不足上，這是這二十年來(lái)摩爾定律給我們帶來(lái)的紅利。

實(shí)際上數(shù)據(jù)庫(kù)中的存在排隊(duì)效應(yīng)的地方很多，任何一個(gè)地方存在瓶頸都會(huì)影響極限測(cè)試的性能，也會(huì)影響到生產(chǎn)環(huán)境中的并發(fā)訪問(wèn)效率。兩年前我寫過(guò)一篇文章《從疏通下水道聯(lián)想到的優(yōu)化問(wèn)題》，這篇文章中對(duì)此做了詳細(xì)的分析，有興趣的朋友可以在我的公眾號(hào)中查找閱讀。

實(shí)際上決定數(shù)據(jù)庫(kù)連接數(shù)的最主要因素還是應(yīng)用，對(duì)于絕大多數(shù)數(shù)據(jù)庫(kù)系統(tǒng)而言，max_connections參數(shù)一定要確保使用這個(gè)數(shù)據(jù)庫(kù)的所有模塊不會(huì)因?yàn)檫B接池不足而導(dǎo)致應(yīng)用報(bào)錯(cuò)?，F(xiàn)在的應(yīng)用系統(tǒng)大多十分復(fù)雜，還有大量的模塊使用并發(fā)量十分不穩(wěn)定的微服務(wù)。我見(jiàn)過(guò)一套數(shù)據(jù)庫(kù)系統(tǒng)對(duì)接的應(yīng)用連接池超過(guò)100個(gè)，哪怕一個(gè)連接池設(shè)置幾十個(gè)連接，max_connections也必須設(shè)置為幾千才能確保大多數(shù)情況下不會(huì)因?yàn)閿?shù)據(jù)庫(kù)連接數(shù)限制而導(dǎo)致應(yīng)用故障。

數(shù)據(jù)庫(kù)的最大連接數(shù)設(shè)置的過(guò)大有什么壞處呢？最容易出問(wèn)題的往往不是CPU，當(dāng)然如果在云環(huán)境中，我們給數(shù)據(jù)庫(kù)的CPU資源很少，那么較大的連接可能會(huì)引發(fā)CPU資源的不足。關(guān)于云環(huán)境數(shù)據(jù)庫(kù)服務(wù)器的CPU資源問(wèn)題，那是一個(gè)更大的話題-容量管理，今天我們暫不討論。數(shù)據(jù)庫(kù)應(yīng)用對(duì)CPU的使用一般來(lái)說(shuō)是不存在資源不足的問(wèn)題的，當(dāng)然如果某個(gè)并發(fā)量很大的SQL的執(zhí)行計(jì)劃錯(cuò)了，是很容易把CPU跑爆掉的，這個(gè)也不在我們今天探討的范圍內(nèi)，因?yàn)檫@種情況出現(xiàn)，哪怕連接數(shù)設(shè)置的很低，也會(huì)出問(wèn)題。

除此之外，實(shí)際上最容易出問(wèn)題的是內(nèi)存，數(shù)據(jù)庫(kù)會(huì)話數(shù)多了，因?yàn)锳TTACH共享內(nèi)存所占用的TLB就會(huì)很大，特別是數(shù)據(jù)庫(kù)沒(méi)有使用大頁(yè)的情況下。前陣子我們?cè)诜治鲆粋€(gè)數(shù)據(jù)庫(kù)宕機(jī)的案例中，就發(fā)現(xiàn)一臺(tái)128GB的數(shù)據(jù)庫(kù)服務(wù)器上，TLB居然高達(dá)30GB。另外會(huì)話都會(huì)使用WORK_MEM來(lái)做排序、JOIN等操作。會(huì)話數(shù)多了，這些內(nèi)存自然就會(huì)使用的更多。前兩年和一個(gè)國(guó)外的PGER交流的時(shí)候，他提出了一個(gè)PG內(nèi)存估算的方法，悲觀的算法是MAX_CONNECTIONS*WORK_MEM作為會(huì)話工作內(nèi)存，樂(lè)觀的算法是MAX_ACTIVE_SESSIONS*WORK_MEM作為會(huì)話的工作內(nèi)存。根據(jù)這個(gè)，結(jié)合物理內(nèi)存大小，計(jì)算SHARED_BUFFERS能夠使用內(nèi)存的最大值。

實(shí)際上悲觀與樂(lè)觀算法算出來(lái)的值相差甚大，基本上不具備參考意義。當(dāng)時(shí)我和他說(shuō)與其這么精打細(xì)算，莫不如把SWAP設(shè)置大一點(diǎn)，哪怕物理內(nèi)存偶爾用的多一些，系統(tǒng)產(chǎn)生一個(gè)小抖動(dòng)，很快就能挺過(guò)去了。他想了一會(huì)兒，認(rèn)同了我的觀點(diǎn)。

實(shí)際上我們今天討論的內(nèi)容很多都屬于容量管理的范疇，這個(gè)問(wèn)題也是困擾了我近20年的問(wèn)題，這20年里，參與過(guò)不少容量管理相關(guān)的項(xiàng)目，也幫用戶構(gòu)建了一些模型，只不過(guò)，感覺(jué)還是在門外晃悠。等有時(shí)間，我也會(huì)寫幾篇這方面的文章，把我們這些年的一些成果分享給大家。