Qué cambió
Los desarrolladores de MariaDB identificaron y arreglaron una regresión de rendimiento que apareció a partir de la rama 10.5 y afectaba cargas de trabajo que caben íntegramente en memoria (in‑memory). El problema estaba ligado a la gestión de la lista LRU del buffer pool de InnoDB: desde 10.5 ciertos eventos empezaron a activar un «reloj» de liberación de páginas demasiado pronto, lo que disparó promociones en la LRU y aumentó la contención en buf_pool.mutex.
Por qué importan las mejoras de InnoDB
El buffer pool es la caché de páginas de InnoDB y la lista LRU decide qué páginas se expulsan cuando hacen falta marcos libres. En versiones anteriores se usaban múltiples instancias del buffer pool para reducir contención; a partir de 10.5 se unificó esa estructura en una sola instancia, con la expectativa de que en cargas que caben en memoria no habría tanta presión sobre la caché.
Qué provocó la regresión y cómo se arregló
Los cambios destinados a evitar escrituras innecesarias de páginas liberadas (registros FREE_PAGE y otras modificaciones relacionadas) hicieron que el mecanismo que marca cuándo empieza la expulsión de páginas (el «reloj» o clock de páginas libres) se activara con demasiada frecuencia, incluso cuando no había escasez real de marcos libres. Eso provocó un volumen masivo de promociones en la LRU: cada promoción toma buf_pool.mutex y, en cargas muy concurrentes, se tradujo en un coste de context switches y bloqueo.
La corrección aplicada en 11.8 no solo restaura el significado original del reloj en escenarios in‑memory, sino que evita también que buf_pool.mutex se use en cada promoción de página al acceder a ella. En otras palabras, reduce la entrada en la sección crítica durante una lectura que solo quería marcar una página como «accedida», bajando la contención.
Impacto medido
- En pruebas con sysbench publicadas por Mark Callaghan, la versión 11.8 con la corrección aumentó el rendimiento en un test concreto de 20.326 a 57.052 QPS (≈2.8×).
- Validaciones adicionales en distintos hosts y ramas (11.8, 12.3 y 13.1) confirmaron ganancias significativas; en algunos casos la 11.8 corregida llegó a ser entre un 7% y 9% más rápida que la histórica 10.4.34 en esas pruebas.
Quiénes se benefician y qué deben hacer
Afecta sobre todo a administradores de bases de datos y propietarios de sitios con cargas de lectura intensiva que caben en la memoria del buffer pool (oltp_read_only y consultas con muchas búsquedas en clave primaria). Si sus bases de datos emplean configuraciones con buffer pools grandes y datos que residen principalmente en memoria, pueden ver mejoras relevantes al migrar a la rama 11.8 con la corrección.
Recomendaciones prácticas
- Evaluar la migración o actualización a MariaDB 11.8 si su workload es mayoritariamente in‑memory y su versión actual es ≥10.5 y muestra degradación en lecturas concurrentes.
- Antes de actualizar en producción, replicar el perfil de carga con sysbench o pruebas representativas para comprobar la ganancia en su hardware y configuración.
- Revisar parámetros de buffer pool (tamaño, innodb_max_dirty_pages_pct) y observar las métricas de promociones/LRU y contención en buf_pool.mutex tras la actualización.
Nota: el análisis que motivó la corrección proviene de trazas de perfil y de comparativas históricas entre versiones; la corrección intenta devolver el comportamiento previo en in‑memory y reducir la contención global en el camino.
Lee también:
- Linux 7.4 añade soporte DMA-BUF al camino de E/S con io_uring
- Fedora Linux 45 se retrasa otra vez y apunta ahora al 3 de noviembre
Fuente: MariaDB.org
