server
server copied to clipboard
MDEV-24948: thd_need_wait_reports() hurts performance
Reduce the cost of thd_rpl_deadlock_check() which is used to do parallel replication conflict detecton.
-
Cache the value of thd_need_wait_reports() in InnoDB trx_t, and only call thd_rpl_deadlock_check() if required.
-
Remove the FL_WAITED flag in GTID. This flag was set if a transaction did any lock wait inside InnoDB on the master. In optimistic parallel replication on the slave, such transaction would not run in parallel with any prior transactions. It is not clear what the value of this mechanism is. If a transaction did not wait on the master, it can still conflict on the slave. And even if it did have to wait on the master, that does not mean that it will need to wait on the slave, or that such wait will cause a conflict or other problem. So waiting for all prior transactions on the slave in FL_WAITED transactions might slow down things rather than speed up.
-
Only request thd_rpl_deadlock_check() calls for non-replication THDs if the --binlog-commit-wait-count option is enabled. Such wait might have to timeout, if the waiting commits are blocking other transactions from joining the group commit, so the wait reports are used to terminate the wait early. After this patch, setting --binlog-commit-wait-count non-zero will only have effect for newly created connections.
With these changes, unless the non-default --binlog-commit-wait-count option is used, the overhead of thd_rpl_deadlock_check() is reduced to a single conditional in non-parallel-replication threads.
Signed-off-by: Kristian Nielsen [email protected]