On Thu, Dec 12, 2024 at 5:31 PM <[email protected]> wrote: > > Hi, > > On 2024-12-05 21:44, Kazuhiko via discuss wrote: > > On 2024-12-04 18:31, Gordan Bobic wrote: > >>> I just tried READ COMMITTED everywhere on 11.4 and I had no such > >>> consistent increase of the history length (see the attachment). But > >>> it > >>> is not an acceptable solution and we anyway had no such issue on 10.4 > >>> with READ COMMITTED and REPEATABLE READ combination. > > I tried MariaDB 10.5. Both 'consistent increase of the history length' > issue and 'MariaDB stall' issue > happen on MariaDB 10.5.27 like I already tried on 11.4.4 while running > many READ COMMITTED DML and many > REPEATABLE READ DQL queries in parallel.
Didn't you previously mention that the tx history length problem goes away when running globally in read-committed mode (similar to behaviour of innodb_locks_unsafe_for_binlog on 10.4)? On the subject of the stall you mention, if we are talking about the stall that happens when the locks finally resolve and the tx history gets purged, that is a serious problem that I have yet to manage to fully tune out in cases where I have experienced it, but it can be partially mitigated by setting something like the following: innodb_max_purge_lag_wait = 1M # I find that around 1M is where things start to go badly sideways, you may want to try lower for your workload, e.g. 100K innodb_max_purge_lag = 100K innodb_purge_threads = 16 # assuming you have at least 16 CPU cores on the server) > It is not yet clear which changes between 10.4 and 10.5 cause these > issues. > https://mariadb.com/kb/en/changes-and-improvements-in-mariadb-10-5/ > > Are there any parameter to make 10.5 (or later) behave like 10.4 for > these issues ? > Or can they be simply regression bugs ? If you tracked down the difference in behaviour specifically to innodb_locks_unsafe_for_binlog, then that was removed in this commit: https://github.com/MariaDB/server/commit/1a6f470464171bd1144e4dd6f169bb4018f2e81a _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
