TPC-B測試：Greenplum 6版本比5版本到底好了多少？

pgbench 簡介:

pgbench是一種在PostgreSQL上運行基準測試的簡單程序。它可能在併發的數據庫會話中一遍一遍地運行相同序列的 SQL 命令，而且計算平均事務率（每秒的事務數）。默認狀況下，pgbench會測試一種基於 TPC-B 可是要更寬鬆的場景，其中在每一個事務中涉及五個SELECT、UPDATE以及INSERT命令。可是，經過編寫本身的事務腳本文件很容易用來測試其餘狀況。

使用方法

pgbench [OPTION]... [DBNAME]

初始化選項

-i, --initialize         調用初始化模式
-F, --fillfactor=NUM     設置填充因數
-n, --no-vacuum          初始化後不運行vacuum
-q, --quiet              安靜模式
-s, --scale=NUM          比例因子

標準選項

-c, --client=NUM           數據庫客戶端併發數量(默認值:1)
-C, --connect              爲每一個事務創建新的鏈接
-D, --define=VARNAME=VALUE 定義自定義腳本使用的變量
-f, --file=FILENAME        從文件名中讀取事務腳本
-j, --jobs=NUM             線程數(默認爲1)
-l, --log                  寫入日誌文件
-L, --latency-limit=NUM    將持續時間超過毫秒(ms)的事務算做延遲
-M, --protocol=simple|extended|prepared 提交查詢的協議(默認:simple)
-n, --no-vacuum            測試前不要運行vacuum
-N, --skip-some-updates    跳過pgbench_tellers和pgbench_branches的更新
-P, --progress=NUM         每隔指定秒顯示線程進度報告
-r, --report-latencies     報告每一個命令的平均延遲
-R, --rate=NUM             每秒事務的目標速率
-s, --scale=NUM            在輸出中報告這個比例因子
-S, --select-only          執行只讀查詢
-t, --transactions=NUM     每一個客戶端運行的事務數(默認爲10)
-T, --time=NUM             基準測試持續時間(秒)
-v, --vacuum-all           測試前vacuum所有4張標準表

硬件環境

數量

3臺服務器

型號

華爲2488H V5

CPU

4*16核  Intel Xeon 6130 2.10GHz

存儲

2*480GB SSD 、22*1.2T SAS

內存

1T(33*32 GB)  2666MHz DDR4

網口

2塊雙口千兆、2塊雙口萬兆以太網卡

Linux發行版

Red Hat Enterprise Linux Server release 7.5

Linux內核

3.10.0-862.el7.x86_64

環境配置

GP版本

Greenplum6.2.1

Greenplum5.20

內核版本

PostgreSQL 9.4.24

PostgreSQL 8.3.23

環境配置

Master:mas01 Segment:mas0一、mas0二、seg08

集羣參數設置

Greenplum6

gpconfig -c 'optimizer' -v off
gpconfig -c 'gp_enable_global_deadlock_detector' -v on
gpconfig -c 'resource_scheduler' -v off
gpconfig -c log_statement -v none
gpconfig -c checkpoint_segments -v 2 --skipvalidation

Greenplum5

gpconfig -c 'optimizer' -v off
gpconfig -c 'resource_scheduler' -v off
gpconfig -c log_statement -v none
gpconfig -c checkpoint_segments -v 2 --skipvalidation

參數說明

gp_enable_global_deadlock_detector

此GUC用於控制是否開啓全局死鎖檢測功能，在Greenplum 6中其默認關閉，須要打開它才能夠支持併發更新/刪除操做；Greenplum 5並不支持此GUC。

log_statement

此GUC減小沒必要要的日誌，避免日誌輸出對I/O性能的干擾。

checkpoint_segments

此GUC影響checkpoint主動刷盤的頻率，默認值8會下降刷盤頻率，可是每次刷盤的數據量較大，致使整個集羣瞬時的性能降低。針對OLTP大量更新類語句適當調小此設置會增長刷盤頻率，但因爲每次刷盤數據量變小，平均性能會有較明顯提高；Greenplum 5支持此GUC可是並沒有明顯效果，這是因爲Greenplum 5的性能瓶頸並不在於I/O，而是在表鎖致使的串行化。

測試方法

數據庫創建test庫，採用pgbench進行，數據規模爲1000倍，持續60秒進行測試。

• 初始化命令

pgbench -h mas01 -U gpadmin6 -p 6666 -i -s 1000 test

