選測(cè)的軟件版本及采用的測(cè)試工具

1、MySQL、PostgreSQL、KingbaseES調(diào)優(yōu)及評(píng)測(cè)

我們對(duì)MySQL、PostgreSQL、KingbaseES這3個(gè)數(shù)據(jù)庫(kù)在實(shí)際運(yùn)行中反映出的性能問(wèn)題,均進(jìn)行相關(guān)性能瓶頸分析,并采用了針對(duì)性的調(diào)優(yōu)手段,以使其能夠展現(xiàn)最優(yōu)的性能表現(xiàn)。

1.1、MySQL調(diào)優(yōu)及評(píng)測(cè)

1.1.1、優(yōu)化1,調(diào)整IO相關(guān)配置

分析:初始默認(rèn)配置下,CPU利用率只有45%左右,大概在8萬(wàn)TPMC,通過(guò)分析資源等待情況,判斷是IO問(wèn)題。

優(yōu)化點(diǎn):增加數(shù)據(jù)文件、日志文件的緩存大小,增加配置如下:

效果:通過(guò)增加緩存優(yōu)化了磁盤(pán)讀寫(xiě)數(shù)據(jù),性能提升兩倍。

1.1.2、優(yōu)化2:緩解binlog資源等待

分析:再次觀察系統(tǒng)資源情況,CPU利用率上升到50%左右,IO和網(wǎng)絡(luò)沒(méi)有壓力,懷疑關(guān)鍵瓶頸是數(shù)據(jù)庫(kù)內(nèi)部的資源等待。檢查MySQL當(dāng)前等待事件:

發(fā)現(xiàn)等待事件中最長(zhǎng)的是binlog,雖然其時(shí)間比例在總時(shí)間中占比較低,但是數(shù)據(jù)庫(kù)內(nèi)部的等待視圖看不到其他明顯的問(wèn)題,所以我們決定調(diào)整binlog相關(guān)的配置。

優(yōu)化點(diǎn):基于上述分析,我們將binglog設(shè)置為異步刷新,并且將日志級(jí)別設(shè)置為row來(lái)降低寫(xiě)入量。

效果:執(zhí)行測(cè)試后重新檢查等待事件,binlog等待已得到明顯改善,tpmC也有了一定的提升。

1.1.3、優(yōu)化3:自旋鎖優(yōu)化

分析:再次觀察系統(tǒng)資源情況,CPU利用率依然在50%左右,IO和網(wǎng)絡(luò)沒(méi)有壓力,懷疑關(guān)鍵瓶頸是數(shù)據(jù)庫(kù)內(nèi)部的資源等待。但是數(shù)據(jù)庫(kù)內(nèi)部的等待事件列表已經(jīng)看不出明顯的問(wèn)題,我們轉(zhuǎn)而通過(guò)perf來(lái)繼續(xù)查找根因,發(fā)現(xiàn)存在ut_delay的熱點(diǎn)函數(shù),所以判斷是自旋鎖相關(guān)的使用存在問(wèn)題:

優(yōu)化:重新調(diào)整自旋鎖相關(guān)的delay以及l(fā)oops等參數(shù)。

效果:再次測(cè)試后發(fā)現(xiàn),ut_delay的熱點(diǎn)函數(shù)已經(jīng)消失,tpmc有了大幅提升。

1.2、PostgreSQL調(diào)優(yōu)及評(píng)測(cè)

針對(duì)PostgreSQL主要采用了調(diào)優(yōu)手段:

1.2.1、優(yōu)化1,調(diào)整IO相關(guān)配置

分析:觀察系統(tǒng)資源使用情況,發(fā)現(xiàn)有大量磁盤(pán)IO事件。當(dāng)前磁盤(pán)讀寫(xiě)已成為制約系統(tǒng)性能的首要瓶頸,考慮通過(guò)增大共享內(nèi)存的方式盡量將數(shù)據(jù)放入內(nèi)存中進(jìn)行操作以減小磁盤(pán)IO壓力。

優(yōu)化點(diǎn):增加系統(tǒng)緩存,調(diào)整參數(shù)配置如下:

效果:TPCC性能指標(biāo)大幅提升,IO已不再是系統(tǒng)瓶頸。測(cè)試過(guò)程nmon性能統(tǒng)計(jì):

1.2.2、優(yōu)化2,commit事務(wù)提交優(yōu)化

