降低多版本机制对性能的影响

关键字：

TPCC、sysbench、性能、autovacuum

1.特性说明

KES的MVCC机制在数据删除、更新时会产生dead元组，这些dead元组通过后台autovacuum进程清理。一般情况下autovacuum可以工作的不错，但是当主库或备库存在长事务时，dead元组会不断堆积，造成表膨胀（包括索引膨胀），也会造成SQL执行性能衰退。本特性可以解决上述问题，跳过长事务，清理对任何快照不可见的dead元组。

银行跑批业务场景中，除了T1其他事务Tn都是短事务，实际上业务a中的旧版本大部分是不被任何事务可见的。然而，由于事务T1一直没有提交，导致oldestxmin没有增长，业务表a中的旧版本无法被vacuum清理，查询扫描效率持续下降。为了降低多版本机制对性能影响，需要清理受长事务阻碍无法被vacuum及时清理的dead元组。

目前只实现：

1、Vacuum跳过长事务清理死亡元组状态的设置
2、Vacuum跳过长事务清理次老事务之前特定用户表的死亡元组。

2.性能需求

需求特性开启后，vacuum清理效率不应该降低或降低很少；系统TPCC测试极限值不应该有性能下降，系统sysbench测试不应该有性能下降。

3.测试示例

3.1TPCC测试

测试版本：V008R006B0609095817

测试场景：100仓 1000并发 20分钟 极限生产值

（1）执行需求特性未开启的TPCC测试：

（2）开启需求特性

执行灌数前，对相关表开启一个存储参数，这是一个表级参数，需要在建表时逐个表进行设置(autovacuum_vacuum_by_snapshotcsn=0)，具体操作为：修改“/home/sn/benchmarksql-5.0/run/sql.common”路径下的tableCreates.sql，将其中的建表语句修改为“create table bmsql_config (cfg_name varchar(30) primary key, cfg_value varchar(50))WITH (autovacuum_vacuum_by_snapshotcsn=0);”。

（3）执行TPCC极限生产值测试——按1中的步骤执行。

3.2 sysbench测试

测试版本：V008R006B0609095817

测试场景：10张表 每张表1000w行数据 100并发 10分钟

（1）开启特性需求前执行sysbench测试

（2）开启特性需求后执行sysbench测试

灌数后，对相关表开启一个存储参数，执行语句为：

– 设置参数

alter table sbctest1 set (autovacuum_vacuum_by_snapshotcsn = 0);

– 重置参数到默认值-1

alter table sbctest1 reset (autovacuum_vacuum_by_snapshotcsn);

4.测试注意事项

（1）autovacuum_vacuum_by_snapshotcsn默认值为-1，但是开启此功能后不能再次设置回-1，如果想关闭此功能需要使用命令alter table mvcctest1 reset (autovacuum_vacuum_by_snapshotcsn);

（2）Values默认值为-1，表示不启用此功能；当默认值不为-1的整数时，为触发本功能的阈值（长事务与次老事务的snapshotcsn差值要大于Values），代表有长事务存在，vacuum需要根据snapshotcsn执行清理工作。

（3）snapshotcsn差值的计算方法：用“”命令分别查出两个事务的snapshotcsn值，然后相减（由于是自增的，所以不会存在负数的情况）。
更多信息，参见https://help.kingbase.com.cn/v8/index.html