https://www.modb.pro/db/29135
概述
本文描述了openGauss數據庫基於Taishan服務器，在openEuler操作系統上，爲了達到數據庫的極致性能，所依賴的關鍵系統級調優配置。
硬件規格：
CPU: 鯤鵬-920(1620) ARM aarch64 64核 * 2
內存: >=512G
磁盤: Nvme SSD * 4(每塊大於1TB)
網卡: 1822網卡 萬兆網卡 Ethernet controller: Huawei Technologies Co., Ltd. Hi1822 Family (4*25GE) (rev 45)
軟件規格：
操作系統: openEuler 20.03 (LTS)
數據庫: openGauss 1.0.0
Benchmark: benchmarksql-5.0
jdk: jdk1.8.0_212
ant: apache-ant-1.9.15
文章通過配置BIOS、操作系統、文件系統、網絡、綁核，構造TPCC測試數據等幾個方面來對數據庫進行調優。- 依賴三方工具 jdk ant benchmark - linux工具 htop iostat.
benchmark htop iostat工具的安裝使用請參照：benchmark使用。（https://opengauss.org/zh/blogs/blogs.html?post/optimize/opengauss-tpcc/）
BIOS配置
登錄服務器管理系統，重啓服務器進入BIOS界面，修改BIOS相關配置並重啓 (服務器管理系統以實際爲準)。
1.機器自檢後，會提示啓動選項
2.按“Del”鍵，進入BIOS
3.輸入BIOS密碼
4.恢復出廠設置
按下“F9”，恢復出廠設置
重要：因爲現有的BIOS可能被改動過諸多默認設置，爲保險起見，建議首先恢復出廠設置。
5. 修改相關BIOS設置
修改包括下面三項配置
# BIOS->Advanced->MISC Config，配置Support Smmu爲Disabled
# BIOS->Advanced->MISC Config，配置CPU Prefetching Configuration爲Disabled
# BIOS->Advanced->Memory Config，配置Die Interleaving爲Disable
6. 保存相關BIOS設置，並重啓
按“F10”保存並退出，重新啓動系統。
操作系統配置
優化操作系統相關配置
Irq balance關閉：爲避免gaussdb進程與客戶端搶用CPU，導致CPU使用不均衡。如果htop呈現出部分CPU壓力很大，部分CPU很空閒時需要考慮是否關閉了irqbalance.
service irqbalance stop
echo 0 > proc/sys/kernel/numa_balancing
echo 'never' > sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > sys/kernel/mm/transparent_hugepage/defrag
echo none > sys/block/nvme*n*/queue/scheduler ## 針對nvme磁盤io隊列調度機制設置
文件系統配置
修改xfs文件系統blocksize爲8K
<1> 確認nvme盤對應加載點的現有blocksize 下面命令查看當前掛載的nvme盤
df -h | grep nvme
/dev/nvme0n1 3.7T 2.6T 1.2T 69% data1
/dev/nvme1n1 3.7T 1.9T 1.8T 51% data2
/dev/nvme2n1 3.7T 2.2T 1.6T 59% data3
/dev/nvme3n1 3.7T 1.4T 2.3T 39% data4
xfs_info命令可以查看nvme盤的信息
xfs_info data1
上圖中block的大小正好爲8K, 不需要修改。若不滿足8k塊大小的要求, 需要重新格式, 格式化前注意數據的備份。
<2> 針對需要格式化的磁盤，備份所需的數據
用戶注意根據需要，將所需數據備份至其他磁盤或其他機器。
<3> 重新格式化磁盤，設置block大小8k
以/dev/nvme0n1盤，加載點爲/data1爲例，相關參考命令如下：
umount /data1
mkfs.xfs -b size=8192 /dev/nvme0n1 -f
mount /dev/nvme0n1 /data1
<4> 再次用xfs_info命令確認blocksize是否修改正確。
網絡配置
1. 多中斷隊列設置
針對泰山服務器核數較多的特徵，產品需要在服務器端和客戶端設置網卡多隊列。當前推薦的配置爲：服務器端網卡配置16中斷隊列，客戶端網卡配置48中斷隊列。
多中斷隊列設置工具(1822-FW)
Hi1822網卡發佈版本可以從如下鏈接獲取，IN500 solution 5.1.0.SPC401及之後正式支持設置多隊列： https://support.huawei.com/enterprise/zh/intelligent-accelerator-components/in500-solution-pid-23507369/software.
<1> 解壓Hi1822-NIC-FW.zip, 進入目錄，在root用戶下安裝hinicadm.
<2> 確定當前連接的物理端口是哪個網卡的，不同硬件平臺這個網口和網卡名有差別。以如下示例機器爲例，當前使用enp3s0的小網網口，屬於hinic0網卡。
<3> 進入config目錄， 利用配置工具hinicconfig配置中斷隊列FW配置文件：
64隊列配置文件：std_sh_4x25ge_dpdk_cfg_template0.ini；
16隊列配置文件：std_sh_4x25ge_nic_cfg_template0.ini；
對hinic0卡配置爲不同隊列數（默認16隊列，可以按需要調整）
./hinicconfig hinic0 -f std_sh_4x25ge_dpdk_cfg_template0.ini
重啓操作系統生效，輸入命令ethtool -l enp3s0查看（比如下圖表示修改爲(32)
修改combined的值，輸入命令ethtool -L enp3s0 combined 48（不同平臺，不同應用的優化值可能不同，當前128核平臺，服務器端調優值爲16，客戶端調優值爲48）。
2. 中斷調優
在openGauss數據庫滿跑的情況下（CPU佔比90%以上），CPU成爲瓶頸，開啓offloading，將網絡分片offloading到網卡上
ethtool –K enp3s0 tso on
ethtool –K enp3s0 lro on
ethtool –K enp3s0 gro on
ethtool –K enp3s0 gso on
以1620平臺爲例，網卡中斷綁定每個numa node中最後4個core，每個core綁定3箇中斷。綁核中斷腳本如下所示，此腳本將在openGauss安裝的時候在gs_preinstall被調用，具體執行步驟請查看產品安裝說明書：
sh bind_net_irq.sh 16
3. 網卡固件確認與更新
確認當前環境的小網網卡固件版本是否爲2.5.0.0
ethtool -i enp3s0
driver: hinic
version: 2.3.2.11
firmware-version: 2.5.0.0
expansion-rom-version:
bus-info: 0000:03:00.0
如果是2.5.0.0，建議更換爲2.4.1.0，以獲得更佳性能。
網卡固件更新步驟
<1> 上傳網卡固件驅動至服務器 Hi1822_nic_prd_1h_4x25G.bin
<2> 使用root執行如下命令
hinicadm updatefw -i <物理網卡設備名> -f <固件文件路徑>
其中，“物理網卡設備名”爲網卡在系統中的名稱，例如“hinic0”表示第一張網卡，“hinic1”表示第二張網卡，查找方法參見前文“多中斷隊列設置”。例如：
# hinicadm updatefw -i <物理網卡設備名> -f <固件文件路徑>
Please do not remove driver or network device
Loading...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] [100%] [\]
Loading firmware image succeed.
Please reboot OS to take firmware effect.
<3> 重啓服務器，再確認小網網卡固件版本成功更新爲2.4.1.0
ethtool -i enp3s0
driver: hinic
version: 2.3.2.11
firmware-version: 2.4.1.0
expansion-rom-version:
bus-info: 0000:03:00.0
確認小網網卡固件版本成功更新成功。
數據庫服務端及客戶端綁核
安裝數據庫, 具體參考openGauss安裝文檔。
大概步驟如下：
◾ 停止數據庫
◾ 修改postgresql.conf參數
◾ 以綁核方式啓動數據庫： numactl --interleave=all bin/gaussdb -D ${DATA_DIR} --single_node
◾ 以綁核方式啓動benchmark： numactl -C 0-19,32-51,64-83,96-115 ./runBenchmark.sh props.pg
按照自己的綁核配置和benchmark配置文件執行此命令。這裏的綁核參數是在數據庫綁核參數的空隙。
1. 服務器端綁核設置
<1> 業務進程在運行過程中，硬件上報的網絡中斷會導致頻繁的上下文切換，嚴重影響效率，因此需要將網絡中斷和業務分開綁定在不同的核上運行，網絡中斷綁核請查看上一節。
<2> 當前openGauss中引入了線程池機制，即數據庫啓動時，線程池將創建指定數目的線程來服務，線程在創建時會進行綁核，因此需要將網卡的綁核信息通過 GUC 參數傳入，方便運行期間綁核設置。以128核爲例，對應參數如下圖：
其中線程總數爲（cpu總數128 - 處理網絡的cpu數目16）* 每個核上線程數（經驗值推薦7.25） = (128-16)*7.25 = 812，numa節點數爲4，處理中斷的核數爲16。
如下爲輔助分配綁定CPU：
numactl -C 0-27,32-59,64-91,96-123 gaussdb --single_node -D {DATA_DIR} -p {PORT} &
或者：
numactl --interleave=all gaussdb --single_node -D {DATA_DIR} -p {PORT} &
2. 服務器端參數設置
postgresql.conf中新增如下參數：- advance_xlog_file_num = 10
此參數表示後臺線程BackgroundWALWriter週期性地提前檢測並初始化未來10個XLog文件，避免事務提交時纔去執行XLog文件初始化，從而降低事務提交時延。只有在性能壓力測試時作用纔會體現出來，一般不用配置。默認爲0，即不進行提前初始化。- numa_distribute_mode = 'all'
此參數目前有all和none兩個取值。all表示啓用NUMA優化，將工作線程和對應的PGPROC、WALInsertlock進行統一分組，分別綁定到對應的NUMA Node下，以減少關鍵路徑上的CPU遠端訪存。默認取值爲none，表示不啓用NUMA分佈特性。只有在涉及到多個NUMA節點，且遠端訪存代價明顯高於本地訪存時使用。當前建議在性能壓力測試情況下開啓。
thread_pool_attr線程池配置
thread_pool_attr = '812,4,(cpubind: 0-27,32-59,64-91,96-123)'
相關參數：
max_connections = 4096
allow_concurrent_tuple_update = true
audit_enabled = off
checkpoint_segments = 1024
checkpoint_timeout = 15min
cstore_buffers = 16MB
enable_alarm = off
enable_codegen = false
enable_data_replicate = off
full_page_writes = on
max_files_per_process = 100000
max_prepared_transactions = 2048
shared_buffers = 350GB
use_workload_manager = off
wal_buffers = 1GB
work_mem = 1MB
log_min_messages = FATAL
transaction_isolation = 'read committed'
default_transaction_isolation = 'read committed'
synchronous_commit = on
fsync = on
maintenance_work_mem = 2GB
vacuum_cost_limit = 2000
autovacuum = on
autovacuum_mode = vacuum
autovacuum_max_workers = 5
autovacuum_naptime = 20s
autovacuum_vacuum_cost_delay = 10
xloginsert_locks = 48
update_lockwait_timeout = 20min
enable_mergejoin = off
enable_nestloop = off
enable_hashjoin = off
enable_bitmapscan = on
enable_material = off
wal_log_hints = off
log_duration = off
checkpoint_timeout = 15min
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_scale_factor = 0.02
enable_save_datachanged_timestamp = false
log_timezone = 'PRC'
timezone = 'PRC'
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
enable_thread_pool = on
thread_pool_attr = '812,4,(cpubind:0-27,32-59,64-91,96-123)'
enable_double_write = off
enable_incremental_checkpoint = on
enable_opfusion = on
advance_xlog_file_num = 10
numa_distribute_mode = 'all'
track_activities = off
enable_instr_track_wait = off
enable_instr_rt_percentile = off
track_counts = on
track_sql_count = off
enable_instr_cpu_timer = off
plog_merge_age = 0
session_timeout = 0
enable_instance_metric_persistent = off
enable_logical_io_statistics = off
enable_page_lsn_check = off
enable_user_metric_persistent = off
enable_xlog_prune = off
enable_resource_track = off
instr_unique_sql_count=0
enable_beta_opfusion=on
enable_beta_nestloop_fusion=on
3. TPCC客戶端綁核設置
客戶端通過 numactl 將客戶端綁定在除網卡外的核上，下圖以 128 核環境舉例，共80個核用於處理業務邏輯，剩餘48個核處理網絡中斷。
對應tpmc程序應該使用爲：
numactl -C 0-19,32-51,64-83,96-115 ./runBenchmark.sh props.pg
其他核用來處理網絡中斷。
構建TPCC初始數據
1. 修改benchmark配置
複製props.pg並重命名爲props.opengauss.1000w，編輯該文件，將如下配置覆蓋到文件裏面：
cp props.pg props.opengauss.1000w
vim props.opengauss.1000w
db=postgres
driver=org.postgresql.Driver
// 修改連接字符串, 包含ip, 端口號, 數據庫
conn=jdbc:postgresql://ip:port/tpcc1000?prepareThreshold=1&batchMode=on&fetchsize=10
// 設置數據庫登錄用戶和密碼
user=user
password=******
warehouses=1000
loadWorkers=200
// 設置最大併發數量, 跟服務端最大work數對應
terminals=812
//To run specified transactions per terminal- runMins must equal zero
runTxnsPerTerminal=0
//To run for specified minutes- runTxnsPerTerminal must equal zero
runMins=5
//Number of total transactions per minute
limitTxnsPerMin=0
//Set to true to run in 4.x compatible mode. Set to false to use the
//entire configured database evenly.
terminalWarehouseFixed=false
//The following five values must add up to 100
//The default percentages of 45, 43, 4, 4 & 4 match the TPC-C spec
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4
// Directory name to create for collecting detailed result data.
// Comment this out to suppress.
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
osCollectorScript=./misc/os_collector_linux.py
osCollectorInterval=1
// 收集OS負載信息
//osCollectorDevices=net_enp3s0 blk_nvme0n1 blk_nvme1n1 blk_nvme2n1 blk_nvme3n1
2. TPCC導入數據前準備
<1> 替換tableCreats.sql文件
下載文件tableCreates.sql (https://blog.opengauss.org/zh/post/optimize/images/tableCreates.sql)。 使用該文件替換benchmarkSQL中路徑 benchmarksql-5.0/run/sql.common/ 下的對應文件。
該文件主要做了如下修改：
◾增加了兩個表空間
CREATE TABLESPACE example2 relative location 'tablespace2';
CREATE TABLESPACE example3 relative location 'tablespace3';
◾ 刪除序列bmsql_hist_id_seq
◾ 給每一個表增加FACTOR屬性
create table bmsql_stock (
s_w_id integer not null,
.....
s_dist_10 char(24)
) WITH (FILLFACTOR=80) tablespace example3;
<2> 修改索引indexCreates.sql
修改run/sql.common/indexCreates.sql文件
修改上圖中紅框中的內容如下：
在該文件中添加下圖中紅色內容，可以在benchmark自動生成數據的時候自動生成到不同的數據表空間，如果未添加可以在benchmark生成數據之後再數據庫端修改，用於分盤。
<3> 修改runDatabaseBuild.sh文件 修改下圖內容可避免生產數據時候的外鍵不支持錯誤。
3. 導入數據
運行runDatabaseBuild.sh導入數據
4. 數據備份
爲了方便多次測試, 減少導數據的時間, 可以將導好的數據備份, 一種常用的做法是: 停止數據庫, 將整個數據目錄做一次拷貝。恢復時參考腳本如下：
#!/bin/bash
rm -rf /ssd/omm108/gaussdata
rm -rf /usr1/omm108dir/tablespace2
rm -rf /usr2/omm108dir/tablespace3
rm -rf /usr3/omm108dir/pg_xlog
cp -rf /ssd/omm108/gaussdatabf/gaussdata /ssd/omm108/ &
job0=$!
cp -rf /usr1/omm108dir/tablespace2bf/tablespace2 /usr1/omm108dir/ &
job1=$!
cp -rf /usr2/omm108dir/tablespace3bf/tablespace3 /usr2/omm108dir/ &
job2=$!
cp -rf /usr3/omm108dir/pg_xlogbf/pg_xlog /usr3/omm108dir/ &
job3=$!
wait $job1 $job2 $job3 $job0
5. 數據分盤
在性能測試過程中, 爲了增加IO的吞吐量, 需要將數據分散到不同的存儲介質上。由於我們機器上有4塊NVME盤, 可以將數據分散到不同的盤上。我們主要將pg_xlog, tablespace2, tablespace3這三個目錄放置在其他3個NVME盤上, 並在原有的位置給出指向真實位置的軟連接. pg_xlog位於數據庫目錄下, tablespace2, tablespace3分別位於數據庫目錄pg_location下。對tablespace2分盤的示例命令如下：
mv $DATA_DIR/pg_location/tablespace2 $TABSPACE2_DIR/tablespace2
cd $DATA_DIR/pg_location/
ln -svf $TABSPACE2_DIR/tablespace2 ./
6. 運行TPCC程序
numactl –C 0-19,32-51,64-83,96-115 ./runBenchmark.sh props.opengauss.1000w
7. 性能監控
使用htop監控數據庫服務端和tpcc客戶端CPU利用情況, 極限性能測試情況下, 各個業務CPU的佔用率都非常高(> 90%), 若有CPU佔用率沒有達標, 可能是綁核方式不對, 需要進行調整
上圖中黃線框中的是處理網絡中斷的CPU.
8. 調優後的監控狀態
經過調優後的htop狀態呈現這種狀態是比較可靠的狀態
數據庫調優是一個繁瑣的工作，需要不斷去修改配置，運行TPCC，反覆去調試以達到最優性能配置。
TPCC運行結果：
