Hi Kazuhiko, On Wed, Jan 8, 2025 at 12:54 PM <[email protected]> wrote: > I could reproduce 'history list increase' issue with the attached schema > and python script, > that executes 50% R-C DML and 50% R-R DQL using 64 threads.
Thank you. I have asked our performance tester to reproduce this. For what it is worth, for quite some time we have observed a huge history list length during certain Sysbench workloads. The problem was significantly improved for some workloads by some changes such as MDEV-32050. One surprise was that under some circumstances, the purge tasks could steal too many resources from SQL processing. The actual "fix" of https://jira.mariadb.org/browse/MDEV-34515 was to limit the default size of a purge batch to 127, to match the number of usable rollback segments when using innodb_undo_tablespaces>1. Roughly speaking, InnoDB can concurrently start or commit at most that many transactions. If the purge batch is larger, it appears to block the starting or finishing of user transactions. I made several other improvements based on my observations while diagnosing MDEV-34515, but in the end it was the configuration parameter change that "fixed" that artificial test case (a table with 1 record and 1 secondary index). The parameter innodb_buffer_pool_instances has no effect starting with MariaDB Server 10.5. I believe that the motivation of splitting the buffer pool was to work around contention on buf_pool.mutex. We do have one known performance bug MDEV-33966 in that area. Quite some time ago, I started https://github.com/MariaDB/server/pull/3522 but did not get to refine it. Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB plc _______________________________________________ discuss mailing list -- [email protected] To unsubscribe send an email to [email protected]
