pgbench 介紹

1、簡介：

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

2、使用方法：

<code>pgbench [OPTION]... [DBNAME]/<code>

3、初始化選項：

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

4、標準選項：

<code>-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張標準表/<code>

測試環境介紹

1、硬件環境：

• 數量：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

2、數據庫環境配置：

• GP版本：Greenplum6.2.1 vs. Greenplum5.20
• 內核版本：PostgreSQL 9.4.24 vs. PostgreSQL 8.3.23
• 環境配置：Master: mas01; Segment: mas01、mas02、seg08

3、集群參數設置：

Greenplum 6

<code>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/<code>

Greenplum5

<code>gpconfig -c 'optimizer' -v off
gpconfig -c 'resource_scheduler' -v off
gpconfig -c log_statement -v none
gpconfig -c checkpoint_segments -v 2 --skipvalidation/<code>

4、參數說明

<code>gp_enable_global_deadlock_detector/<code>

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

<code>log_statement/<code>

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

<code>checkpoint_segments/<code>

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

測試方法

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

• 初始化命令

<code>pgbench -h mas01 -U gpadmin6 -p 6666 -i -s 1000 test/<code>

• 基準測試命令

<code>pgbench -h mas01 -U $user -p $port -c $N -T 60 -r test/<code>

• 單查詢測試命令

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

• 單更新測試命令

<code>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;/<code>

• 單插入測試命令

<code>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;/<code>

總結

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

如果是ao表會是怎樣的情況？接著把表 pgbench_accounts 修改成ao表，再進行測試：

<code>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;/<code>

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

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

<code>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;/<code>

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

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

同樣 TPS 也是很低，看來 GP6 的 OLTP 提升只是對 heap 表起作用。

接著我們對 Greenplum 6 的參數進行優化，以 TPC-B 基準測試為例，並以 CPU 的核數64為併發數來進行調整。

1、Greenplum 6和5的對比沒有開啟線程，是為了減少 Greenplum 5 不受 pgbench 線程參數的影響，現在調整 pgbench 命令，開啟線程 –j 參數，採用值16。

測試命令

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

測試結果

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

<code>gpconfig -c shared_buffers -v '2GB'/<code>

測試結果

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

<code>gpconfig -c synchronous_commit -v off/<code>

測試結果

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

<code>gpconfig -c fsync -v 'off' –skipvalidation/<code>

測試結果

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

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

基準測試測試結果截圖

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

基準測試測試結果截圖：

單查詢測試結果截圖：

單更新測試結果截圖：

單插入測試結果截圖：

葉健鋒：

MPP數據庫研發管理

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

閱讀更多 Greenplum中文社區 的文章

關鍵字: 數據庫 實戰 版本