Hi,
On 2024-12-13 11:46, Marko Mäkelä wrote:
On Thu, Dec 12, 2024 at 10:43 PM Kazuhiko via discuss
<[email protected]> 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
_______________________________________________
discuss mailing list -- [email protected]
To unsubscribe send an email to [email protected]
