Entender los subprocesos del «Page Cleaner» de MariaDB: cómo influyen en el rendimiento

Limpiador de páginas Los hilos de MariaDB controlan la forma en que InnoDB escribe las páginas modificadas del buffer pool al disco, lo que permite suavizar los tiempos de respuesta bajo cargas de escritura. Quien comprenda la arquitectura actual, con un único hilo de limpieza, evitará cuellos de botella en la ruta de escritura y mantendrá la base de datos Rendimiento constante.

Puntos centrales

• Arquitectura: Un hilo de limpieza vacía las páginas sucias independientemente de las instancias del pool de búferes.
• Versiones: La variable innodb_page_cleaners Se eliminó a partir de MariaDB 10.6.
• Enfoque de la LRU: La selección de borrado se basa en el fin del LRU y en el progreso del punto de control.
• Mito: Un mayor número de subprocesos no implica automáticamente un mejor rendimiento.
• Práctica: El tamaño del buffer pool, la capacidad de E/S y los puntos de control son los factores que más influyen en el resultado.

Qué hace exactamente Page Cleaner

El hilo de Page Cleaner dice: Sucio Devuelve las páginas del búfer de InnoDB antes de que las operaciones de los usuarios se reflejen directamente en el disco. De este modo, desacopla las operaciones de escritura de las consultas y reduce notablemente la variabilidad en los tiempos de respuesta, sobre todo durante los picos de carga. Considero que el «Cleaner» actúa como un regulador de ritmo: divide las operaciones de escritura en porciones adecuadas, en lugar de procesar grandes oleadas de forma descontrolada. El hilo se sirve de las páginas que acaban en el final de la lista LRU, para que la caché vuelva a quedar rápidamente libre para los datos más solicitados. Al mismo tiempo, impulsa el punto de control, de modo que no queden demasiados cambios sin escribir en la memoria. Quien comprenda este proceso, se dará cuenta más rápidamente de si E/S si ese es el cuello de botella o si el problema se debe más bien a una caché demasiado pequeña y a un exceso de páginas sucias.

Versión: De muchos hilos a uno solo

Históricamente, se podían configurar varios «cleaners», pero MariaDB 10.5.1 inició la reestructuración y MariaDB 10.6 eliminó innodb_page_cleaners definitivamente. Desde entonces, un solo buf_flush_page_cleaner-Un único hilo se encarga del trabajo de todas las instancias del pool de búferes. Esto reduce los costes de coordinación, simplifica el ajuste y refleja la idea de que un buen algoritmo es más importante que la diversidad de hilos. Quien siga instrucciones extraídas de artículos sobre MySQL o de otras versiones antiguas, se topará rápidamente con parámetros que hoy en día no surten efecto. Yo compruebo primero la versión exacta de MariaDB antes de ajustar los supuestos parámetros. Así evito perder tiempo y me centro en los parámetros que influyen en el Ruta de escritura influir realmente.

Pool de búfer, páginas sucias y LRU

El buffer pool almacena los datos más utilizados en la RAM y ahorra costosos Disco-accesos. En cuanto las transacciones escriben, se generan páginas sucias, que en un primer momento solo existen en la memoria. El «Cleaner» las escribe a tiempo para que la LRU quede libre al final y las páginas leídas con frecuencia permanezcan en la parte superior de la caché. Presto atención al número de instancias del «buffer pool» que están activas y a cómo se distribuye el acceso, ya que el paralelismo puede aliviar las colas de espera. Quien quiera profundizar más, encontrará consejos prácticos sobre Instancias del grupo de búferes, por ejemplo, para servidores multinúcleo. Al final, la tasa de páginas sucias indica si la frecuencia de vaciado se mantiene al mismo ritmo que la tasa de escritura y si la caché cumple su Hits suministros.

Progreso de los puntos de control y latencia