分析:觀察此時(shí)系統(tǒng)資源使用情況,磁盤(pán)使用率較高,依然存在優(yōu)化空間

優(yōu)化點(diǎn):優(yōu)化commit提交。PostgreSQL提供了兩個(gè)參數(shù)commit_delay,commit_siblings。commit_delay是事務(wù)提交和日志刷盤(pán)的時(shí)間間隔。并發(fā)的非只讀事務(wù)數(shù)目較多的場(chǎng)景可以適當(dāng)增加該值,使日志緩沖區(qū)一次刷盤(pán)可以刷出較多的事務(wù),減少I(mǎi)O次數(shù),提高性能。需要和 commit_sibling配合使用。commit_siblings是觸發(fā)commit_delay的并發(fā)事務(wù)數(shù),只有系統(tǒng)的并發(fā)活躍事務(wù)數(shù)達(dá)到了該值,才會(huì)等待commit_delay的時(shí)間將日志刷盤(pán)。

調(diào)整參數(shù)如下:

效果:調(diào)整之后,性能有一定的提升

1.2.3、優(yōu)化3,數(shù)據(jù)刷盤(pán)優(yōu)化

分析:此時(shí)觀察系統(tǒng)資源,發(fā)現(xiàn)checkpoint進(jìn)程持續(xù)占用CPU,分析日志發(fā)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)器checkpoint頻率太高

優(yōu)化點(diǎn):優(yōu)化checkpoint,減少I(mǎi)O大量讀寫(xiě)的次數(shù)。增加配置:

效果:增加checkpoint配置后,checkpoint頻率過(guò)高告警已消失。

1.2.4、優(yōu)化4,autovacuum優(yōu)化

分析:大量寫(xiě)入數(shù)據(jù)之后,發(fā)現(xiàn)vacuum進(jìn)程持續(xù)占用CPU

優(yōu)化點(diǎn):PostgreSQL數(shù)據(jù)庫(kù)自動(dòng)清理機(jī)制,會(huì)自動(dòng)清理過(guò)程中出現(xiàn)大量的數(shù)據(jù)掃描事件,頻繁的清理過(guò)程反而會(huì)帶來(lái)數(shù)據(jù)庫(kù)過(guò)多的性能消耗,從而導(dǎo)致正常業(yè)務(wù)處理資源緊張。因此對(duì)自動(dòng)清理過(guò)程進(jìn)行限制可以在一定程度上提高業(yè)務(wù)處理性能。增加如下配置:

效果:vacuum進(jìn)程長(zhǎng)期占用CPU現(xiàn)象消失,性能有一定提升

1.3、KingbaseES調(diào)優(yōu)及評(píng)測(cè)結(jié)果

1.3.1、優(yōu)化1,IO優(yōu)化

分析:在高并發(fā)場(chǎng)景下影響數(shù)據(jù)庫(kù)處理能力性能主要因素有數(shù)據(jù)庫(kù)IO消耗、服務(wù)器CPU使用效率等因素,且IO優(yōu)化是數(shù)據(jù)庫(kù)優(yōu)化手段中最常見(jiàn)也是最常用的。KingbaseES數(shù)據(jù)庫(kù)優(yōu)化采用了共享內(nèi)存優(yōu)化、wal日志讀寫(xiě)策略、IO頻率、臟頁(yè)刷盤(pán)策略等多種優(yōu)化手段以提高高并發(fā)場(chǎng)景下的業(yè)務(wù)處理能力。

優(yōu)化前性能統(tǒng)計(jì):

優(yōu)化點(diǎn):共享內(nèi)存參數(shù)調(diào)整、wal日志策略調(diào)整、臟頁(yè)存盤(pán)策略等

效果:CPU利用率極大的提升,TPMC也相應(yīng)得到了提升。

優(yōu)化后的性能統(tǒng)計(jì):

1.3.2、優(yōu)化2,等待事件優(yōu)化

分析:觀察此時(shí)數(shù)據(jù)庫(kù)系統(tǒng)等待事件, ProcArrayGroupUpdate等待事件占據(jù)了34%的數(shù)據(jù)庫(kù)時(shí)間,存在較為嚴(yán)重的性能問(wèn)題。

優(yōu)化點(diǎn):優(yōu)化事務(wù)快照實(shí)現(xiàn)方式,提升數(shù)據(jù)庫(kù)并發(fā)處理能力。

