GreenPlum高并發(fā)查詢鎖優(yōu)化

1.1 GreenPlum簡(jiǎn)介

Greenplum數(shù)據(jù)庫(kù)是一種大規(guī)模并行處理（MPP）數(shù)據(jù)庫(kù)服務(wù)器，其架構(gòu)特別針對(duì)管理大規(guī)模分析型數(shù)據(jù)倉(cāng)庫(kù)以及商業(yè)智能工作負(fù)載而設(shè)計(jì)。Greenplum數(shù)據(jù)庫(kù)是基于PostgreSQL開源技術(shù)的。它本質(zhì)上是多個(gè)PostgreSQL面向磁盤的數(shù)據(jù)庫(kù)實(shí)例一起工作形成的一個(gè)緊密結(jié)合的數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）。

其組網(wǎng)中通常會(huì)有一個(gè)主節(jié)點(diǎn)和standby主節(jié)點(diǎn)，同時(shí)分布著多個(gè)子節(jié)點(diǎn)（segment節(jié)點(diǎn)）。主節(jié)點(diǎn)只負(fù)責(zé)查詢?nèi)蝿?wù)的解析及分發(fā)，不存儲(chǔ)和處理數(shù)據(jù)，子節(jié)點(diǎn)將數(shù)據(jù)分布式存儲(chǔ)進(jìn)行并行查詢，并反饋查詢結(jié)果及狀態(tài)到主節(jié)點(diǎn)。

GreenPlum分布式數(shù)據(jù)庫(kù)運(yùn)行流程大致如下：

1、client端由libpq協(xié)議連接master節(jié)點(diǎn)，master節(jié)點(diǎn)創(chuàng)建QD進(jìn)程進(jìn)行SQL解析等，生成查詢計(jì)劃

2、QD進(jìn)程通過libpq協(xié)議與各子節(jié)點(diǎn)連接，分發(fā)查詢?nèi)蝿?wù)，子節(jié)點(diǎn)再創(chuàng)建QE進(jìn)程執(zhí)行SQL查詢?nèi)蝿?wù)

3、各子節(jié)點(diǎn)QE進(jìn)程查詢結(jié)果由interconnect匯總返回至QD進(jìn)程

4、QD進(jìn)程通過libpq將匯總結(jié)果返回客戶端

更多信息可在官網(wǎng)主頁(yè)https://cn.greenplum.org/獲取。

在GreenPlum數(shù)據(jù)庫(kù)查詢場(chǎng)景，會(huì)出現(xiàn)s_lock熱點(diǎn)函數(shù)，影響鯤鵬服務(wù)器上查詢性能，需進(jìn)一步進(jìn)行優(yōu)化。

1.2 軟硬件配置信息

數(shù)據(jù)庫(kù)版本：GreenPlum 6.9.1?????????? 操作系統(tǒng)：Centos7.6

硬件配置信息如下：

配置項(xiàng)

鯤鵬

X86

CPU型號(hào)

Kunpeng 5230

Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz

內(nèi)存

256G

256G

磁盤（數(shù)據(jù)盤）

500G HDD

500G HDD

均采用單機(jī)模式，一個(gè)主節(jié)點(diǎn)，子節(jié)點(diǎn)配置4個(gè)segment，無standby節(jié)點(diǎn)。

1.3 性能優(yōu)化

1.3.1 S_lock熱點(diǎn)函數(shù)復(fù)現(xiàn)

1、生成測(cè)試數(shù)據(jù)

通過pagebnech測(cè)試工具，執(zhí)行以下命令生成14GB的測(cè)試數(shù)據(jù)：

# 其中-F參數(shù)為裝填因子，-s值得是比例因子，比例因子越大，測(cè)試數(shù)據(jù)集也越大

pgbench -i -F 100 -s 1000 -p port -h con_addr -U postgres postgres

如：pgbench -h master -U gpadmin -p 5432 -c 100 -j 100 ?-S? -T 60 -r postgres

2、執(zhí)行壓測(cè)命令

執(zhí)行以下命令進(jìn)行壓測(cè)：

pgbench -h con_addr -p port -r -n -c 100 -j 100 -T 60 -S -U postgres postgres

3、壓測(cè)現(xiàn)象如下

100并發(fā)壓測(cè)結(jié)果：TPS 為805左右

進(jìn)一步看到熱點(diǎn)函數(shù)非常集中，s_lock占比達(dá)到82.42%

此時(shí)CPU資源消耗99%，主要集中在s_lock函數(shù)上

1.3.2 優(yōu)化分析

問題分析

通過s_lock熱點(diǎn)函數(shù)復(fù)現(xiàn)可以看到，s_lock函數(shù)已成為當(dāng)前瓶頸點(diǎn)，是優(yōu)化的核心點(diǎn)。

默認(rèn)GreenPlum編譯后是release版本，調(diào)試時(shí)無法看到詳細(xì)信息，為了跟蹤s_lock形成原因及進(jìn)一步優(yōu)化，需重新編譯debug版本。

編譯GreenPlum的Debug版本

# 重新編譯debug版本

./configure --with-perl --with-python --with-libxml --prefix=/usr/local/gpdb-debug --enable-debugntuplestore? --enable-debug? --enable-debug-extensions

make -j32make install

調(diào)用棧分析

完成debug版本編譯后，重新運(yùn)行數(shù)據(jù)庫(kù)并進(jìn)行壓測(cè)，壓測(cè)同時(shí)用gdb進(jìn)行跟蹤調(diào)試