El punto de control establece un marcador hasta el cual los cambios se guardan de forma segura en el soporte de datos, y el «Page Cleaner» desplaza este marcador hacia adelante. Si el punto de control se queda atrás, aumentan el nivel de uso del registro y la amplificación de escritura, lo que se refleja en la duración del commit y en el pico de «n» durante las consultas. Compruebo periódicamente cuánto varía la distancia del punto de control y si el limpiador genera oscilaciones demasiado grandes. Si no se consigue suavizar estas oscilaciones, pueden producirse picos de actividad en los que se bloqueen los subprocesos de los usuarios. Para comprender los conceptos básicos, resulta útil echar un vistazo a Checkpointing y amplificación de escritura en el contexto del alojamiento web. Quien analice estos indicadores podrá detectar rápidamente si Descarga-si el trabajo se realiza a tiempo o si el sistema tiene que ponerse al día a toda prisa en fases posteriores.

Malentendidos habituales sobre el tuning

Muchos esperan que los subprocesos en segundo plano adicionales proporcionen automáticamente un mayor rendimiento, pero en este caso no es así. Lo decisivo sigue siendo la calidad del algoritmo de vaciado y la dosis adecuada de E/S-Trabajo por intervalo. Un limpiador demasiado agresivo genera picos de carga breves que aumentan los tiempos de respuesta. Un limpiador demasiado moderado acumula demasiadas páginas sucias, lo que provoca posteriormente oleadas de vaciado más grandes. Ambas situaciones se perciben como un efecto de acordeón en las latencias. Por eso busco un patrón uniforme que se adapte al subsistema de memoria y que afecte lo menos posible a los hilos de los usuarios. bloqueado.

Métricas y supervisión: lo que compruebo

Para tomar decisiones, me baso en las cifras, no en corazonadas. Superviso el porcentaje de páginas sucias, el progreso de los puntos de control, las tasas de escritura y Fsync, así como los tiempos de espera en el registro de redo y los archivos de datos. Si los tiempos de confirmación varían bajo carga, echo un vistazo a los atrasos de vaciado y al tamaño de los archivos del registro de redo. La proporción de páginas al final de la lista LRU también da una idea de la presión de expulsión y de la necesidad de realizar operaciones de vaciado. Los valores atípicos en las IOPS indican que el «cleaner» está escribiendo paquetes demasiado grandes o que se ha alcanzado el límite de almacenamiento. Estos puntos de medición revelan si el cuello de botella se debe más bien al tamaño de la caché, Memoria-En lo que respecta al rendimiento o a la estrategia de purga.

Configuración: cómo elegir correctamente las dimensiones y la capacidad de E/S

Los parámetros más importantes siguen siendo el tamaño del pool de búfer, la capacidad de E/S y la estructura del registro. Un pool de búfer más grande reduce la carga de lectura, pero no debe permitir que la proporción de páginas sucias crezca sin control. Los parámetros de capacidad de E/S controlan la cantidad de datos que el «cleaner» intenta escribir en una unidad de tiempo. Los valores demasiado bajos provocan atascos, mientras que los demasiado altos generan picos en el perfil de latencia. Yo ajusto estas magnitudes al sistema de almacenamiento real, en lugar de fiarme de valores estándar abstractos. La siguiente tabla resume los ajustes relevantes que determinan el comportamiento del Descarga-marcar el proceso.

Actuación/Aspecto	Efecto sobre Page Cleaner	Nota para MariaDB	Orientación práctica
innodb_buffer_pool_size	Influye en la cantidad de páginas sucias y en la presión de expulsión	Un pool más grande requiere una cadencia de flush constante	Utilizar la RAM, pero dejar una reserva para el sistema operativo y Consulta-Dejar la caché
innodb_io_capacity / innodb_io_capacity_max	Alcance limitado de los trabajos de purga previstos	Ajustar a las IOPS reales de SSD/NVMe	Empezar con un valor conservador y luego ir aumentándolo poco a poco
innodb_flush_log_at_trx_commit	Controla la frecuencia de «commit-Fsync»	La elección influye en la latencia y la vida útil	„1“ para la máxima vida útil; „2/0“ para una menor Latencia
Tamaño del registro de rehacer	Actúa sobre la distancia de Checkpoint y las ondas de Flush	Si es demasiado pequeño, obliga a realizar comprobaciones frecuentes	Aumentar el tamaño para suavizar los picos de escritura
innodb_page_cleaners (antiguo)	Hoy sin influencia	Eliminado a partir de MariaDB 10.6	No volver a tocarlo, centrarse en las acciones activas Parámetros