優(yōu)化前系統(tǒng)top等待事件分析統(tǒng)計(jì):

優(yōu)化后系統(tǒng)top等待事件分析統(tǒng)計(jì):

效果:通過(guò)以上優(yōu)化前后系統(tǒng)等待事件對(duì)比,可以看出數(shù)據(jù)庫(kù)系統(tǒng)中ProcArrayGroupUpdate等待事件在優(yōu)化前占所有等待事件的34.46%,優(yōu)化后幾乎不占用系統(tǒng)CPU太長(zhǎng)事件,較大提升了整體性能。

1.3.3、優(yōu)化3,綁核提升性能

分析:CPU通用調(diào)度模式下,進(jìn)程容易因?yàn)闋?zhēng)搶時(shí)間片而在不同的CPU核心之間切換,由此帶來(lái)上下文切換的開(kāi)銷問(wèn)題,造成性能損耗。

優(yōu)化點(diǎn):KingbaseES通過(guò)將每個(gè)進(jìn)程均勻的綁定到CPU核心上,在高并發(fā)業(yè)務(wù)壓力下節(jié)省了進(jìn)程在多CPU核之間切換帶來(lái)的開(kāi)銷。

效果:調(diào)整之后,性能得到明顯提升。

1.4、經(jīng)驗(yàn)優(yōu)化

以上討論了對(duì)三個(gè)數(shù)據(jù)庫(kù)主要的調(diào)優(yōu)手段和結(jié)果,調(diào)優(yōu)后期,分別觀察各數(shù)據(jù)庫(kù)所在資源情況,CPU利用率上升到70-80%左右,IO和網(wǎng)絡(luò)無(wú)沒(méi)有明顯壓力。評(píng)估瓶頸優(yōu)化的方式投入產(chǎn)出比較低,進(jìn)一步根據(jù)已有經(jīng)驗(yàn)進(jìn)行調(diào)優(yōu)方式的確認(rèn)和細(xì)節(jié)參數(shù)的微調(diào)優(yōu)化。

參考如下確認(rèn)點(diǎn):

1.所有的SQL執(zhí)行計(jì)劃都合理,無(wú)調(diào)整空間

2.優(yōu)化IO,使用異步IO、優(yōu)化臟頁(yè)刷盤(pán)方式

3.優(yōu)化熱點(diǎn)函數(shù)、非必要處理事件

4.關(guān)閉監(jiān)控系統(tǒng)

效果:CPU利用率略有提升,tpmc也隨之略有提高。

1.5、最終評(píng)測(cè)結(jié)果

基于綜上描述的調(diào)優(yōu)操作和評(píng)測(cè),分別獲得MySQL、PostgreSQL、KingbaseES優(yōu)化后的性能指標(biāo),具體如下:

從結(jié)果上可見(jiàn),在同樣的基礎(chǔ)環(huán)境和測(cè)試模型下,人大金倉(cāng)KingbaseES產(chǎn)品的性能指標(biāo)明顯高于PostgreSQL和MySQL。KingbaseES為何性能上能夠表現(xiàn)如此優(yōu)異,讓我們來(lái)探究下其內(nèi)部的優(yōu)化技術(shù)。

2、淺談KingbaseES“黑科技”

2.1、面向NUMA架構(gòu)多核優(yōu)化

2.1.1、NUMA的“前世今生”

為了尋求算力上不斷新的突破,CPU先是朝著“頻率”的方向高歌猛跟進(jìn),但隨著逐漸受到物理極限的挑戰(zhàn),轉(zhuǎn)為向核數(shù)越來(lái)越多發(fā)展,但由于所有CPU核都是通過(guò)共享一個(gè)北橋來(lái)讀取內(nèi)存,核數(shù)的不斷增多帶來(lái)了北橋響應(yīng)時(shí)間的瓶頸問(wèn)題。于是技術(shù)人員另辟蹊徑,即將內(nèi)存平均分配在各個(gè)die上,由此CPU核發(fā)展進(jìn)入NUMA(Non-Uniform Memory Access)化時(shí)代,如此雖解決了原北橋讀取內(nèi)存的瓶頸問(wèn)題,但由于NUMA架構(gòu)下存在CPU訪問(wèn)本地內(nèi)存的速度要比遠(yuǎn)端內(nèi)存的訪問(wèn)速度快1.3–5倍,當(dāng)CPU的核數(shù)越多,這種架構(gòu)的內(nèi)存訪問(wèn)的成本開(kāi)銷越大。

