[MDEV-11039] Add new scheduling algorithm for reducing tail latencies Created: 2016-10-12  Updated: 2023-02-28  Resolved: 2016-10-27

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB, Storage Engine - XtraDB
Fix Version/s: 10.1.19, 10.2.3, 10.3.0

Type: Task Priority: Critical
Reporter: Sergey Vojtovich Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 1
Labels: contribution, foundation

Issue Links:
Problem/Incident
causes MDEV-11168 InnoDB: Failing assertion: !other_loc... Closed
causes MDEV-12837 WSREP: BF lock wait long Closed
causes MDEV-16664 InnoDB: Failing assertion: !other_loc... Closed
Relates
relates to MDEV-23897 ASAN SEGV in lock_grant_and_move_on_page Closed
relates to MDEV-30748 LOCKing mechanism Improvement Request... Open

 Description   

This branch introduces a new scheduling algorithm (Variance-Aware-Transaction-Scheduling, VATS) for the record lock manager of InnoDB and XtraDB. Instead of using First-Come-First-Served (FCFS), the newly introduced algorithm uses an Eldest-Transaction-First (ETF) heuristic, which prefers older transactions over new ones. A configuration parameter (innodb_lock_schedule_algorithm) is introduced for users to choose between VATS and FCFS (the default one). We've extensively tested this algorithm in many workloads. The algorithm is very simple, and the changes are very local, but it significantly improves performance (in terms of average latency and throughput) and predictability (in terms of reduction of tail and quantile latencies) For more details, please refer to this paper http://arxiv.org/abs/1602.01871



 Comments   
Comment by Jan Lindström (Inactive) [ 2016-10-27 ]

commit ea0ae42d8324f6210b95a38bcf76014ce062d1f3
Merge: 4edd4ad 7496176
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Wed Oct 26 08:34:04 2016 +0300

Merge pull request #250 from sensssz/10.1-vats

A few fixes for VATS in 10.1

commit 74961760a4837d2deb33336329c28cf9ad9b4e9e
Author: sensssz <hjmsens@gmail.com>
Date: Tue Oct 25 18:57:03 2016 -0400

A few fixes for VATS in 10.1

commit 021212b525e39d332cddd0b9f1656e2fa8044905
Merge: 1bfa37a 183c028
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date: Mon Oct 24 21:51:42 2016 +0300

Merge pull request #245 from sensssz/10.1-vats

MDEV-11039 - Add new scheduling algorithm for reducing tail latencies

Comment by Arseniy [ 2018-02-01 ]

This configuration parameter prevents mariadb to be built without innodb.

Comment by Daniel Black [ 2018-02-01 ]

saur0n I can't follow your comment. You can build mariadb without innodb and in that case innodb_lock_schedule_algorithm wont' exist along with all the other innodb variables. If I'm misunderstanding your assertion can you provide clarification.

Comment by Arseniy [ 2018-02-02 ]

When I configure mariadb to be built without innodb, but with wsrep, I get some build errors because innodb-related symbols are not found.

Comment by Daniel Black [ 2018-02-02 ]

Ok. Looks like a oversight of this configuration in https://github.com/MariaDB/server/commit/da3a3a68df34c7fef387ce890d3925166edeef2c#diff-bbb9322fe6d0355bb459fe6df3a5126c

Comment by Daniel Black [ 2018-02-02 ]

recommend creating a new issue if this doesn't get noticed. We generally don't reopen issues after release is made. As per the commit you issue was caused by attempting to fix MDEV-12837.

Comment by Marko Mäkelä [ 2018-07-05 ]

This contribution was merged to MariaDB 10.1, and it was enabled by default in 10.2, by changing the default value of the new parameter to innodb_lock_schedule_algorithm=vats. In 10.1, the default is innodb_lock_schedule_algorithm=fcfs, using the old algorithm.

The algorithm seems to be incompatible with how the lock replication and transaction certification in Galera cluster works. The fix of MDEV-12837 was to make Galera refuse innodb_lock_schedule_algorithm=vats.

Comment by Marko Mäkelä [ 2020-10-05 ]

Due to the regression MDEV-16664 (potential corruption due to wrongly granting exclusive locks on the same record to more than one active transaction at a time), I did the following:

  1. Reverted the default back to the safe value
  2. Added a deprecation and corruption warning
  3. Removed the option innodb_lock_schedule_algorithm and related code (MariaDB Server 10.6)
Generated at Thu Feb 08 07:46:50 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.