Guía práctica: cómo realizar pruebas paso a paso

Empiezo con una referencia clara bajo carga antes de modificar los ajustes. A continuación, ajusto innodb_io_capacity Poco a poco, y observo si los picos de latencia se producen con menos frecuencia. Si se producen oleadas de vaciado prolongadas, aumento el tamaño del redo log para que el punto de control disponga de más espacio en el búfer. A continuación, compruebo si el buffer pool tiene suficiente espacio para que los datos activos no sean desplazados demasiado rápido. A cada cambio le doy tiempo suficiente para que sus efectos y efectos secundarios se manifiesten con claridad. Solo cuando los indicadores y la experiencia del usuario mejoran conjuntamente, marco la casilla Paso de.

Influencia del búfer de doble escritura

El búfer de doble escritura protege las páginas frente a escrituras parciales y bloques dañados, pero al mismo tiempo afecta a la velocidad de escritura y a los patrones de vaciado. Especialmente cuando el porcentaje de actualizaciones es elevado, puede influir en el rendimiento percibido del limpiador. Los sistemas de almacenamiento modernos con orden de escritura persistente mitigan en parte este efecto, pero sigue siendo medible. Por eso, antes de ajustar este parámetro, compruebo la carga de trabajo, las expectativas de integridad de los datos y la latencia aceptable. Quien necesite más detalles al respecto, encontrará información adicional en el artículo sobre el Búfer de doble escritura. De este modo, se puede decidir si la vida útil y Protección Se le da prioridad a la latencia mínima.

Síntomas frecuentes y medidas para combatirlos

Si los tiempos de commit se disparan a pesar de que la CPU está libre, eso indica un atasco en el flushing o un almacenamiento deficiente. Las fuertes fluctuaciones en las IOPS apuntan a paquetes de flushing demasiado grandes; en ese caso, reduzco la capacidad de E/S y amplío el redo log. Si el porcentaje de páginas sucias se mantiene elevado de forma permanente, significa que el limpiador funciona de forma demasiado defensiva o que el pool de búferes es demasiado pequeño. Si las páginas más utilizadas se deslizan rápidamente hacia el final de la lista LRU, significa que falta espacio en la caché o que la carga de escritura está saturando demasiado el pool. En entornos de alojamiento, el almacenamiento compartido suele suponer un lastre; en estos casos, lo único que ayuda es medir la carga a lo largo del día y, si es necesario, cambiar a soportes más rápidos. Documento cada cambio para que la causa y Efecto que se mantenga claro en el futuro.

Cómo establece el «Cleaner» las prioridades entre la lista «Flush» y la LRU

InnoDB distingue entre dos fuentes principales a la hora de escribir: la lista LRU (páginas que deben dejar espacio para nuevos accesos) y la lista de vaciado (todas las páginas sucias, ordenadas por el número de secuencia de registro más antiguo). El «Page Cleaner» equilibra estos dos objetivos: limpia el final de la lista LRU para evitar expulsiones y, al mismo tiempo, extrae elementos de la lista de vaciado para hacer avanzar constantemente el punto de control. Si el espacio libre en el búfer se ve sometido a presión, tiene prioridad el vaciado de la lista LRU; por el contrario, si la distancia del punto de control aumenta, el limpiador incrementa la proporción procedente de la lista de vaciado. Este cambio explica por qué los perfiles de latencia varían con las cargas de trabajo cambiantes: si aumenta la presión de lectura, predominan los vaciados LRU; si aumenta la presión de escritura, predomina el trabajo del punto de control. Analizo este patrón en la supervisión para decidir si debo ajustar más la capacidad de E/S o la reserva del registro de rehacer.

Lavado adaptativo: cómo interpretar correctamente los umbrales