• 基準測試命令

pgbench -h mas01 -U $user -p $port -c $N -T 60 -r test

• 單查詢測試命令

pgbench -h mas01 -U $user -p $port -c $N -S -T 60 -r test

• 單更新測試命令

pgbench -h mas01 -U $user -p $port -c $N -S -T 60 -r test -f update.sql
# vi update.sql
\set naccounts 100000 * :scale
\setrandom aid 1 :naccounts
\setrandom delta -5000 5000
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
END;

• 單插入測試命令

pgbench -h mas01 -U $user -p $port -c $N -S -T 60 -r test -f insert.sql
# vi insert.sql
\set nbranches 1 * :scale
\set ntellers 10 * :scale
\set naccounts 100000 * :scale
\setrandom aid 1 :naccounts
\setrandom bid 1 :nbranches
\setrandom tid 1 :ntellers
\setrandom delta -5000 5000
BEGIN;
INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
END;

總結

執行過程當中觀察到Greenplum 5在涉及更新時，有大量的鎖狀況，有單查詢和單插入時，由於兩段事務的緣由，沒有及時commit致使lwlock(系統共享資源鎖)的衝突，而Greenplum 6引入了全局死鎖檢測功能從而支持了HEAP表數據表的併發更新，解決了這個問題，在併發更新測試時master上的lwlock沒有，節點上的lwlock有但不多總和才幾個，所以性能大大提升。

若是是ao表會是怎樣的狀況？接着把表pgbench_accounts修改爲ao表，再進行測試：

test=# create table pgbench_accounts_ao(like pgbench_accounts)WITH (appendonly=true,compresstype=zlib,COMPRESSLEVEL=5);
test=# insert into pgbench_accounts_ao select * from pgbench_accounts;
test=# alter table pgbench_accounts rename to pgbench_accounts_bak;
test=# alter table pgbench_accounts_ao rename to pgbench_accounts;
test=# vacuum analyze pgbench_accounts;

果真對ao表的更新有問題，觀察到只有一個進程在跑，其它都在等待鎖。

對ao表進行插入併發測試：

create table pgbench_history_ao(like pgbench_history)WITH (appendonly=true,compresstype=zlib,COMPRESSLEVEL=5);
insert into pgbench_history_ao select * from pgbench_history;
alter table pgbench_history rename to pgbench_history_bak;
alter table pgbench_history_ao rename to pgbench_history;
vacuum analyze pgbench_history;

性能降低很明顯，ao表是不適合頻繁的插入。

對ao表進行查詢併發測試：

一樣TPS也是很低，看來GP6的OLTP提高只是對heap表起做用。

接着咱們對Greenplum6的參數進行優化，以TPC-B基準測試爲例，並以CPU的核數64爲併發數來進行調整

一、Greenplum6和5的對比沒有開啓線程，是爲了減小Greenplum5不受pgbench線程參數的影響，如今調整pgbench命令，開啓線程 –j 參數，採用值16。

測試命令

pgbench -h mas01 -U gpadmin6 -p 6666 -c 64 -j 16 -T 30 -r test

測試結果

二、調整共享內存參數shared_buffers，存儲共享數據至內存。

gpconfig -c shared_buffers -v '2GB'

測試結果

三、調整事務提交參數，不強制將 WAL寫入磁盤，只需寫到緩存中就會向客戶端返回提交成功，延遲wal_writer_delay*3毫秒寫入磁盤，可提高TPS但會有事務丟失風險。

gpconfig -c synchronous_commit -v off

測試結果

四、關閉持久化調用，不強制刷新數據到磁盤，在斷電或者系統出現問題時有數據丟失的風險。

gpconfig -c fsync -v 'off' –skipvalidation

測試結果

在以前對比測試命令基礎上，加上-j $N參數開啓線程，並在當前參數設置下測試Greenplum6的性能結果

RT（平均響應時間），單位毫秒

基準測試測試結果截圖

在以前測試命令基礎上，加上-j $N參數開啓線程，並在當前參數設置下測試結果

基準測試測試結果截圖

單查詢測試結果截圖

單更新測試結果截圖

單插入測試結果截圖

做者簡介

葉健鋒，MPP數據庫研發管理

座標廣州，2012年開始學習使用Greenplum至今，熟練數據庫的規劃部署、SQL開發及調優、ETL數據加載，數據庫運維和性能調優等工做。