GreenPlum應用優化案例分享

1 問題背景

GreenPlum6.9.1的應用程序移植到鯤鵬服務器上，benchmark測試發現業務吞吐量沒有達到硬件預期，需要做相應調優。

2 原因分析

BIOS配置

主要針對CPU預取等BIOS配置進行優化，提升基礎性能。

操作系統參數配置

結合網絡和IO資源進行優化。

數據庫層調優

結合熱點函數發現資源瓶頸進行升入分析調優。

3 解決方案

3.1 BIOS層調優

重啟服務器，按Esc鍵進入BIOS設置界面

1、關閉SMMU

依次進入“Advanced > MISC Config > > Support Smmu”，設置為Disabled

2、關閉CPU預取

依次進入“Advanced > MISC Config > CPU Prefetching Configuration”設置為Disabled。

3、設置PCIE max Payload size為512B

選擇“Advanced > PCIe Configure”，把所有的PCIE口Max Payload Size 設置為 512B

注意：完成BIOS各項設置后按“F10”保存退出（永久有效）

3.2 OS層優化

（1）CPU開啟性能模式

cpupower frequency-set -g performance

（2）網卡中斷綁核優化

步驟 0：查看使用網卡的物理所屬numa節點

# ethtool -i eth_name? // 找到對應的bus-info

# 根據bus-info 執行： lspci -vs 0000:02:00.0

步驟 1：停止irqbalance。

# systemctl stop irqbalance.service

# systemctl disable irqbalance.service

步驟 2：設置網卡隊列個數為CPU的核數，如48。

# ethtool -L eth_name combined 48

步驟 3：查詢中斷號。

# cat /proc/interrupts | grep $ eth_name | awk -F ':' '{print $1}'

步驟 4：根據中斷號，將每個中斷分別綁定在一個核上，其中cpuID為0表示core0。

# echo $cpuID? >? /proc/irq/$irq/smp_affinity_list

//如對于中斷號是1298 è1329(32個隊列綁定在0-31的core上)，可使用如下命令簡化設置

# for((i=1298; i <=1298+31;i++));do echo $(((${i} - 1298))) > /proc/irq/${i}/smp_affinity_list;done

//查看設置是否成功

# for((i=1298; i <=1298+31;i++));do cat /proc/irq/${i}/smp_affinity_list;done

（3）設置網卡中斷聚合參數，減少網絡時延

ethtool -c eth_name? // 查看當前配置

// 設置中斷聚合，使更快響應網絡請求，各參數根據場景需要調整到最佳值

ethtool -C enp125s0f0? adaptive-rx off adaptive-tx off rx-usecs 10 tx-usecs 10 rx-frames 10 tx-frames 10

（4）IO調度策略調優

cat? deadline或noop > /sys/block/${device}/ queue/scheduler

當使用的HDD盤時，使用deadline調度策略，使用SSD盤時，優先使用noop調度策略。(針對數據盤操作)

3.3 GreenPlum數據庫層調優

（1）數據庫內置參數調優

對于GreenPlum數據庫調優，可優先在子節點配置多個segement，segment數越多時每個節點上運行的Postgres進程也越多，類似于每個節點上會有多實例Pg數據庫，適合發揮鯤鵬的多核優化，其次還可以基于GreenPlum的數據庫參數進行適當優化。

gp_set_proc_affinity

該參數可以設置segment進程和主節點進程的cpu親和性，在數據庫啟動時進行自動綁核。默認為off狀態，推薦對子節點的segment進程綁核，主節點不綁核。

Host節點關閉：gp_set_proc_affinity? off

segment節點打開：gp_set_proc_affinity on

注：還有一些進程共享參數的設置可參考解決鯤鵬Boostkit數據庫調優文檔，(https://support.huaweicloud.com/tngg-kunpengdbs/kunpenggreenplum_05_0015.html)

（2）鯤鵬加速庫優化手段

Postgres使用到的壓縮庫為zstd，可以通過perf top查看當前的sql測試場景是否zstd壓縮/解壓縮成為熱點，如果是則可以使用加速庫zstd進行優化。

現場觀察到zstd的相關熱點函數占比較高，可進行針對性優化。

優化方法：

下載編譯zstd: https://github.com/kunpengcompute/zstd

進行編譯，將libzstd.so.1.4.4文件拷貝到系統目錄/lib64/路徑下，創建并覆蓋libzstd對應軟連接，運行時可觀測熱點調用的zstd加速庫版本確認是否生效。

（3）低版本CRC熱點函數優化（源碼）

現象：熱點：pg_comp_crc32c_sb8?? 集中在靜態庫：all: libpgport.a?? libpgport_srv.a

pg_comp_crc32c_sb8 這個函數有8%的熱點；

src/include/port/pg_crc32c.h:60:extern pg_crc32c pg_comp_crc32c_sb8(pg_crc32c crc, const void *data, size_t len);

src/include/port/pg_crc32c.h:72:??????? ((crc) = pg_comp_crc32c_sb8((crc), (data), (len)))

src/include/port/pg_crc32c.h:89:extern pg_crc32c pg_comp_crc32c_sb8(pg_crc32c crc, const void *data, size_t len);

src/port/pg_crc32c_choose.c:58:???????? pg_comp_crc32c = pg_comp_crc32c_sb8;

修改src/port/pg_crc32c_sb8.c文件內容

優化：

Postgres數據庫在11版本及以后才增加了armv8的crc等特性，對鯤鵬支持相對友好，在選用GreenPlum數據庫版本時，優先推薦客戶使用內核為Postgres 11及以后的版本。如果是內核數據庫是低于postgre11版本，可采用將高版本中的src/port/pg_crc32c_armv8.c文件進行回合，優化crc為硬算模式。（回合后需要在configure中對CFLAGS增加-march=armv8-a+crc）

（4）高并發查詢時主節點s_lock熱點函數占用高場景優化

Perf top觀測到的s_lock熱點函數：

由于GreenPlum對于鎖沒有相關數據庫配置參數調整，需在src/backend/storage/lmgr/s_lock.c文件修改spins_per_delay變量參數，減少自旋鎖爭搶程度，可根據實際并發情況調整，調整直到s_lock熱點函數占用在預期范圍即可。調整確定spins_per_delay變量時，需要同步測試其他場景(如insert、update等)，避免過于追求單查詢TPS，導致其他場景性能下降過大，綜合各測試場景找到該參數的一個合理值。

修改代碼行實例(參數值僅供參考，需結合實際情況設定)：

4 總結

綜上，調優相關思路總結如下：

熟悉業務數據流，了解整個大致原理及數據走向

檢查對齊硬件配置資源

觀察性能瓶頸點，不忽略任何可疑點

剖析組件原理，尋找新的優化措施

避免參數組合循環嘗試優化，先做原理性分析再下手

任務調度 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。