Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
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
Attachments
Issue Links
- causes
-
MDEV-11168 InnoDB: Failing assertion: !other_lock || wsrep_thd_is_BF(lock->trx->mysql_thd, FALSE) || wsrep_thd_is_BF(other_lock->trx->mysql_thd, FALSE)
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Open
-
- links to
Activity
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.
When I configure mariadb to be built without innodb, but with wsrep, I get some build errors because innodb-related symbols are not found.
Ok. Looks like a oversight of this configuration in https://github.com/MariaDB/server/commit/da3a3a68df34c7fef387ce890d3925166edeef2c#diff-bbb9322fe6d0355bb459fe6df3a5126c
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.
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.
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:
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