Databases & Storage

MariaDB 11.8 triples in-memory InnoDB speed by fixing 10.5 LRU regression

Key Takeaway

A MariaDB 11.8 fix removes buf_pool.mutex from LRU promotion and restores pre-10.5 clock semantics, yielding roughly 3x throughput gains on in-memory workloads by eliminating unnecessary page list management overhead introduced by freed-page handling changes.

Summary

MariaDB 11.8 delivers dramatic performance improvements for in-memory InnoDB workloads through a fix that resolves a regression tracing back to version 10.5. The root cause was identified by Alessandro Vetere: changes in MariaDB 10.5.2 and 10.5.4-5 (MDEV-15528 and MDEV-8139) that optimized freed-page handling for crash recovery inadvertently caused the buffer pool's freed_page_clock to begin ticking during load phases, even when no actual eviction pressure existed. This forced constant LRU list promotions under buf_pool.mutex protection, turning what should be no-ops for in-memory workloads into a major contention point.

The merged fix takes two approaches. First, it removes buf_pool.mutex from the LRU promotion path on page access entirely, not merely for in-memory scenarios. Second, it restores the original meaning of the freed_page_clock so that it accurately signals when eviction has genuinely started rather than being triggered by routine page cleaner activity. Benchmark validation by Mark Callaghan showed QPS rising from 20,326 to 57,052 (approximately 2.8x) on one test configuration, while independent validation by Jonathan Miller demonstrated even larger gains across MariaDB 11.8, 12.3, and 13.1. Notably, the fixed 11.8 now runs 7-9% faster than 10.4.34, the pre-regression baseline.

Buffer pool mutex and clock semantics in the 11.8 fix

  • LRU promotion mutex removal: The fix takes buf_pool.mutex out of buf_page_make_young() entirely, eliminating the serialization point that caused context switches per query to spike from 2.8 to 29.6 when MDEV-23399 made the mutex blocking.
  • freed_page_clock semantics restoration: Pre-10.5, the clock remained at zero until genuine eviction pressure began, allowing in-memory workloads to skip LRU statistics and block movement entirely; the fix restores this original meaning rather than having the clock tick on any freed-page removal by the page cleaner.
  • Single buffer pool context: The regression manifested after MariaDB 10.5 removed multiple buffer pool instances (MDEV-15058), consolidating to one buf_pool.LRU list and one buf_pool.mutex; the fix addresses the resulting contention without reintroducing partitioning complexity.
  • Purge and undo page interaction: The 10.5 freed-page optimization (avoiding writes of garbage pages to data files and adding FREE_PAGE redo records) caused purge-driven undo page frees and B-tree page frees to trigger clock advances via LRU removals, arming the clock during load phases.
  • Validation methodology: Performance was verified against Mark Callaghan's public sysbench archive spanning 27 releases on identical hardware, with SHOW ENGINE INNODB STATUS confirming pre-10.5 runs made approximately 25 thousand pages young versus 1.3-1.8 billion in affected 10.5+ releases.

Why it matters

Database administrators running MariaDB on memory-resident datasets—common in caching layers, analytical staging, and high-throughput OLTP—can expect substantial latency and throughput improvements without hardware changes or configuration tuning. The fix also validates the architectural decision to maintain a single buffer pool instance, reducing operational complexity compared to MySQL-style partitioning while demonstrating that mutex contention can be addressed through finer-grained code changes rather than data structure splitting.

What to do

  • If you are using MariaDB 10.5 or later, consider updating to MariaDB 11.8 to fix the LRU promotion regression and improve in-memory InnoDB workload performance
  • Check your current MariaDB version and compare its performance to the benchmarks provided to determine if the update is necessary for your specific use case

Original reference: mariadb.org →