MariaDB utiliza el flushing adaptativo para ajustar dinámicamente la tasa de escritura en función del consumo de redo y del porcentaje de páginas sucias. En la práctica, tengo en cuenta tres parámetros: el valor objetivo de páginas sucias, el nivel mínimo (low-water-mark) y la tasa de escritura actual. Si la proporción de páginas sucias supera el valor objetivo, el «cleaner» se vuelve más estricto; si cae por debajo, se muestra más moderado. Un umbral de «Low-Water» demasiado bajo provoca que el vaciado se active con frecuencia y puede generar picos de latencia breves pero perceptibles. Un umbral demasiado alto deja demasiados datos sucios en la memoria, lo que posteriormente genera problemas más graves. Ajusto los umbrales de manera que se adapten a las características del sistema de almacenamiento: los SSD NVMe rápidos soportan tasas de vaciado continuas y moderadamente más altas; los sistemas más lentos se benefician de lotes más pequeños y uniformes.

Utilizar de forma adecuada las opciones específicas de almacenamiento

El Page Cleaner no funciona en el vacío: la elección del método de vaciado y el comportamiento del sistema de archivos determinan el resultado. Con innodb_flush_method Controlo si InnoDB escribe las páginas directamente (O_DIRECT) o a través de la caché del sistema operativo. La escritura directa evita el doble almacenamiento en caché y estabiliza las latencias en Linux con XFS/EXT4. Sin embargo, los sistemas de archivos como ZFS gestionan O_DIRECT de forma diferente; en ese caso, compruebo si se utiliza un método sincronizado (fsync/O_DSYNC) ofrece un perfil más coherente. Además, merece la pena echar un vistazo al «neighborhood flushing» (vecinos contiguos): En las matrices de discos duros (HDD), puede resultar útil la escritura simultánea de bloques adyacentes; en SSD/NVMe, la reduzco para evitar una amplificación de escritura innecesaria. Lo fundamental es que la configuración se adapte al soporte físico: el mejor algoritmo de limpieza sirve de poco si el almacenamiento subyacente se ve ralentizado.

El seguimiento en la práctica: consultas que me ayudan

Para tener una visión general rápida, utilizo tres perspectivas: los valores de estado globales, las métricas de InnoDB y el volcado periódico.

• Cifras clave: SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';, ... LIKE 'Innodb_os_log_written';, ... LIKE 'Innodb_log_waits';. Subir esperas de registro, el registro de repetición es demasiado pequeño o el proceso de vaciado es demasiado lento.
• Nivel de detalle: SHOW ENGINE INNODB STATUS\G Proporciona posiciones de puntos de control (LSN), longitudes de las listas de vaciado e indicaciones sobre cuellos de botella. Comparo el „número de secuencia de registro“ y el „último punto de control“ para estimar la distancia entre puntos de control.
• Telemetría más precisa: SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%'; o ... LIKE 'log_%'; muestra tendencias que pueden pasarse por alto fácilmente en pruebas breves.

Lo importante es la correlación: si las latencias de commit aumentan al mismo tiempo que la tasa de Fsync, es probable que el «cleaner» esté configurado con un valor demasiado estricto. Si la proporción de páginas sucias y la distancia entre puntos de control aumentan al mismo tiempo, significa que falta rendimiento de flushing o que el registro de redo es demasiado pequeño.

Perfiles de carga de trabajo: OLTP, generación de informes, procesamiento masivo

Dependiendo de la carga de trabajo, me centro en distintos aspectos. En entornos OLTP, mi objetivo es realizar pequeños lotes de vaciado de forma constante y mantener una banda de latencia estrecha; en este caso, se configuran moderadamente innodb_io_capacity y disponer de suficientes búferes de redo es fundamental. Para las ventanas de generación de informes o ETL, acepto temporalmente tasas de vaciado más altas, pero me aseguro de que no se prolonguen hasta las horas de mayor actividad de los usuarios. En la carga masiva de datos, prefiero registros de redo más grandes y —si los requisitos de durabilidad lo permiten— una disciplina de Fsync temporalmente reducida (innodb_flush_log_at_trx_commit=2). De este modo, el Page Cleaner puede seguir „trabajando en segundo plano“ de forma continua, sin ralentizar las transacciones de los usuarios. Una vez finalizado el proceso, vuelvo a establecer los valores más estrictos para que el funcionamiento diario se mantenga estable.

