Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
Description
lock_sys is one of three major InnoDB scalability bottlenecks. Scalability issues are especially obvious under sysbench OLTP update index/non-index benchmarks.
There's no clarity on how exactly it should be optimised yet.
Attachments
Issue Links
- blocks
-
MDEV-21452 Use condition variables and normal mutexes instead of InnoDB os_event and mutex
- Closed
- causes
-
MDEV-24861 Assertion `trx->rsegs.m_redo.rseg' failed in innodb_prepare_commit_versioned
- Closed
- includes
-
MDEV-24731 Excessive mutex contention in DeadlockChecker::check_and_resolve()
- Closed
- is blocked by
-
MDEV-24671 Assertion failure in lock_wait_table_reserve_slot()
- Closed
- relates to
-
MDEV-11392 AliSQL: [perf] Issue#31 OPTIMIZE CHECK/GRANT OF INNODB TABLE LOCK
- Closed
-
MDEV-16406 Refactor the InnoDB record locks
- Open
-
MDEV-24813 Locking full table scan fails to use table-level locking
- In Review
-
MDEV-24948 thd_need_wait_reports() hurts performance
- Open
-
MDEV-24952 Simplify the locking and access of lock hash tables
- Closed
-
MDEV-26476 InnoDB is missing futex support on some platforms
- Closed
-
MDEV-18706 ER_LOCK_DEADLOCK on concurrent read and insert into already locked gap
- In Review
-
MDEV-21175 Remove dict_table_t::n_foreign_key_checks_running from InnoDB
- Closed
-
MDEV-24915 Galera conflict resolution is unnecessarily complex
- Closed
-
MDEV-25010 Assertion `!lock_sys_t::get_first(receiver_cell, receiver_id, receiver_heap_no)' failed in lock_rec_move
- Closed
- links to