降低多版本机制对性能的影响
关键字:
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