Procesos de larga duración, purga y efectos indirectos

Aunque el hilo de purga tenga otros objetivos (limpiar versiones antiguas), su velocidad influye en el panorama general. Si las versiones antiguas permanecen mucho tiempo sin eliminarse, aumenta el espacio necesario y la carga de memoria y de E/S se distribuye de forma menos óptima. Esto puede suponer una carga indirecta para el „Page Cleaner“, ya que hay más páginas ocupadas en el pool y la LRU se ve sometida a presión más rápidamente. Por eso vigilo de cerca los retrasos en la purga y me aseguro de que ninguna transacción de larga duración «bloquee» el sistema. Un avance estable de la purga, un «Cleaner» continuo y un ritmo de escritura equilibrado: estos tres engranajes deben encajar entre sí.

Lista de comprobación para la resolución de problemas en la ruta de escritura

• ¿La distancia entre puntos de control es elevada y sigue aumentando? Aumenta el tamaño del registro de repetición y innodb_io_capacity Subir el nivel y volver a comprobar el perfil.
• ¿Picos de IOPS y picos de commit? innodb_io_capacity Reducir ligeramente, suavizar el tamaño del lote, tener en cuenta el efecto de doble escritura.
• ¿El porcentaje de páginas sucias se mantiene elevado? Aumenta el tamaño del buffer pool o ajusta el flushing adaptativo para que sea más estricto; comprueba la carga de trabajo en los hotsets.
• ¿Se ven las esperas de registro? O bien la reserva de Redo es demasiado pequeña, o bien el Flush va con retraso. Primero hay que aumentar la reserva de Redo y, después, ajustar con precisión el rendimiento del Cleaner.
• ¿El progreso de LSN es irregular? Los paquetes «flush» son inconsistentes. Cambia los valores poco a poco hasta que se observe un progreso más regular.
• ¿Cuellos de botella relacionados con el almacenamiento? Comprueba el método «flush», el programador y la configuración de la caché RAID/SAN; utiliza como objetivo las IOPS sostenidas en lugar de las picos.

Ejemplo: calibración en tres rondas

En una instancia OLTP con gran volumen de escritura, empiezo realizando una medición de carga en el entorno de producción. Ronda 1: Mido los niveles de llenado del registro de redo y la distancia de checkpoint. El registro suele estar ocupado en un 70-80 % (%), mientras que la distancia varía mucho, por lo que duplico el tamaño del redo. Ronda 2: tras repetir la prueba, las latencias se estabilizan, pero ocasionalmente se producen picos de Fsync. Reduzco innodb_io_capacity Moderado, hasta que la distribución de IOPS se estabilice. Ronda 3: La tasa de páginas sucias se mantiene en el límite superior. Asigno más RAM al buffer pool, lo que alivia la carga de la LRU y hace que el trabajo del limpiador sea más predecible. Resultado: el Commit-P95 desciende notablemente, la curva de IOPS se vuelve más uniforme y el punto de control avanza de forma constante —exactamente el patrón que busco—.

Brevemente resumido

Un único hilo de limpieza organiza el vaciado de las páginas sucias, mantiene el punto de control en movimiento y protege las consultas frente a picos intensos de escritura. Los parámetros relevantes siguen siendo el tamaño del pool de búferes, la capacidad de E/S, la estructura del registro de rehacer y las características del sistema de almacenamiento. Los parámetros obsoletos, como innodb_page_cleaners Ya no les presto atención y me centro en los indicadores que tienen una influencia directa. Quien analice métricas como la tasa de páginas sucias, el intervalo entre puntos de control y la duración del commit, detectará los cuellos de botella más rápidamente. Los cambios graduales con una línea de base clara proporcionan resultados fiables, sin ocultar efectos secundarios. Así, el Page Cleaner funciona silenciosamente en segundo plano, y la Tiempo de respuesta se mantiene constante, incluso bajo carga.