Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
On multithreaded write-intensive benchmarks, with innodb_flush_log_at_trx_comit (e.g sysbench update_index), log_write_up_to() is one of the hottest functions, and the log_sys.mutex is one of the hottest mutexes.
This is partially due to the way how log_sys.flush_event is used.
Whenever there is a pending flush, a thread is going to wait on this event, and when event is signalled, it retries the flush from the start. The problem here is that when flush is done, all threads are woken, resulting in contention of log_sys.mutex. There is a lot of spurious wakeups, and retries.
Situation can be improved e.g by using a custom synchronization primitive instead of Innodb event.
The synchronization primitive could have 2 operations
- wait(wait_lsn)
- set(set_lsn)
Where wait blocks current thread until set is called with set_lsn >= wait_lsn.
Note, that seldom "pseudo-spurious" wakeup might still be necessary in order to elect new group commit leader. But set should not wakeup all of the waiting threads.
Attachments
Issue Links
- relates to
-
MDEV-27848 Remove unused wait/io/file/innodb/innodb_log_file
- Closed
-
MDEV-27917 Some redo log diagnostics is always reported as 0
- Closed
-
MDEV-28870 InnoDB: Missing FILE_CREATE, FILE_DELETE or FILE_MODIFY before FILE_CHECKPOINT during crash recovery
- Closed
-
MDEV-17084 Optimize append only files for NVDIMM
- Closed
-
MDEV-21925 Redo log mutex competition is serious
- Closed