選測的軟件版本及采用的測試工具
1、MySQL、PostgreSQL、KingbaseES調優(yōu)及評測
我們對MySQL、PostgreSQL、KingbaseES這3個數(shù)據(jù)庫在實際運行中反映出的性能問題,均進行相關性能瓶頸分析,并采用了針對性的調優(yōu)手段,以使其能夠展現(xiàn)最優(yōu)的性能表現(xiàn)。
1.1、MySQL調優(yōu)及評測
1.1.1、優(yōu)化1,調整IO相關配置
分析:初始默認配置下,CPU利用率只有45%左右,大概在8萬TPMC,通過分析資源等待情況,判斷是IO問題。
優(yōu)化點:增加數(shù)據(jù)文件、日志文件的緩存大小,增加配置如下:
效果:通過增加緩存優(yōu)化了磁盤讀寫數(shù)據(jù),性能提升兩倍。
1.1.2、優(yōu)化2:緩解binlog資源等待
分析:再次觀察系統(tǒng)資源情況,CPU利用率上升到50%左右,IO和網(wǎng)絡沒有壓力,懷疑關鍵瓶頸是數(shù)據(jù)庫內部的資源等待。檢查MySQL當前等待事件:
發(fā)現(xiàn)等待事件中最長的是binlog,雖然其時間比例在總時間中占比較低,但是數(shù)據(jù)庫內部的等待視圖看不到其他明顯的問題,所以我們決定調整binlog相關的配置。
優(yōu)化點:基于上述分析,我們將binglog設置為異步刷新,并且將日志級別設置為row來降低寫入量。
效果:執(zhí)行測試后重新檢查等待事件,binlog等待已得到明顯改善,tpmC也有了一定的提升。
1.1.3、優(yōu)化3:自旋鎖優(yōu)化
分析:再次觀察系統(tǒng)資源情況,CPU利用率依然在50%左右,IO和網(wǎng)絡沒有壓力,懷疑關鍵瓶頸是數(shù)據(jù)庫內部的資源等待。但是數(shù)據(jù)庫內部的等待事件列表已經看不出明顯的問題,我們轉而通過perf來繼續(xù)查找根因,發(fā)現(xiàn)存在ut_delay的熱點函數(shù),所以判斷是自旋鎖相關的使用存在問題:
優(yōu)化:重新調整自旋鎖相關的delay以及l(fā)oops等參數(shù)。
效果:再次測試后發(fā)現(xiàn),ut_delay的熱點函數(shù)已經消失,tpmc有了大幅提升。
1.2、PostgreSQL調優(yōu)及評測
針對PostgreSQL主要采用了調優(yōu)手段:
1.2.1、優(yōu)化1,調整IO相關配置
分析:觀察系統(tǒng)資源使用情況,發(fā)現(xiàn)有大量磁盤IO事件。當前磁盤讀寫已成為制約系統(tǒng)性能的首要瓶頸,考慮通過增大共享內存的方式盡量將數(shù)據(jù)放入內存中進行操作以減小磁盤IO壓力。
優(yōu)化點:增加系統(tǒng)緩存,調整參數(shù)配置如下:
效果:TPCC性能指標大幅提升,IO已不再是系統(tǒng)瓶頸。測試過程nmon性能統(tǒng)計:
1.2.2、優(yōu)化2,commit事務提交優(yōu)化
分析:觀察此時系統(tǒng)資源使用情況,磁盤使用率較高,依然存在優(yōu)化空間
優(yōu)化點:優(yōu)化commit提交。PostgreSQL提供了兩個參數(shù)commit_delay,commit_siblings。commit_delay是事務提交和日志刷盤的時間間隔。并發(fā)的非只讀事務數(shù)目較多的場景可以適當增加該值,使日志緩沖區(qū)一次刷盤可以刷出較多的事務,減少IO次數(shù),提高性能。需要和 commit_sibling配合使用。commit_siblings是觸發(fā)commit_delay的并發(fā)事務數(shù),只有系統(tǒng)的并發(fā)活躍事務數(shù)達到了該值,才會等待commit_delay的時間將日志刷盤。
調整參數(shù)如下:
效果:調整之后,性能有一定的提升
1.2.3、優(yōu)化3,數(shù)據(jù)刷盤優(yōu)化
分析:此時觀察系統(tǒng)資源,發(fā)現(xiàn)checkpoint進程持續(xù)占用CPU,分析日志發(fā)現(xiàn)數(shù)據(jù)庫服務器checkpoint頻率太高
優(yōu)化點:優(yōu)化checkpoint,減少IO大量讀寫的次數(shù)。增加配置:
效果:增加checkpoint配置后,checkpoint頻率過高告警已消失。
1.2.4、優(yōu)化4,autovacuum優(yōu)化
分析:大量寫入數(shù)據(jù)之后,發(fā)現(xiàn)vacuum進程持續(xù)占用CPU
優(yōu)化點:PostgreSQL數(shù)據(jù)庫自動清理機制,會自動清理過程中出現(xiàn)大量的數(shù)據(jù)掃描事件,頻繁的清理過程反而會帶來數(shù)據(jù)庫過多的性能消耗,從而導致正常業(yè)務處理資源緊張。因此對自動清理過程進行限制可以在一定程度上提高業(yè)務處理性能。增加如下配置:
效果:vacuum進程長期占用CPU現(xiàn)象消失,性能有一定提升
1.3、KingbaseES調優(yōu)及評測結果
1.3.1、優(yōu)化1,IO優(yōu)化
分析:在高并發(fā)場景下影響數(shù)據(jù)庫處理能力性能主要因素有數(shù)據(jù)庫IO消耗、服務器CPU使用效率等因素,且IO優(yōu)化是數(shù)據(jù)庫優(yōu)化手段中最常見也是最常用的。KingbaseES數(shù)據(jù)庫優(yōu)化采用了共享內存優(yōu)化、wal日志讀寫策略、IO頻率、臟頁刷盤策略等多種優(yōu)化手段以提高高并發(fā)場景下的業(yè)務處理能力。
優(yōu)化前性能統(tǒng)計:
優(yōu)化點:共享內存參數(shù)調整、wal日志策略調整、臟頁存盤策略等
效果:CPU利用率極大的提升,TPMC也相應得到了提升。
優(yōu)化后的性能統(tǒng)計:
1.3.2、優(yōu)化2,等待事件優(yōu)化
分析:觀察此時數(shù)據(jù)庫系統(tǒng)等待事件, ProcArrayGroupUpdate等待事件占據(jù)了34%的數(shù)據(jù)庫時間,存在較為嚴重的性能問題。
優(yōu)化點:優(yōu)化事務快照實現(xiàn)方式,提升數(shù)據(jù)庫并發(fā)處理能力。
優(yōu)化前系統(tǒng)top等待事件分析統(tǒng)計:
優(yōu)化后系統(tǒng)top等待事件分析統(tǒng)計:
效果:通過以上優(yōu)化前后系統(tǒng)等待事件對比,可以看出數(shù)據(jù)庫系統(tǒng)中ProcArrayGroupUpdate等待事件在優(yōu)化前占所有等待事件的34.46%,優(yōu)化后幾乎不占用系統(tǒng)CPU太長事件,較大提升了整體性能。
1.3.3、優(yōu)化3,綁核提升性能
分析:CPU通用調度模式下,進程容易因為爭搶時間片而在不同的CPU核心之間切換,由此帶來上下文切換的開銷問題,造成性能損耗。
優(yōu)化點:KingbaseES通過將每個進程均勻的綁定到CPU核心上,在高并發(fā)業(yè)務壓力下節(jié)省了進程在多CPU核之間切換帶來的開銷。
效果:調整之后,性能得到明顯提升。
1.4、經驗優(yōu)化
以上討論了對三個數(shù)據(jù)庫主要的調優(yōu)手段和結果,調優(yōu)后期,分別觀察各數(shù)據(jù)庫所在資源情況,CPU利用率上升到70-80%左右,IO和網(wǎng)絡無沒有明顯壓力。評估瓶頸優(yōu)化的方式投入產出比較低,進一步根據(jù)已有經驗進行調優(yōu)方式的確認和細節(jié)參數(shù)的微調優(yōu)化。
參考如下確認點:
1.所有的SQL執(zhí)行計劃都合理,無調整空間
2.優(yōu)化IO,使用異步IO、優(yōu)化臟頁刷盤方式
3.優(yōu)化熱點函數(shù)、非必要處理事件
4.關閉監(jiān)控系統(tǒng)
效果:CPU利用率略有提升,tpmc也隨之略有提高。
1.5、最終評測結果
基于綜上描述的調優(yōu)操作和評測,分別獲得MySQL、PostgreSQL、KingbaseES優(yōu)化后的性能指標,具體如下:
從結果上可見,在同樣的基礎環(huán)境和測試模型下,人大金倉KingbaseES產品的性能指標明顯高于PostgreSQL和MySQL。KingbaseES為何性能上能夠表現(xiàn)如此優(yōu)異,讓我們來探究下其內部的優(yōu)化技術。
2、淺談KingbaseES“黑科技”
2.1、面向NUMA架構多核優(yōu)化
2.1.1、NUMA的“前世今生”
為了尋求算力上不斷新的突破,CPU先是朝著“頻率”的方向高歌猛跟進,但隨著逐漸受到物理極限的挑戰(zhàn),轉為向核數(shù)越來越多發(fā)展,但由于所有CPU核都是通過共享一個北橋來讀取內存,核數(shù)的不斷增多帶來了北橋響應時間的瓶頸問題。于是技術人員另辟蹊徑,即將內存平均分配在各個die上,由此CPU核發(fā)展進入NUMA(Non-Uniform Memory Access)化時代,如此雖解決了原北橋讀取內存的瓶頸問題,但由于NUMA架構下存在CPU訪問本地內存的速度要比遠端內存的訪問速度快1.3–5倍,當CPU的核數(shù)越多,這種架構的內存訪問的成本開銷越大。
2.1.2、NUMA架構發(fā)展對數(shù)據(jù)庫的挑戰(zhàn)
數(shù)據(jù)庫是高并發(fā),數(shù)據(jù)訪問沖突嚴重的軟件系統(tǒng),其需要大量使用大規(guī)模共享內存,面對NUMA架構,就不可避免在運行過程中去訪問遠程內存了,在不干預情況下,數(shù)據(jù)庫內部進程會在CPU的核之間飄移,當線程運行時從一個核飄移到一個新的核上運行時,原先訪問的數(shù)據(jù)結構再次訪問時就涉及遠端訪問,從而導致訪問時延增加。
由此可見,雖然CPU的NUMA技術發(fā)展帶來了自身能力的大幅提升,但上層軟件能否有效利用,才能真正決定算力釋放的效果,縱觀IT技術棧,只有硬件、操作系統(tǒng)、數(shù)據(jù)庫軟件都要深度適配 NUMA架構,才能充分發(fā)揮出NUMA的優(yōu)勢。因此人大金倉數(shù)據(jù)庫產品KingbaseES作為企業(yè)級的商用數(shù)據(jù)庫,為了幫助用戶更高效地利用多核算力,提升數(shù)據(jù)庫的響應速度,進行了針對性的優(yōu)化。
2.1.3、線程綁核,降低訪問時延
防止線程飄移,讓其實現(xiàn)CPU核的就近訪問,這是降低訪問時延的關鍵,因此采用將線程能夠固定到具體的核上運行的方法。KingbaseES利用配置參數(shù)設定,利用操作系統(tǒng)設置親和性接口達到將線程綁定到具體NUMA節(jié)點上的效果。
同時,KingbaseES是一個客戶端服務器結構,客戶端和服務器是通過網(wǎng)絡通信來進行交互,網(wǎng)絡是一個頻繁的操作,并也會占用CPU,因此還需考慮將網(wǎng)絡中斷和業(yè)務處理進行區(qū)隔避免相互干擾,所以也對網(wǎng)絡中斷進行了綁核操作,并和后臺業(yè)務線程綁核進行區(qū)分,這樣能進一步提升利用效率,降低內耗。
2.1.4、NUMA化數(shù)據(jù)結構改造,減少跨核訪問
KingbaseES因業(yè)務處理需要,涉及很多對全局性數(shù)據(jù)結構的操作,如WALInsertLock、PGPROC等,在NUMA架構下,優(yōu)化前,此類數(shù)據(jù)結構存放在共享內存中,當出現(xiàn)高并發(fā)訪問,訪問競爭激烈時,就會存在對其跨核訪問,形成訪問遠端內存的局面,造成性能消耗。
根據(jù)以上問題,結合KingbaseES內部操作邏輯特點,并基于前文所述的線程綁核優(yōu)化,我們進行了更深層更針對性的優(yōu)化,即將操作頻繁的的全局性數(shù)據(jù)結構按照NUMA節(jié)點的數(shù)量切分為多組,并分別在對應的NUMA節(jié)點上申請內存,當某線程需要操作相關數(shù)據(jù)結構,可訪問自己所綁定的NUMA節(jié)點上本地內存的相關數(shù)據(jù)結構內容,減少了跨核的遠端訪問,提升了訪問效率。
2.2、高并發(fā)沖突環(huán)境下的并發(fā)控制算法調整,減少單點瓶頸
原模式下,每個數(shù)據(jù)庫鏈接都會維護幾個存儲當前狀態(tài)的結構,每當事務需要獲得快照時,申請共享進程鎖,遍歷所有進程?？煺招枰涗洶ó斍罢谶\行的最大事務id、下一個將要開始的事務id,以及這二者之間正在運行的所有事務和子事務id列表?；诖?在可見性判斷時可知,低于最小事務id的事務已結束,而大于最大事務id的事務視為正在運行,二者之間的事務態(tài)則需要根據(jù)列表判斷。在高并發(fā)時,對所有進程進行遍歷的時間變長,并且由于進程鎖在很多場景下需要獨占,例如下圖所示的事務結束,大量并發(fā)進程相互之間的干擾愈加不可忽視,快照獲取過程成為占比最高的部分。有鑒于此,如何最大程度的減少鎖,成為解決問題的關鍵。
根據(jù)內核事務管理系統(tǒng)狀態(tài)信息的分布特點,我們重新設計了數(shù)據(jù)結構,采用事務位圖方式展現(xiàn)事務狀態(tài)。如下圖所示,在事務開始時使用獨占進程鎖設置事務狀態(tài)位圖,結束時仍然使用獨占進程鎖消除事務狀態(tài)位圖,而在獲取快照時也仍然使用共享事務鎖,但此時不再需要遍歷進程狀態(tài)。此設計使狀態(tài)數(shù)據(jù)變得非常緊湊,能夠快速獲取事務狀態(tài),大幅降低共享鎖的持有時間。
TPCC測試中,使用200并發(fā)終端壓測,單獨驗證跟蹤查看該方案最終測試結果,快照獲取過程在整個運行期間的從占比6%以上,降低到0.2%以下。在不同平臺上,tpmC均有不同幅度的提升,其中Intel平臺大約20%,鯤鵬920平臺約有5-6%。
3、寄語
國產數(shù)據(jù)庫蟄伏40年,人大金倉從第一代創(chuàng)辦人堅信“中國也應有自己的數(shù)據(jù)庫”之初心,到如今第三代金倉人面對國內外社會形勢的變化,能扛起國產數(shù)據(jù)庫承載核心業(yè)務應用的大旗,這一路走來,我們克服了很多困難,也得到了諸多客戶的支持與肯定。未來,人大金倉將繼續(xù)砥礪前行,不斷提升用戶對我們的信心,為中國數(shù)據(jù)庫正名。
