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:mas01、mas02、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为并发数来进行调整

1、Greenplum6和5的对比没有开启线程,是为了减少Greenplum5不受pgbench线程参数的影响,现在调整pgbench命令,开启线程 –j 参数,采用值16。

测试命令

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

测试结果

2、调整共享内存参数shared_buffers,存储共享数据至内存。

gpconfig -c shared_buffers -v '2GB'

测试结果

3、调整事务提交参数,不强制将 WAL写入磁盘,只需写到缓存中就会向客户端返回提交成功,延迟wal_writer_delay*3毫秒写入磁盘,可提升TPS但会有事务丢失风险。

gpconfig -c synchronous_commit -v off

测试结果

4、关闭持久化调用,不强制刷新数据到磁盘,在断电或者系统出现问题时有数据丢失的风险。

gpconfig -c fsync -v 'off' –skipvalidation

测试结果

在之前对比测试命令基础上,加上-j $N参数开启线程,并在当前参数设置下测试Greenplum6的性能结果

RT(平均响应时间),单位毫秒

基准测试测试结果截图

在之前测试命令基础上,加上-j $N参数开启线程,并在当前参数设置下测试结果

基准测试测试结果截图

单查询测试结果截图

单更新测试结果截图

单插入测试结果截图

作者简介

叶健锋,MPP数据库研发管理

坐标广州,2012年开始学习使用Greenplum至今,熟练数据库的规划部署、SQL开发及调优、ETL数据加载,数据库运维和性能调优等工作。

发表评论

电子邮件地址不会被公开。 必填项已用*标注