「NewSQL技术」Greenplum 6中的OLTP负载性能提升60倍以上

Greenplum 6包含了针对OLTP场景的多个优化，极大地提高了高并发情况下简单查询、插入、删除和更新操作的性能。这些改进包括:

• 更新PostgreSQL内核版本到9.4。这次更新带来了一套新的功能，同时也提高了系统的整体性能。例如，引入诸如fastpath之类的锁优化可以减少高并发情况下的锁争用开销。
• GP6提供了全局死锁检测，以支持对同一堆表的并发更新/删除操作。
• 优化全局事务，甚至避免在只读场景中持有锁，从而减少启动和结束事务的延迟。

基于这些优化，在我们的测试环境中，Greenplum 6的TPC-B性能是Greenplum 5的60倍，单次更新操作性能达到70倍，单次插入峰值性能达到3.6倍，单次查询性能达到3.5倍。特别是对于单次查询场景，我们在Greenplum 6中消除了大部分的锁竞争，使主CPU使用率超过90%，通过提高主节点的硬件性能进一步提高了查询的TPS性能。在192核的测试环境(1个master+18个段)中，单个查询TPS可以达到220,000。

1测试环境和方法

1.1测试环境

我们的测试环境基于谷歌云平台(GCP)。它是一个由5台虚拟主机组成的集群，包括一台主主机和4台段主机。主虚拟主机和段虚拟主机配置信息如下:

每个段主机运行一个段，整个集群没有配置镜像和备用。除此之外，您还需要一个虚拟主机来运行测试工具pgbench，它的配置不需要非常高，在我们的测试中是4核5 GB的配置。

1.2 Greenplum信息

我们的测试使用的是自编译的Greenplum，下面是版本信息:

Greenplum 6Greenplum 56.0.0-beta.35.18.0d2ebd40835e481a8724f4e3169c60cade3fed6d86aec9959d367d46c6b4391eb9ffc82c735d20102./configure \ –prefix=$HOME/opt/gpdb \ –disable-orca \ –disable-gpfdist \ –disable-pxf \ CFLAGS=’-g -O3 -march=native’ \ CXXFLAGS=’-g -O3 -march=native’./configure \ –prefix=$HOME/opt/gpdb5 \ –disable-orca\ –disable-gpfdist \ –disable-pxf \ CFLAGS=’-g -O3 -march=native’ \ CXXFLAGS=’-g -O3 -march=native’

1.3 Cluster Configuration

• gpconfig -c gp_enable_global_deadlock_detector -v on此GUC用于控制是否启用了全局死锁检测。在Greenplum 6中默认是关闭的。需要打开才能支持并发的更新/删除操作;Greenplum 5不支持这个GUC。
• gpconfig -c log_statement -v none这种GUC减少了不必要的日志，并防止日志输出干扰I/O性能。
• gpconfig -c checkpoint_segments -v 2 –skipvalidation这个GUC影响检查点磁盘刷新的频率。默认值8将降低刷新频率，但每次刷新的数据量很大，会导致整个集群的暂时性能下降。适当地调整OLTP工作负载的值将增加刷新的频率，但是由于每次刷新的数据量较小，平均性能将显著提高;Greenplum 5支持这种GUC，但是没有明显的效果，因为Greenplum 5的性能瓶颈不是在I/O中，而是在由表锁引起的序列化中。

1.4测试方法

我们的测试是使用pgbench进行的。数据大小为1000倍，没有对数据进行额外的调整。有四种测试类别，它们是具有多个语句、单个选择语句、单个更新语句和单个插入语句的标准TPC-B事务。对于每个类别，当并发客户端从10增加到200时，测试将计算TPS值。

2测试结果

2.1 TPC-B

Pgbench的TPC-B测试混合了大表和小表的插入、更新和查询操作。Greenplum 6的TPS峰值约为4,300，而Greenplum 5的峰值约为70，性能提高了60倍。造成这种巨大性能差异的一个关键因素是，Greenplum 6引入了全局死锁检测来支持对堆表的并发更新，而对Greenplum 5中相同表的更新必须在序列化过程中完成。

— pgbench -c N -j N -r -T 60 -P 1 -s 1000\set scale 1000\set nbranches 1 * :scale\set ntellers 10 * :scale\set naccounts 100000 * :scale\set random aid 1 :naccounts\set random bid 1 :nbranches\set random tid 1 :ntellers\set random delta -5000 5000BEGIN;UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;SELECT abalance FROM pgbench_accounts WHERE aid = :aid;UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE tid = :tid;UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);END;

2.2单条查询

Greenplum 6的TPS峰值可以达到79000以上，而Greenplum 5的TPS只有23000，增长率为350%。

— pgbench -c N -j N -r -T 60 -P 1 -s 1000 -S\set scale 1000\set naccounts 100000 * :scale\set random aid 1 :naccountsSELECT abalance FROM pgbench_accounts WHERE aid = :aid;

2.3单条更新

除了pgbench的内置测试之外，我们还测试了单个更新场景。青梅6的峰值TPS为7300，青梅5的峰值TPS约为100，达到70多倍。

— pgbench -c N -j N -r -T 60 -P 1 -s 1000 -f update-only.sql\set scale 1000\set naccounts 100000 * :scale\set random aid 1 :naccounts\set random delta -5000 5000UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;

2.4单条插入

在单次插入测试中，Greenplum 6的TPS峰值超过18000，而Greenplum 5的TPS峰值为5000，增加了360%。

— pgbench -c N -j N -r -T 60 -P 1 -s 1000 -f insert-only.sql\set scale 1000\set nbranches 1 * :scale\set ntellers 10 * :scale\set naccounts 100000 * :scale\set random aid 1 :naccounts\set random bid 1 :nbranches\set random tid 1 :ntellers\set random delta -5000 5000INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES (:tid, :bid, :aid, :delta, CURRENT_TIMESTAMP);

3未来的工作

在测试中，我们注意到一些编译选项对更新操作的性能和稳定性有很大的影响。wal_segment_size是只读的GUC，这意味着一个WAL片文件的大小。每当写入许多片文件时，就会触发强制磁盘刷新。显然，该值越大，刷新频率越低。但是，每次磁盘刷新的数据量也会增加，主机上其他进程的I/O操作性能会受到极大干扰，整个集群的性能会立即下降。在Greenplum中，这个GUC的默认值是64MB。我们注意到在Greenplum中更新操作的TPS波动很大，而在PostgreSQL中调整到默认值16MB时，波动范围明显减小。TPS值也提高了。但是，该值仅在编译时通过“configure - with- walton - SEGSIZE =SEGSIZE”得到支持，因此如何支持运行时调优和微调策略将是我们未来工作的一部分。我们还注意到，在单插入测试类别中，当Greenplum 6的并发数超过峰值时，其性能有一定程度的下降。根据我们的初步测试，这与内部锁的竞争有关，如果我们能进行更多的优化，那么在未来的Greenplum版本中可以期待更高的插入性能。

本文：http://jiagoushi.pro/node/1181