{"id":21467,"date":"2026-09-16T18:21:26","date_gmt":"2026-09-16T16:21:26","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-page-cleaner-threads-datenbank\/"},"modified":"2026-09-16T18:21:26","modified_gmt":"2026-09-16T16:21:26","slug":"mariadb-limpiador-de-paginas-subprocesos-base-de-datos","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"Entender los subprocesos del \u00abPage Cleaner\u00bb de MariaDB: c\u00f3mo influyen en el rendimiento"},"content":{"rendered":"<p><strong>Limpiador de p\u00e1ginas<\/strong> Los hilos de MariaDB controlan la forma en que InnoDB escribe las p\u00e1ginas 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 \u00fanico hilo de limpieza, evitar\u00e1 cuellos de botella en la ruta de escritura y mantendr\u00e1 la <strong>base de datos<\/strong> Rendimiento constante.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Arquitectura<\/strong>: Un hilo de limpieza vac\u00eda las p\u00e1ginas sucias independientemente de las instancias del pool de b\u00faferes.<\/li>\n  <li><strong>Versiones<\/strong>: La variable <code>innodb_page_cleaners<\/code> Se elimin\u00f3 a partir de MariaDB 10.6.<\/li>\n  <li><strong>Enfoque de la LRU<\/strong>: La selecci\u00f3n de borrado se basa en el fin del LRU y en el progreso del punto de control.<\/li>\n  <li><strong>Mito<\/strong>: Un mayor n\u00famero de subprocesos no implica autom\u00e1ticamente un mejor rendimiento.<\/li>\n  <li><strong>Pr\u00e1ctica<\/strong>: El tama\u00f1o del buffer pool, la capacidad de E\/S y los puntos de control son los factores que m\u00e1s influyen en el resultado.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/server-performance-5647.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Qu\u00e9 hace exactamente Page Cleaner<\/h2>\n\n<p>El hilo de Page Cleaner dice: <strong>Sucio<\/strong> Devuelve las p\u00e1ginas del b\u00fafer 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 \u00abCleaner\u00bb act\u00faa 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\u00e1ginas que acaban en el final de la lista LRU, para que la cach\u00e9 vuelva a quedar r\u00e1pidamente libre para los datos m\u00e1s 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\u00e1 cuenta m\u00e1s r\u00e1pidamente de si <strong>E\/S<\/strong> si ese es el cuello de botella o si el problema se debe m\u00e1s bien a una cach\u00e9 demasiado peque\u00f1a y a un exceso de p\u00e1ginas sucias.<\/p>\n\n<h2>Versi\u00f3n: De muchos hilos a uno solo<\/h2>\n\n<p>Hist\u00f3ricamente, se pod\u00edan configurar varios \u00abcleaners\u00bb, pero MariaDB 10.5.1 inici\u00f3 la reestructuraci\u00f3n y MariaDB 10.6 elimin\u00f3 <strong>innodb_page_cleaners<\/strong> definitivamente. Desde entonces, un solo <code>buf_flush_page_cleaner<\/code>-Un \u00fanico hilo se encarga del trabajo de todas las instancias del pool de b\u00faferes. Esto reduce los costes de coordinaci\u00f3n, simplifica el ajuste y refleja la idea de que un buen algoritmo es m\u00e1s importante que la diversidad de hilos. Quien siga instrucciones extra\u00eddas de art\u00edculos sobre MySQL o de otras versiones antiguas, se topar\u00e1 r\u00e1pidamente con par\u00e1metros que hoy en d\u00eda no surten efecto. Yo compruebo primero la versi\u00f3n exacta de MariaDB antes de ajustar los supuestos par\u00e1metros. As\u00ed evito perder tiempo y me centro en los par\u00e1metros que influyen en el <strong>Ruta de escritura<\/strong> influir realmente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_perfmeeting_3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pool de b\u00fafer, p\u00e1ginas sucias y LRU<\/h2>\n\n<p>El buffer pool almacena los datos m\u00e1s utilizados en la RAM y ahorra costosos <strong>Disco<\/strong>-accesos. En cuanto las transacciones escriben, se generan p\u00e1ginas sucias, que en un primer momento solo existen en la memoria. El \u00abCleaner\u00bb las escribe a tiempo para que la LRU quede libre al final y las p\u00e1ginas le\u00eddas con frecuencia permanezcan en la parte superior de la cach\u00e9. Presto atenci\u00f3n al n\u00famero de instancias del \u00abbuffer pool\u00bb que est\u00e1n activas y a c\u00f3mo se distribuye el acceso, ya que el paralelismo puede aliviar las colas de espera. Quien quiera profundizar m\u00e1s, encontrar\u00e1 consejos pr\u00e1cticos sobre <a href=\"https:\/\/webhosting.de\/es\/mariadb-grupo-de-buferes-instancias-sistemas-multinucleo-optimizacion-del-rendimiento-base-de-datos\/\">Instancias del grupo de b\u00faferes<\/a>, por ejemplo, para servidores multin\u00facleo. Al final, la tasa de p\u00e1ginas sucias indica si la frecuencia de vaciado se mantiene al mismo ritmo que la tasa de escritura y si la cach\u00e9 cumple su <strong>Hits<\/strong> suministros.<\/p>\n\n<h2>Progreso de los puntos de control y latencia<\/h2>\n\n<p>El punto de control establece un marcador hasta el cual los cambios se guardan de forma segura en el soporte de datos, y el \u00abPage Cleaner\u00bb desplaza este marcador hacia adelante. Si el punto de control se queda atr\u00e1s, aumentan el nivel de uso del registro y la amplificaci\u00f3n de escritura, lo que se refleja en la duraci\u00f3n del commit y en el pico de \u00abn\u00bb durante las consultas. Compruebo peri\u00f3dicamente cu\u00e1nto var\u00eda 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\u00e1sicos, resulta \u00fatil echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/base-de-datos-checkpointing-escritura-amplificacion-alojamiento-guia-escalado\/\">Checkpointing y amplificaci\u00f3n de escritura<\/a> en el contexto del alojamiento web. Quien analice estos indicadores podr\u00e1 detectar r\u00e1pidamente si <strong>Descarga<\/strong>-si el trabajo se realiza a tiempo o si el sistema tiene que ponerse al d\u00eda a toda prisa en fases posteriores.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-threads-performance-6574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Malentendidos habituales sobre el tuning<\/h2>\n\n<p>Muchos esperan que los subprocesos en segundo plano adicionales proporcionen autom\u00e1ticamente un mayor rendimiento, pero en este caso no es as\u00ed. Lo decisivo sigue siendo la calidad del algoritmo de vaciado y la dosis adecuada de <strong>E\/S<\/strong>-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\u00e1ginas sucias, lo que provoca posteriormente oleadas de vaciado m\u00e1s grandes. Ambas situaciones se perciben como un efecto de acorde\u00f3n en las latencias. Por eso busco un patr\u00f3n uniforme que se adapte al subsistema de memoria y que afecte lo menos posible a los hilos de los usuarios. <strong>bloqueado<\/strong>.<\/p>\n\n<h2>M\u00e9tricas y supervisi\u00f3n: lo que compruebo<\/h2>\n\n<p>Para tomar decisiones, me baso en las cifras, no en corazonadas. Superviso el porcentaje de p\u00e1ginas sucias, el progreso de los puntos de control, las tasas de escritura y Fsync, as\u00ed como los tiempos de espera en el registro de redo y los archivos de datos. Si los tiempos de confirmaci\u00f3n var\u00edan bajo carga, echo un vistazo a los atrasos de vaciado y al tama\u00f1o de los archivos del registro de redo. La proporci\u00f3n de p\u00e1ginas al final de la lista LRU tambi\u00e9n da una idea de la presi\u00f3n de expulsi\u00f3n y de la necesidad de realizar operaciones de vaciado. Los valores at\u00edpicos en las IOPS indican que el \u00abcleaner\u00bb est\u00e1 escribiendo paquetes demasiado grandes o que se ha alcanzado el l\u00edmite de almacenamiento. Estos puntos de medici\u00f3n revelan si el cuello de botella se debe m\u00e1s bien al tama\u00f1o de la cach\u00e9, <strong>Memoria<\/strong>-En lo que respecta al rendimiento o a la estrategia de purga.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_page_cleaner_5372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuraci\u00f3n: c\u00f3mo elegir correctamente las dimensiones y la capacidad de E\/S<\/h2>\n\n<p>Los par\u00e1metros m\u00e1s importantes siguen siendo el tama\u00f1o del pool de b\u00fafer, la capacidad de E\/S y la estructura del registro. Un pool de b\u00fafer m\u00e1s grande reduce la carga de lectura, pero no debe permitir que la proporci\u00f3n de p\u00e1ginas sucias crezca sin control. Los par\u00e1metros de capacidad de E\/S controlan la cantidad de datos que el \u00abcleaner\u00bb 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\u00e1ndar abstractos. La siguiente tabla resume los ajustes relevantes que determinan el comportamiento del <strong>Descarga<\/strong>-marcar el proceso.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Actuaci\u00f3n\/Aspecto<\/th>\n      <th>Efecto sobre Page Cleaner<\/th>\n      <th>Nota para MariaDB<\/th>\n      <th>Orientaci\u00f3n pr\u00e1ctica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_size<\/code><\/td>\n      <td>Influye en la cantidad de p\u00e1ginas sucias y en la presi\u00f3n de expulsi\u00f3n<\/td>\n      <td>Un pool m\u00e1s grande requiere una cadencia de flush constante<\/td>\n      <td>Utilizar la RAM, pero dejar una reserva para el sistema operativo y <strong>Consulta<\/strong>-Dejar la cach\u00e9<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_capacity<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>Alcance limitado de los trabajos de purga previstos<\/td>\n      <td>Ajustar a las IOPS reales de SSD\/NVMe<\/td>\n      <td>Empezar con un valor conservador y luego ir aument\u00e1ndolo poco a poco<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Controla la frecuencia de \u00abcommit-Fsync\u00bb<\/td>\n      <td>La elecci\u00f3n influye en la latencia y la vida \u00fatil<\/td>\n      <td>\u201e1\u201c para la m\u00e1xima vida \u00fatil; \u201e2\/0\u201c para una menor <strong>Latencia<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Tama\u00f1o del registro de rehacer<\/td>\n      <td>Act\u00faa sobre la distancia de Checkpoint y las ondas de Flush<\/td>\n      <td>Si es demasiado peque\u00f1o, obliga a realizar comprobaciones frecuentes<\/td>\n      <td>Aumentar el tama\u00f1o para suavizar los picos de escritura<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (antiguo)<\/td>\n      <td>Hoy sin influencia<\/td>\n      <td>Eliminado a partir de MariaDB 10.6<\/td>\n      <td>No volver a tocarlo, centrarse en las acciones activas <strong>Par\u00e1metros<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Gu\u00eda pr\u00e1ctica: c\u00f3mo realizar pruebas paso a paso<\/h2>\n\n<p>Empiezo con una referencia clara bajo carga antes de modificar los ajustes. A continuaci\u00f3n, ajusto <code>innodb_io_capacity<\/code> 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\u00f1o del redo log para que el punto de control disponga de m\u00e1s espacio en el b\u00fafer. A continuaci\u00f3n, compruebo si el buffer pool tiene suficiente espacio para que los datos activos no sean desplazados demasiado r\u00e1pido. 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 <strong>Paso<\/strong> de.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-pagecleaner-4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Influencia del b\u00fafer de doble escritura<\/h2>\n\n<p>El b\u00fafer de doble escritura protege las p\u00e1ginas frente a escrituras parciales y bloques da\u00f1ados, 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\u00e1metro, compruebo la carga de trabajo, las expectativas de integridad de los datos y la latencia aceptable. Quien necesite m\u00e1s detalles al respecto, encontrar\u00e1 informaci\u00f3n adicional en el art\u00edculo sobre el <a href=\"https:\/\/webhosting.de\/es\/innodb-doble-bufer-de-escritura-seguridad-optimizacion-del-rendimiento-enfoque\/\">B\u00fafer de doble escritura<\/a>. De este modo, se puede decidir si la vida \u00fatil y <strong>Protecci\u00f3n<\/strong> Se le da prioridad a la latencia m\u00ednima.<\/p>\n\n<h2>S\u00edntomas frecuentes y medidas para combatirlos<\/h2>\n\n<p>Si los tiempos de commit se disparan a pesar de que la CPU est\u00e1 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\u00edo el redo log. Si el porcentaje de p\u00e1ginas sucias se mantiene elevado de forma permanente, significa que el limpiador funciona de forma demasiado defensiva o que el pool de b\u00faferes es demasiado peque\u00f1o. Si las p\u00e1ginas m\u00e1s utilizadas se deslizan r\u00e1pidamente hacia el final de la lista LRU, significa que falta espacio en la cach\u00e9 o que la carga de escritura est\u00e1 saturando demasiado el pool. En entornos de alojamiento, el almacenamiento compartido suele suponer un lastre; en estos casos, lo \u00fanico que ayuda es medir la carga a lo largo del d\u00eda y, si es necesario, cambiar a soportes m\u00e1s r\u00e1pidos. Documento cada cambio para que la causa y <strong>Efecto<\/strong> que se mantenga claro en el futuro.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-performance-4629.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo establece el \u00abCleaner\u00bb las prioridades entre la lista \u00abFlush\u00bb y la LRU<\/h2>\n<p>InnoDB distingue entre dos fuentes principales a la hora de escribir: la lista LRU (p\u00e1ginas que deben dejar espacio para nuevos accesos) y la lista de vaciado (todas las p\u00e1ginas sucias, ordenadas por el n\u00famero de secuencia de registro m\u00e1s antiguo). El \u00abPage Cleaner\u00bb 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\u00fafer se ve sometido a presi\u00f3n, tiene prioridad el vaciado de la lista LRU; por el contrario, si la distancia del punto de control aumenta, el limpiador incrementa la proporci\u00f3n procedente de la lista de vaciado. Este cambio explica por qu\u00e9 los perfiles de latencia var\u00edan con las cargas de trabajo cambiantes: si aumenta la presi\u00f3n de lectura, predominan los vaciados LRU; si aumenta la presi\u00f3n de escritura, predomina el trabajo del punto de control. Analizo este patr\u00f3n en la supervisi\u00f3n para decidir si debo ajustar m\u00e1s la capacidad de E\/S o la reserva del registro de rehacer.<\/p>\n\n<h2>Lavado adaptativo: c\u00f3mo interpretar correctamente los umbrales<\/h2>\n<p>MariaDB utiliza el flushing adaptativo para ajustar din\u00e1micamente la tasa de escritura en funci\u00f3n del consumo de redo y del porcentaje de p\u00e1ginas sucias. En la pr\u00e1ctica, tengo en cuenta tres par\u00e1metros: el valor objetivo de p\u00e1ginas sucias, el nivel m\u00ednimo (low-water-mark) y la tasa de escritura actual. Si la proporci\u00f3n de p\u00e1ginas sucias supera el valor objetivo, el \u00abcleaner\u00bb se vuelve m\u00e1s estricto; si cae por debajo, se muestra m\u00e1s moderado. Un umbral de \u00abLow-Water\u00bb 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\u00e1s graves. Ajusto los umbrales de manera que se adapten a las caracter\u00edsticas del sistema de almacenamiento: los SSD NVMe r\u00e1pidos soportan tasas de vaciado continuas y moderadamente m\u00e1s altas; los sistemas m\u00e1s lentos se benefician de lotes m\u00e1s peque\u00f1os y uniformes.<\/p>\n\n<h2>Utilizar de forma adecuada las opciones espec\u00edficas de almacenamiento<\/h2>\n<p>El Page Cleaner no funciona en el vac\u00edo: la elecci\u00f3n del m\u00e9todo de vaciado y el comportamiento del sistema de archivos determinan el resultado. Con <code>innodb_flush_method<\/code> Controlo si InnoDB escribe las p\u00e1ginas directamente (O_DIRECT) o a trav\u00e9s de la cach\u00e9 del sistema operativo. La escritura directa evita el doble almacenamiento en cach\u00e9 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\u00e9todo sincronizado (<em>fsync<\/em>\/<em>O_DSYNC<\/em>) ofrece un perfil m\u00e1s coherente. Adem\u00e1s, merece la pena echar un vistazo al \u00abneighborhood flushing\u00bb (<em>vecinos contiguos<\/em>): En las matrices de discos duros (HDD), puede resultar \u00fatil la escritura simult\u00e1nea de bloques adyacentes; en SSD\/NVMe, la reduzco para evitar una amplificaci\u00f3n de escritura innecesaria. Lo fundamental es que la configuraci\u00f3n se adapte al soporte f\u00edsico: el mejor algoritmo de limpieza sirve de poco si el almacenamiento subyacente se ve ralentizado.<\/p>\n\n<h2>El seguimiento en la pr\u00e1ctica: consultas que me ayudan<\/h2>\n<p>Para tener una visi\u00f3n general r\u00e1pida, utilizo tres perspectivas: los valores de estado globales, las m\u00e9tricas de InnoDB y el volcado peri\u00f3dico.<\/p>\n<ul>\n  <li>Cifras clave: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Subir <em>esperas de registro<\/em>, el registro de repetici\u00f3n es demasiado peque\u00f1o o el proceso de vaciado es demasiado lento.<\/li>\n  <li>Nivel de detalle: <code>SHOW ENGINE INNODB STATUS\\G<\/code> Proporciona posiciones de puntos de control (LSN), longitudes de las listas de vaciado e indicaciones sobre cuellos de botella. Comparo el \u201en\u00famero de secuencia de registro\u201c y el \u201e\u00faltimo punto de control\u201c para estimar la distancia entre puntos de control.<\/li>\n  <li>Telemetr\u00eda m\u00e1s precisa: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> o <code>... LIKE 'log_%';<\/code> muestra tendencias que pueden pasarse por alto f\u00e1cilmente en pruebas breves.<\/li>\n<\/ul>\n<p>Lo importante es la correlaci\u00f3n: si las latencias de commit aumentan al mismo tiempo que la tasa de Fsync, es probable que el \u00abcleaner\u00bb est\u00e9 configurado con un valor demasiado estricto. Si la proporci\u00f3n de p\u00e1ginas 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\u00f1o.<\/p>\n\n<h2>Perfiles de carga de trabajo: OLTP, generaci\u00f3n de informes, procesamiento masivo<\/h2>\n<p>Dependiendo de la carga de trabajo, me centro en distintos aspectos. En entornos OLTP, mi objetivo es realizar peque\u00f1os lotes de vaciado de forma constante y mantener una banda de latencia estrecha; en este caso, se configuran moderadamente <code>innodb_io_capacity<\/code> y disponer de suficientes b\u00faferes de redo es fundamental. Para las ventanas de generaci\u00f3n de informes o ETL, acepto temporalmente tasas de vaciado m\u00e1s 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\u00e1s grandes y \u2014si los requisitos de durabilidad lo permiten\u2014 una disciplina de Fsync temporalmente reducida (<code>innodb_flush_log_at_trx_commit=2<\/code>). De este modo, el Page Cleaner puede seguir \u201etrabajando en segundo plano\u201c de forma continua, sin ralentizar las transacciones de los usuarios. Una vez finalizado el proceso, vuelvo a establecer los valores m\u00e1s estrictos para que el funcionamiento diario se mantenga estable.<\/p>\n\n<h2>Procesos de larga duraci\u00f3n, purga y efectos indirectos<\/h2>\n<p>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 \u00f3ptima. Esto puede suponer una carga indirecta para el \u201ePage Cleaner\u201c, ya que hay m\u00e1s p\u00e1ginas ocupadas en el pool y la LRU se ve sometida a presi\u00f3n m\u00e1s r\u00e1pidamente. Por eso vigilo de cerca los retrasos en la purga y me aseguro de que ninguna transacci\u00f3n de larga duraci\u00f3n \u00abbloquee\u00bb el sistema. Un avance estable de la purga, un \u00abCleaner\u00bb continuo y un ritmo de escritura equilibrado: estos tres engranajes deben encajar entre s\u00ed.<\/p>\n\n<h2>Lista de comprobaci\u00f3n para la resoluci\u00f3n de problemas en la ruta de escritura<\/h2>\n<ul>\n  <li>\u00bfLa distancia entre puntos de control es elevada y sigue aumentando? Aumenta el tama\u00f1o del registro de repetici\u00f3n y <code>innodb_io_capacity<\/code> Subir el nivel y volver a comprobar el perfil.<\/li>\n  <li>\u00bfPicos de IOPS y picos de commit? <code>innodb_io_capacity<\/code> Reducir ligeramente, suavizar el tama\u00f1o del lote, tener en cuenta el efecto de doble escritura.<\/li>\n  <li>\u00bfEl porcentaje de p\u00e1ginas sucias se mantiene elevado? Aumenta el tama\u00f1o del buffer pool o ajusta el flushing adaptativo para que sea m\u00e1s estricto; comprueba la carga de trabajo en los hotsets.<\/li>\n  <li>\u00bfSe ven las esperas de registro? O bien la reserva de Redo es demasiado peque\u00f1a, o bien el Flush va con retraso. Primero hay que aumentar la reserva de Redo y, despu\u00e9s, ajustar con precisi\u00f3n el rendimiento del Cleaner.<\/li>\n  <li>\u00bfEl progreso de LSN es irregular? Los paquetes \u00abflush\u00bb son inconsistentes. Cambia los valores poco a poco hasta que se observe un progreso m\u00e1s regular.<\/li>\n  <li>\u00bfCuellos de botella relacionados con el almacenamiento? Comprueba el m\u00e9todo \u00abflush\u00bb, el programador y la configuraci\u00f3n de la cach\u00e9 RAID\/SAN; utiliza como objetivo las IOPS sostenidas en lugar de las picos.<\/li>\n<\/ul>\n\n<h2>Ejemplo: calibraci\u00f3n en tres rondas<\/h2>\n<p>En una instancia OLTP con gran volumen de escritura, empiezo realizando una medici\u00f3n de carga en el entorno de producci\u00f3n. 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\u00eda mucho, por lo que duplico el tama\u00f1o del redo. Ronda 2: tras repetir la prueba, las latencias se estabilizan, pero ocasionalmente se producen picos de Fsync. Reduzco <code>innodb_io_capacity<\/code> Moderado, hasta que la distribuci\u00f3n de IOPS se estabilice. Ronda 3: La tasa de p\u00e1ginas sucias se mantiene en el l\u00edmite superior. Asigno m\u00e1s RAM al buffer pool, lo que alivia la carga de la LRU y hace que el trabajo del limpiador sea m\u00e1s predecible. Resultado: el Commit-P95 desciende notablemente, la curva de IOPS se vuelve m\u00e1s uniforme y el punto de control avanza de forma constante \u2014exactamente el patr\u00f3n que busco\u2014.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Un \u00fanico hilo de limpieza organiza el vaciado de las p\u00e1ginas sucias, mantiene el punto de control en movimiento y protege las consultas frente a picos intensos de escritura. Los par\u00e1metros relevantes siguen siendo el tama\u00f1o del pool de b\u00faferes, la capacidad de E\/S, la estructura del registro de rehacer y las caracter\u00edsticas del sistema de almacenamiento. Los par\u00e1metros obsoletos, como <strong>innodb_page_cleaners<\/strong> Ya no les presto atenci\u00f3n y me centro en los indicadores que tienen una influencia directa. Quien analice m\u00e9tricas como la tasa de p\u00e1ginas sucias, el intervalo entre puntos de control y la duraci\u00f3n del commit, detectar\u00e1 los cuellos de botella m\u00e1s r\u00e1pidamente. Los cambios graduales con una l\u00ednea de base clara proporcionan resultados fiables, sin ocultar efectos secundarios. As\u00ed, el Page Cleaner funciona silenciosamente en segundo plano, y la <strong>Tiempo de respuesta<\/strong> se mantiene constante, incluso bajo carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explicaci\u00f3n de los hilos del \u00abpage cleaner\u00bb de MariaDB: El \u00abpage cleaner\u00bb de MariaDB InnoDB influye en las p\u00e1ginas sucias y en el rendimiento de la base de datos.<\/p>","protected":false},"author":1,"featured_media":21460,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21467","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"106","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Page Cleaner","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21460","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}