gdb attach -p postgres-PID? #可進(jìn)行多次嘗試，直到atach到的函數(shù)停留在s_lock

然后執(zhí)行 bt 命令打印調(diào)用棧：

結(jié)合調(diào)用?？梢园l(fā)現(xiàn)，最終會(huì)調(diào)用tas函數(shù)去完成s_lock函數(shù)功能，進(jìn)入tas函數(shù)所在文件路徑gpdb\src\include\storage\s_lock.h，tas在arm分枝下的實(shí)現(xiàn)：

核心問題轉(zhuǎn)化為優(yōu)化tas實(shí)現(xiàn)，提升鎖的性能。

TAS函數(shù)優(yōu)化

Tas是test and set的縮寫，該操作是實(shí)現(xiàn)一種不可中斷的原子運(yùn)算，對(duì)嘗試的變量進(jìn)行賦值操作，通常是置1，如果失敗則重試，最后返回之前的舊值。

代碼中tas的實(shí)現(xiàn)調(diào)用了gcc內(nèi)存的tas原子操作 __sync_lock_test_and_set，編寫相關(guān)測(cè)試代碼觀察函數(shù)的匯編實(shí)現(xiàn)如下：

mov???? w1, 1

.L3:

ldxr??? w2, [x0]

stxr??? w3, w1, [x0]

cbnz??? w3, .L3

dmb???? ish

匯編中可以看到，由于ldxr+stxr指令并不能保存內(nèi)存一致性，從而需要內(nèi)存屏障指令dmb ish配合來實(shí)現(xiàn)內(nèi)存一致性，該內(nèi)存屏障指令將帶來性能上的損失。

CAS實(shí)現(xiàn)優(yōu)化分析

CAS需要3個(gè)參數(shù)，一個(gè)內(nèi)存位置(ptr)，一個(gè)期望舊值(old_value)，一個(gè)待寫入內(nèi)存的新值(new_value)，過程大致是：

比較內(nèi)存值*ptr是否與olad_value相等

如果相等，則用新值new_value一直重試寫入

如果不相等，不做任何操作

無論哪種情況，CAS最終返回值是內(nèi)存ptr的原始值

使用ldaxr+stlxr兩條指令實(shí)現(xiàn)原子操作時(shí)，可以同時(shí)保證內(nèi)存一致性，相比以上方式更加高效。同時(shí)分析可以發(fā)現(xiàn)，TAS是直接寫操作，CAS是先比較，滿足條件 后再寫。而寫是一個(gè)相對(duì)耗時(shí)的操作，因此在高并發(fā)、頻繁使用鎖的場(chǎng)景，CAS性能會(huì)更好。

綜合以上分析，使用內(nèi)嵌匯編方式重新實(shí)現(xiàn)Tas函數(shù)：https://github.com/greenplum-db/gpdb/pull/12848/files

優(yōu)化后100并發(fā)運(yùn)行時(shí)TPS 3800，整體熱點(diǎn)函數(shù)占用也下降到38%。

LSE編譯選項(xiàng)優(yōu)化分析

LL/SC(Load-link/Store-condition)原子指令需要把共享變量先load到本核所在的L1cache中進(jìn)行修改，在鎖競(jìng)爭(zhēng)少的情況下性能較好，但在鎖競(jìng)爭(zhēng)激烈時(shí)會(huì)導(dǎo)致系? ? ? ? ?統(tǒng)性能下降嚴(yán)重。ARMv8.1規(guī)范中引入了新的原子操作指令擴(kuò)展LSE（Large SystemExtensions），將計(jì)算操作放到L3 cache去做，增大數(shù)據(jù)共享范圍，減少 cache一致性耗時(shí)，在鎖競(jìng)爭(zhēng)激烈時(shí)可以提升鎖的性能。

在Configure文件添加以下編譯選項(xiàng)重新編譯：

CFLAGS="-march=armv8-a+lse"

CXXFLAGS="-march=armv8-a+lse"

實(shí)際測(cè)試發(fā)現(xiàn)該編譯選項(xiàng)可以降低熱點(diǎn)函數(shù)占用，但性能基本無提升：

（1）100并發(fā)下CAS優(yōu)化+ LSE 編譯選項(xiàng)后熱點(diǎn)函數(shù)CAS進(jìn)一步下降到27%，但TPS也由3652下降到2985，性能弱化了。

（2）不做CAS優(yōu)化，使用原有的TAS+LSE編譯選項(xiàng)優(yōu)化后，熱點(diǎn)函數(shù)占比由83%下降到77.8%，同時(shí)TPS 也由805下降到577，性能也劣化了。

初步分析看，當(dāng)前GreenPlum場(chǎng)景下，鯤鵬LSE編譯選項(xiàng)優(yōu)化有負(fù)向效果，暫不采用。

1.3.3 優(yōu)化措施

已在GreenPlum開源社區(qū)提交PR進(jìn)行全量測(cè)試，PR review中，待合入；相關(guān)優(yōu)化代碼可參考PR #12848：improv spinlock(TAS) performance on aarch64 platform, such as kunpeng

1.4 優(yōu)化前后測(cè)試結(jié)果

鎖優(yōu)化后，鯤鵬平臺(tái)上性能平均提升383.47%，較x86性能平均領(lǐng)先108.92%。

任務(wù)調(diào)度 數(shù)據(jù)庫(kù)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。