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数据加载，数据库运维和性能调优等工做。