OneSQL :: 优化SAP Hybris应用”Lock wait timeout exceeded; try restarting transaction”错误

在互联网行业里,绝大多数应用都是新建的,在设计中就考虑了业务的高并发,在使用MySQL数据库时,尽量避免了大的事务,可以说事务越大,并发处理能力越低,比如优化到没有事务,就可以采用NoSQL了。但在绝大多数非互联网企业的应用中,业务逻辑较为复杂,数据库的事务特性是必须的,因此并发稍大就会出现较严重的锁等待情况,使用MySQL时就会遇到1205号错误,即MySQL为了保护自身,当锁等待超过一定时间(由参数innodb_lock_wait_timeout决定)后,就会报此错误。

payment 36:1
1205, HY000, Lock wait timeout exceeded; try restarting transaction
payment 21:1
1205, HY000, Lock wait timeout exceeded; try restarting transaction
payment 288:1
1205, HY000, Lock wait timeout exceeded; try restarting transaction
1205, HY000, Lock wait timeout exceeded; try restarting transaction
payment 202:1

我们曾经帮一客户去优化SAP的Hybris电商应用的并发性能,发现当并发用户数上升时,不仅总体性能降低,而且伴随着大量的1205号错误;当我们调大innodb_lock_wait_timeout参数值时,并不能降低错误的概率,反而会大大降低总体的事务处理能力。这种情况很容易用tpcc测试重现出来,比如用600并发连接去压测一个20个DW仓库,压测命令如下:

tpcc_start -h 172.30.12.15 -P 3306 -d test \
      -u test -p test -w 20 -c 600 -r 20 -l 120 -i 20

当压测时间超过超时设置值时,就极容易发生锁等待超时,从这里可以猜测,MySQL在唤醒超时等待会话时,采用了随机的策略,并不是唤醒等待最久的会话,从而导致了超时错误的发生,造成这个情况的原因则是同时进入MySQL的并发事务数太多。在MySQL 8中引入的Contention Aware Transaction Scheduler,估计可以极大地优化并发事务的场景。

除此之外,OneSQL的高并发补丁可以极大地优化并发事务的性能,通过以事务为单位的多队列线程池技术,不仅保证了高并发下的tpcc压测性能,同时通过Server层事务排队技术,避免了锁等待超时错误。下图是不同并发(见X轴,从64到3072并发)下的TpmC值(见Y轴)。


OneSQL以事务为单位的多队列线程池技术,将MySQL InnoDB层的活动事务数,控制在较优化的范围(可以通过参数设定优化目标值),彻底避免过多的InnoDB层并发事务数,降低事务调度的成本,达到性能的极限优化,并且对应用来说,完全100%透明。

在客户的应用场景中,通过将MySQL透明切换到OneSQL,透明地提升了至少4倍的并发事务处理能力,从而可以轻松地面对店庆等促销活动。