Status: Closed (View Workflow)
Affects Version/s: 10.2.41, 10.3.32, 10.4.22, 10.5.13, 10.6.5
Component/s: Storage Engine - InnoDB
COLO- 2x 8C/16T Intel Xeon Gold 6134 w/592GB RAM and 10TB PCI-E NVMe SSD
OTHER- 2x AMD Epyc 7532 w/512GB RAM and PCI-E NVMe SSD
Original issue and repro-
Current repro and data provided in developer comment via link.
Flamegraphs from Intel machine attached (two variants per- one uses perf polling at 99Hz, other uses mariadb-stacktrace collecting thread dumps every 5 seconds for 60 iterations). Stack trace from AMD machine attached.
Three sets of flamegraphs-
- Regular 10.6.5 using utf8mb3 (not set as default) charset for tables with AHI enabled
- Regular 10.6.5 using latin1 (set as default) charset for tables with AHI disabled (default)
- Custom 10.6.5 using utf8mb3 (not set as default) charset for tables with AHI disabled (default) where line 867 of mysys/charset.c has been removed prior to compiling MariaDB 10.6.5 CS
Base concern is despite this being a read workload, adding cores to the workload has a diminishing impact (very noticeable going from 4 to 8 cores on our Intel setup where 8 cores should have been ideal for scaling)-
Flamegraphs seem to demonstrate counter from
MDEV-6274 yielding an outsized, negative impact. Results without this counter greatly improve-
Flamegraphs from modified binary still suggest additional collation/charset optimization may stand in the way of even better performance, and likewise for what appear to be some low-level InnoDB locks.
Would like to see MariaDB achieve scaling closer to 200% performance gain for doubling core count, which on this same workload Postgres comes very close to achieving.