Hi, On 2024-12-13 11:46, Marko Mäkelä wrote:
On Thu, Dec 12, 2024 at 10:43 PM Kazuhiko via discuss <discuss@lists.mariadb.org> wrote:
Here is the summary for history length issue: (RC = READ COMMITTED, RR = REPEATABLE READ)
Good * 10.4, RR only with innodb_locks_unsafe_for_binlog * 10.4, RC for DML, RR for DQL * 10.5, RC only
Bad * 10.5, RC for DML, RR for DQL * 11.4, RC for DML, RR for DQL
Could you please also test the recent 10.6.20 release? It includes some performance improvements to the InnoDB undo log subsystem that were not applied to the 10.5 series, most recently MDEV-34515.
In 'RC for DML, RR for DQL' combination, here are the more detailed list for history length issue : Good * 10.4.34 * 10.5.5, 10.5.16, 10.5.19, 10.5.20 * 10.6.13 Bad * 10.5.21, 10.5.22, 10.5.27 * 10.6.15, 10.6.20 * 11.4.3, 11.4.4 So it seems that the changes between 10.5.20 and 10.5.21 caused this issue. # I skipped 10.6.14 because of the warning in the release note. # https://mariadb.com/kb/en/mariadb-10-6-14-release-notes/
In case you are running on NUMA hardware, it might be worth trying to bind the mariadbd process to a single NUMA node in order to avoid cross-NUMA traffic. In some workloads, going from 2 NUMA nodes to 1 can double the throughput. I have tried to improve our NUMA performance (any reduction of mutex contention should help with that), but the high-level design is really targeting SMP, not being NUMA friendly.
The current performance test environment is running on a virtual machine, thus I'm not sure if it is a NUMA 'hardware'. But anyway its impact should be much smaller than history length behaviour difference shown above, I think. Best regards, Kazuhiko