2.1.2、NUMA架構(gòu)發(fā)展對(duì)數(shù)據(jù)庫(kù)的挑戰(zhàn)

數(shù)據(jù)庫(kù)是高并發(fā),數(shù)據(jù)訪問(wèn)沖突嚴(yán)重的軟件系統(tǒng),其需要大量使用大規(guī)模共享內(nèi)存,面對(duì)NUMA架構(gòu),就不可避免在運(yùn)行過(guò)程中去訪問(wèn)遠(yuǎn)程內(nèi)存了,在不干預(yù)情況下,數(shù)據(jù)庫(kù)內(nèi)部進(jìn)程會(huì)在CPU的核之間飄移,當(dāng)線程運(yùn)行時(shí)從一個(gè)核飄移到一個(gè)新的核上運(yùn)行時(shí),原先訪問(wèn)的數(shù)據(jù)結(jié)構(gòu)再次訪問(wèn)時(shí)就涉及遠(yuǎn)端訪問(wèn),從而導(dǎo)致訪問(wèn)時(shí)延增加。

由此可見(jiàn),雖然CPU的NUMA技術(shù)發(fā)展帶來(lái)了自身能力的大幅提升,但上層軟件能否有效利用,才能真正決定算力釋放的效果,縱觀IT技術(shù)棧,只有硬件、操作系統(tǒng)、數(shù)據(jù)庫(kù)軟件都要深度適配 NUMA架構(gòu),才能充分發(fā)揮出NUMA的優(yōu)勢(shì)。因此人大金倉(cāng)數(shù)據(jù)庫(kù)產(chǎn)品KingbaseES作為企業(yè)級(jí)的商用數(shù)據(jù)庫(kù),為了幫助用戶更高效地利用多核算力,提升數(shù)據(jù)庫(kù)的響應(yīng)速度,進(jìn)行了針對(duì)性的優(yōu)化。

2.1.3、線程綁核,降低訪問(wèn)時(shí)延

防止線程飄移,讓其實(shí)現(xiàn)CPU核的就近訪問(wèn),這是降低訪問(wèn)時(shí)延的關(guān)鍵,因此采用將線程能夠固定到具體的核上運(yùn)行的方法。KingbaseES利用配置參數(shù)設(shè)定,利用操作系統(tǒng)設(shè)置親和性接口達(dá)到將線程綁定到具體NUMA節(jié)點(diǎn)上的效果。

同時(shí),KingbaseES是一個(gè)客戶端服務(wù)器結(jié)構(gòu),客戶端和服務(wù)器是通過(guò)網(wǎng)絡(luò)通信來(lái)進(jìn)行交互,網(wǎng)絡(luò)是一個(gè)頻繁的操作,并也會(huì)占用CPU,因此還需考慮將網(wǎng)絡(luò)中斷和業(yè)務(wù)處理進(jìn)行區(qū)隔避免相互干擾,所以也對(duì)網(wǎng)絡(luò)中斷進(jìn)行了綁核操作,并和后臺(tái)業(yè)務(wù)線程綁核進(jìn)行區(qū)分,這樣能進(jìn)一步提升利用效率,降低內(nèi)耗。

2.1.4、NUMA化數(shù)據(jù)結(jié)構(gòu)改造,減少跨核訪問(wèn)

KingbaseES因業(yè)務(wù)處理需要,涉及很多對(duì)全局性數(shù)據(jù)結(jié)構(gòu)的操作,如WALInsertLock、PGPROC等,在NUMA架構(gòu)下,優(yōu)化前,此類數(shù)據(jù)結(jié)構(gòu)存放在共享內(nèi)存中,當(dāng)出現(xiàn)高并發(fā)訪問(wèn),訪問(wèn)競(jìng)爭(zhēng)激烈時(shí),就會(huì)存在對(duì)其跨核訪問(wèn),形成訪問(wèn)遠(yuǎn)端內(nèi)存的局面,造成性能消耗。

