Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.5.4, 10.6.0, 10.6.8, 10.9.3
-
Arch Linux VM running on VMware ESXi
Description
We upgraded an MariaDB Galera Cluster from Version 10.5.13 to 10.9.3. Everything is up and running, from a client's point of view.
However we see a regression in I/O access when running mariadb-dump. A custom script (dumping and compressing every table in separate file) ran for about 45 minutes with MariaDB 10.5.13, the time increased to about two and a half hour with MariaDB 10.9.3.
A simple cp can do about 500MB/s on the machines, with mariadb-dump we get about 25MB/s - limited by disk I/O (where mariadbd is in I/O wait / state "D"). MariaDB 10.5.13 did something about 100MB/s - limited by compression, so could probably do a lot more.
This happens with all available I/O methods, tried with aio, uring and native. Also tried different filesystems (ext4 & btrfs) which does not make a difference. Same results with a cluster node and standalone (non-Galera) installation.
No idea if I/O for regular SQL queries regressed as well. The machines have a reasonable amount of RAM, so no delay is noticeable there. Running mariabackup for Galera state transfer reaches expected transfer rates.
Attachments
Issue Links
- blocks
-
MDEV-31227 innodb_flush_method=O_DIRECT causes 3x regression in workload
- Closed
- is caused by
-
MDEV-15053 Reduce buf_pool_t::mutex contention
- Closed
- relates to
-
MDEV-26055 Adaptive flushing is still not getting invoked in 10.5.11
- Closed
-
MDEV-30400 Assertion `height == btr_page_get_level(page_cur_get_page(page_cursor))' failed in btr_cur_search_to_nth_level on INSERT
- Closed
-
MDEV-31254 InnoDB: Trying to read doublewrite buffer page
- Closed
-
MDEV-29343 MariaDB 10.6.x slower mysqldump etc.
- Closed
-
MDEV-30986 Slow full index scan in 10.6 vs 10.5 for the (slow) I/O-bound case
- Closed