根據(jù)以上問(wèn)題,結(jié)合KingbaseES內(nèi)部操作邏輯特點(diǎn),并基于前文所述的線程綁核優(yōu)化,我們進(jìn)行了更深層更針對(duì)性的優(yōu)化,即將操作頻繁的的全局性數(shù)據(jù)結(jié)構(gòu)按照NUMA節(jié)點(diǎn)的數(shù)量切分為多組,并分別在對(duì)應(yīng)的NUMA節(jié)點(diǎn)上申請(qǐng)內(nèi)存,當(dāng)某線程需要操作相關(guān)數(shù)據(jù)結(jié)構(gòu),可訪問(wèn)自己所綁定的NUMA節(jié)點(diǎn)上本地內(nèi)存的相關(guān)數(shù)據(jù)結(jié)構(gòu)內(nèi)容,減少了跨核的遠(yuǎn)端訪問(wèn),提升了訪問(wèn)效率。

2.2、高并發(fā)沖突環(huán)境下的并發(fā)控制算法調(diào)整,減少單點(diǎn)瓶頸

原模式下,每個(gè)數(shù)據(jù)庫(kù)鏈接都會(huì)維護(hù)幾個(gè)存儲(chǔ)當(dāng)前狀態(tài)的結(jié)構(gòu),每當(dāng)事務(wù)需要獲得快照時(shí),申請(qǐng)共享進(jìn)程鎖,遍歷所有進(jìn)程?？煺招枰涗洶ó?dāng)前正在運(yùn)行的最大事務(wù)id、下一個(gè)將要開(kāi)始的事務(wù)id,以及這二者之間正在運(yùn)行的所有事務(wù)和子事務(wù)id列表?；诖?在可見(jiàn)性判斷時(shí)可知,低于最小事務(wù)id的事務(wù)已結(jié)束,而大于最大事務(wù)id的事務(wù)視為正在運(yùn)行,二者之間的事務(wù)態(tài)則需要根據(jù)列表判斷。在高并發(fā)時(shí),對(duì)所有進(jìn)程進(jìn)行遍歷的時(shí)間變長(zhǎng),并且由于進(jìn)程鎖在很多場(chǎng)景下需要獨(dú)占,例如下圖所示的事務(wù)結(jié)束,大量并發(fā)進(jìn)程相互之間的干擾愈加不可忽視,快照獲取過(guò)程成為占比最高的部分。有鑒于此,如何最大程度的減少鎖,成為解決問(wèn)題的關(guān)鍵。

根據(jù)內(nèi)核事務(wù)管理系統(tǒng)狀態(tài)信息的分布特點(diǎn),我們重新設(shè)計(jì)了數(shù)據(jù)結(jié)構(gòu),采用事務(wù)位圖方式展現(xiàn)事務(wù)狀態(tài)。如下圖所示,在事務(wù)開(kāi)始時(shí)使用獨(dú)占進(jìn)程鎖設(shè)置事務(wù)狀態(tài)位圖,結(jié)束時(shí)仍然使用獨(dú)占進(jìn)程鎖消除事務(wù)狀態(tài)位圖,而在獲取快照時(shí)也仍然使用共享事務(wù)鎖,但此時(shí)不再需要遍歷進(jìn)程狀態(tài)。此設(shè)計(jì)使?fàn)顟B(tài)數(shù)據(jù)變得非常緊湊,能夠快速獲取事務(wù)狀態(tài),大幅降低共享鎖的持有時(shí)間。

TPCC測(cè)試中,使用200并發(fā)終端壓測(cè),單獨(dú)驗(yàn)證跟蹤查看該方案最終測(cè)試結(jié)果,快照獲取過(guò)程在整個(gè)運(yùn)行期間的從占比6%以上,降低到0.2%以下。在不同平臺(tái)上,tpmC均有不同幅度的提升,其中Intel平臺(tái)大約20%,鯤鵬920平臺(tái)約有5-6%。

3、寄語(yǔ)

國(guó)產(chǎn)數(shù)據(jù)庫(kù)蟄伏40年,人大金倉(cāng)從第一代創(chuàng)辦人堅(jiān)信“中國(guó)也應(yīng)有自己的數(shù)據(jù)庫(kù)”之初心,到如今第三代金倉(cāng)人面對(duì)國(guó)內(nèi)外社會(huì)形勢(shì)的變化,能扛起國(guó)產(chǎn)數(shù)據(jù)庫(kù)承載核心業(yè)務(wù)應(yīng)用的大旗,這一路走來(lái),我們克服了很多困難,也得到了諸多客戶的支持與肯定。未來(lái),人大金倉(cāng)將繼續(xù)砥礪前行,不斷提升用戶對(duì)我們的信心,為中國(guó)數(shù)據(jù)庫(kù)正名。

songjy