{"id":21589,"date":"2026-09-20T11:47:21","date_gmt":"2026-09-20T09:47:21","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-adaptive-flushing-optimieren-performance\/"},"modified":"2026-09-20T11:47:21","modified_gmt":"2026-09-20T09:47:21","slug":"optimizar-el-vaciado-adaptativo-de-mariadb-para-mejorar-el-rendimiento","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/mariadb-adaptive-flushing-optimieren-performance\/","title":{"rendered":"Optimizar el \u00abAdaptive Flushing\u00bb de MariaDB: gu\u00eda pr\u00e1ctica para mejorar el rendimiento"},"content":{"rendered":"<p>El \u00abAdaptive Flushing\u00bb de MariaDB controla la velocidad a la que yo <strong>P\u00e1ginas sucias<\/strong> escriba desde el buffer pool al disco, para que el redo log nunca se convierta en un cuello de botella. Si optimizo el \u00abAdaptive Flushing\u00bb de MariaDB, se reducen los picos de latencia, el <strong>Punto de control<\/strong>-El avance se mantiene estable y la carga de escritura sigue siendo previsible.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Valores medidos<\/strong> En primer lugar: nivel de llenado del registro de rehacer, porcentaje de p\u00e1ginas sucias, antig\u00fcedad de los puntos de control<\/li>\n  <li><strong>Capacidad de E\/S<\/strong> determinar con exactitud, no estimar<\/li>\n  <li><strong>Valores umbral<\/strong> Configuraci\u00f3n recomendada: adaptive_flushing_lwm y Dirty-Page-LWM<\/li>\n  <li><strong>E\/S en segundo plano<\/strong> ajustar: io_capacity e io_capacity_max<\/li>\n  <li><strong>Registros de rehacer<\/strong> dimensionar adecuadamente para garantizar un flujo uniforme<\/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\/mariadb-optimierung-team-3052.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo funciona el \u00abAdaptive Flushing\u00bb en MariaDB<\/h2>\n\n<p>Activo la l\u00f3gica din\u00e1mica a trav\u00e9s de <strong>innodb_adaptive_flushing<\/strong> y controla el comportamiento de alerta temprana con <strong>innodb_adaptive_flushing_lwm<\/strong>. Cuanto m\u00e1s lleno est\u00e9 el registro de rehacer (redo log) y cuanto m\u00e1s r\u00e1pido crezca, m\u00e1s agresivamente vaciar\u00e1 InnoDB para evitar que se produzca un cuello de botella. Esta regla vincula la frecuencia de vaciado al rendimiento real de las modificaciones, lo que hace que las breves r\u00e1fagas de E\/S se produzcan con menos frecuencia. Seg\u00fan la documentaci\u00f3n de MariaDB, la intensidad se ajusta al progreso de los puntos de control para evitar tiempos de espera en las operaciones de escritura en disco. Tengo presente que el vaciado adaptativo distribuye el trabajo, pero no compensa un rendimiento de memoria insuficiente.<\/p>\n\n<h2>Entender los indicadores clave: Redo-Log, p\u00e1ginas sucias y puntos de control<\/h2>\n\n<p>Lo primero que miro es el porcentaje de llenado del <strong>Registros de rehacer<\/strong>, la tasa de p\u00e1ginas sucias en el buffer pool y la antig\u00fcedad de los puntos de control. Estos tres par\u00e1metros me indican si el servidor puede vaciar la memoria a tiempo y de forma uniforme o si se acumula trabajo. Si la edad del punto de control aumenta demasiado r\u00e1pido, se activa el vaciado adaptativo, pero en ese caso compruebo adem\u00e1s la latencia del almacenamiento. Para cuestiones detalladas sobre la estrategia de E\/S, me resulta \u00fatil echar un vistazo a los <a href=\"https:\/\/webhosting.de\/es\/mariadb-metodos-de-vaciado-innodb-fsync-guia-de-rendimiento-bufer\/\">M\u00e9todos de purga<\/a>, ya que determinan la eficiencia con la que el n\u00facleo procesa los comandos de escritura. Relaciono estas se\u00f1ales con la capacidad de E\/S medida para poder realizar ajustes en los valores umbral de forma selectiva y garantizar que el sistema en su conjunto siga funcionando de forma coherente.<\/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_flushing_meeting_1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajustar correctamente los tornillos de regulaci\u00f3n<\/h2>\n\n<p>Empiezo con <strong>innodb_io_capacity<\/strong> y establece el valor cercano a la potencia continua real del acumulador, no a los m\u00e1ximos te\u00f3ricos. Para los picos, considero que <strong>innodb_io_capacity_max<\/strong> considerablemente m\u00e1s alto, para que InnoDB pueda aumentar su rendimiento a corto plazo en caso de carga elevada sin sobrecargar la CPU. El valor umbral <strong>innodb_adaptive_flushing_lwm<\/strong> Lo configuro de tal manera que el servidor comience con el preflushing con un margen de tiempo considerable antes de que el registro de rehacer se llene. Adem\u00e1s, configuro <strong>innodb_max_dirty_pages_pct_lwm<\/strong> de tal forma que InnoDB tome medidas correctivas con antelaci\u00f3n cuando aumenta la proporci\u00f3n de p\u00e1ginas sucias y no se produzcan atascos. Solo modifico un par\u00e1metro por ciclo, registro minuciosamente el efecto y dejo que el sistema pase por varias fases de carga antes de seguir optimizando.<\/p>\n\n<h2>Medici\u00f3n concreta de la capacidad de E\/S<\/h2>\n\n<p>Mido el rendimiento de escritura continuo bajo carga de producci\u00f3n, ya que las pruebas sint\u00e9ticas de picos suelen generar falsas expectativas y la <strong>Uniformidad<\/strong> ocultar. Lo que resulta significativo son las medias y los percentiles a medio y largo plazo, que resisten los suavizamientos a corto plazo. Analizo las IOPS de escritura, el rendimiento de escritura, las latencias y la distribuci\u00f3n de los tiempos de respuesta, para no limitarme a considerar solo el valor medio. Quien se base \u00fanicamente en el valor m\u00e1ximo se arriesga a sufrir fases de vaciado agresivas, mientras que las transacciones propiamente dichas se ralentizan. Extraigo conclusiones para <strong>innodb_io_capacity<\/strong> a partir del comportamiento a largo plazo observado, no a partir de marcas m\u00e1ximas ef\u00edmeras.<\/p>\n\n<h2>Resumen de los valores iniciales y los valores l\u00edmite<\/h2>\n\n<p>Utilizo los valores predeterminados como punto de partida, nunca como un dogma, y los compruebo en funci\u00f3n de la carga de trabajo real, el tama\u00f1o del buffer pool y el crecimiento del <strong>Registros de rehacer<\/strong>. Los sistemas SSD y NVMe registran valores claramente m\u00e1s altos que los HDD, pero solo ajusto las tasas lo suficiente como para que los accesos de lectura no se pongan en cola. En el caso de sistemas con mucha actividad, voy aumentando la capacidad poco a poco y observo conjuntamente la latencia, la antig\u00fcedad de los puntos de control y el consumo de CPU. Si la tasa de p\u00e1ginas sucias desciende de forma uniforme y se reducen las oscilaciones en el nivel de llenado del registro de rehacer, me sit\u00fao en un margen de seguridad adecuado. Para m\u00ed sigue siendo fundamental que <strong>Consejos<\/strong> controlar, en lugar de sobrescribirlas con una E\/S de fondo excesiva.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Variable<\/th>\n      <th>Efecto<\/th>\n      <th>Valor inicial t\u00edpico del disco duro<\/th>\n      <th>Valor inicial t\u00edpico del SSD<\/th>\n      <th>Valor inicial t\u00edpico de NVMe<\/th>\n      <th>A qu\u00e9 presto atenci\u00f3n<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_adaptive_flushing<\/td>\n      <td>Activa el vaciado din\u00e1mico<\/td>\n      <td>EN<\/td>\n      <td>EN<\/td>\n      <td>EN<\/td>\n      <td>Compensaci\u00f3n de r\u00e1fagas<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_adaptive_flushing_lwm<\/td>\n      <td>Prelavado temprano<\/td>\n      <td>20\u201330%<\/td>\n      <td>20-40%<\/td>\n      <td>30\u201350%<\/td>\n      <td>Nivel de llenado del registro de rehacer<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity<\/td>\n      <td>Tasa b\u00e1sica de lavado<\/td>\n      <td>100-300<\/td>\n      <td>800\u20132000<\/td>\n      <td>2000\u20138000<\/td>\n      <td>IOPS de escritura continuada<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity_max<\/td>\n      <td>L\u00edmite de emergencia<\/td>\n      <td>400\u2013800<\/td>\n      <td>2000-6000<\/td>\n      <td>6000\u201320000<\/td>\n      <td>Eliminar las puntas<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_dirty_pages_pct_lwm<\/td>\n      <td>P\u00e1gina sucia - Nivel bajo de agua<\/td>\n      <td>5\u201310%<\/td>\n      <td>5\u201315%<\/td>\n      <td>5\u201315%<\/td>\n      <td>Tomar medidas correctivas a tiempo<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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-adaptive-optimierung-2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detectar casos problem\u00e1ticos y s\u00edntomas<\/h2>\n\n<p>Cuando yo <strong>Descarga<\/strong>Cuando veo picos, lo primero que compruebo es el valor de E\/S: si es demasiado bajo, se acumulan las p\u00e1ginas sucias y el sistema tiene que limpiarlas r\u00e1pidamente. Si el valor es demasiado alto, la E\/S en segundo plano se superpone a la carga de trabajo en tiempo real y obliga a las lecturas a esperar. Una \u00abCheckpoint Age\u00bb lenta que de repente se dispara me indica que el servidor reacciona con retraso. Al mismo tiempo, un nivel de llenado del \u00abredo-log\u00bb que crece r\u00e1pidamente se\u00f1ala que el lado de escritura no da abasto o que el registro tiene unas dimensiones insuficientes. Analizo estos patrones de forma conjunta, ya que una sola cifra rara vez explica por completo el comportamiento del vaciado adaptativo.<\/p>\n\n<h2>Dimensionar el registro de repetici\u00f3n (redo-log) para una carga uniforme<\/h2>\n\n<p>Elijo el tama\u00f1o del <strong>Registros de rehacer<\/strong> de modo que quede suficiente margen para las oleadas de carga, sin que los puntos de control se alarguen demasiado. Un registro m\u00e1s grande da a Adaptive Flushing m\u00e1s margen para distribuir el trabajo, pero presto atenci\u00f3n a los tiempos de recuperaci\u00f3n y al presupuesto de memoria. Si el registro crece cada segundo hasta acercarse al l\u00edmite, un aumento moderado reduce la presi\u00f3n y suaviza la curva de vaciado. Si el aumento no supone ning\u00fan alivio, el problema suele radicar en una capacidad de E\/S inadecuada o en una latencia de almacenamiento variable. Solo decido si vuelvo a aumentar el tama\u00f1o del registro tras un periodo de observaci\u00f3n, y no bas\u00e1ndome en instant\u00e1neas.<\/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_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Page Cleaner: subprocesos y paralelismo<\/h2>\n\n<p>Miro el n\u00famero de subprocesos del \u00abpage cleaner\u00bb porque representan el procesamiento en paralelo <strong>Descarga<\/strong>-Controlar el rendimiento de las instancias del pool de b\u00faferes. Cuando la carga de escritura es elevada, un mayor paralelismo aumenta el rendimiento, pero vigilo de cerca la cola de almacenamiento. Si el disco pierde eficacia debido a colas saturadas, reduzco el n\u00famero de subprocesos o limito la capacidad de E\/S. Para comprender mejor este mecanismo, me resulta \u00fatil la descripci\u00f3n general de <a href=\"https:\/\/webhosting.de\/es\/mariadb-limpiador-de-paginas-subprocesos-base-de-datos\/\">Hilos de Page Cleaner<\/a>, para mantener el equilibrio entre la presi\u00f3n y la equidad. Tomo decisiones de forma pragm\u00e1tica: tantos hilos como sean necesarios, pero tan pocos como sea razonable, para que las lecturas no se queden atr\u00e1s.<\/p>\n\n<h2>B\u00fafer de doble escritura: seguridad frente a velocidad de escritura<\/h2>\n\n<p>Tengo en cuenta la <strong>Doublewrite<\/strong>-El b\u00fafer, ya que protege contra los errores de escritura parciales, pero supone un coste adicional de E\/S. En sistemas NVMe fiables, este coste adicional tiene menos importancia, mientras que en sistemas de almacenamiento m\u00e1s lentos se nota m\u00e1s. Mido el efecto real sobre las latencias y la tasa de vaciado de p\u00e1ginas antes de ajustar este par\u00e1metro. Para tomar una decisi\u00f3n fundamentada, recurro a informaci\u00f3n m\u00e1s detallada sobre el <a href=\"https:\/\/webhosting.de\/es\/innodb-doble-bufer-de-escritura-seguridad-optimizacion-del-rendimiento-enfoque\/\">B\u00fafer de doble escritura<\/a> y compruebo si hay otro perfil de riesgo y rendimiento que se adapte a mis necesidades. Nunca tomo una decisi\u00f3n a la ligera, porque la seguridad de los datos y el rendimiento est\u00e1n directamente relacionados en este caso.<\/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_flushing_guide_4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguimiento y m\u00e9tricas en la pr\u00e1ctica<\/h2>\n\n<p>Analizo el porcentaje de \u00abDirty Pages\u00bb, la relaci\u00f3n entre la tasa de vaciado y la tasa de modificaci\u00f3n, y la evoluci\u00f3n de la <strong>Punto de control<\/strong>-Age. Adem\u00e1s, observo el porcentaje de utilizaci\u00f3n del Redo Log a lo largo del tiempo, ya que un aumento lineal indica que se est\u00e1n alcanzando umbrales cr\u00edticos. Vigilo las latencias de E\/S junto con las estad\u00edsticas de InnoDB para poder establecer claramente la relaci\u00f3n de causa y efecto. Tras cada cambio de par\u00e1metro, comparo ventanas de carga id\u00e9nticas; de lo contrario, podr\u00eda sacar conclusiones err\u00f3neas. Documento las curvas, ya que una imagen dice m\u00e1s que un \u00fanico punto de medici\u00f3n y as\u00ed puedo detectar con seguridad las rupturas de tendencia.<\/p>\n\n<h2>Plan de ajuste paso a paso<\/h2>\n\n<p>Empiezo con una medici\u00f3n realista de la <strong>Tasa de escritura<\/strong> y, a partir de ah\u00ed, establezco el valor de innodb_io_capacity. A continuaci\u00f3n, defino innodb_io_capacity_max como medida de emergencia para situaciones de presi\u00f3n, dejando un margen suficiente respecto al valor base. A continuaci\u00f3n, compruebo innodb_adaptive_flushing_lwm y lo reduzco si el Checkpoint-Age se retrasa demasiado. Despu\u00e9s, configuro innodb_max_dirty_pages_pct_lwm de manera que el preflushing comience a tiempo y los picos se reduzcan r\u00e1pidamente. Por \u00faltimo, ajusto el tama\u00f1o del redo log, vuelvo a observar varios ciclos de carga y documento cada cambio antes de dar el siguiente paso.<\/p>\n\n<h2>Mecanismo \u00abFlush\u00bb bajo el cap\u00f3<\/h2>\n\n<p>Distingo entre dos motivos principales para escribir: el <strong>Limpieza de la lista de flush<\/strong> (impulsado por el avance en Checkpoint) y el <strong>Purga de la LRU<\/strong> (debido a la falta de p\u00e1ginas libres). Si el pool de b\u00faferes se llena y faltan p\u00e1ginas libres, el vaciado LRU me obliga a realizar escrituras inmediatas, lo que genera picos de latencia. El vaciado adaptativo tiene como objetivo evitar estas situaciones forzadas mediante el vaciado continuo de la lista de vaciado. Para que esto funcione, mantengo estable la proporci\u00f3n de p\u00e1ginas libres y superviso valores como la profundidad de escaneo de la LRU y la carga por instancia del pool de b\u00faferes. Cuanto m\u00e1s uniformemente se procese la lista de vaciado, menos a menudo tendr\u00e9 que esperar en primer plano a que haya p\u00e1ginas libres.<\/p>\n\n<p>Para ello, tengo en cuenta la relaci\u00f3n entre <strong>innodb_buffer_pool_instances<\/strong>, <strong>innodb_page_cleaners<\/strong> y la capacidad f\u00edsica de E\/S. Un mayor n\u00famero de instancias y subprocesos de limpieza aumentan el paralelismo, pero solo hasta el punto en que las colas de almacenamiento no se desborden. Si las operaciones de vaciado alcanzan longitudes de cola elevadas, es una se\u00f1al de que deber\u00eda haber vaciado antes y m\u00e1s lentamente; eso es precisamente lo que abordo mediante innodb_adaptive_flushing_lwm y las capacidades m\u00ednima y m\u00e1xima.<\/p>\n\n<h2>Confirmaci\u00f3n de transacciones, Redo y Binlog en su contexto<\/h2>\n\n<p>Analizo las rutas de confirmaci\u00f3n y las garant\u00edas de durabilidad en el contexto del suavizado de flushing. <strong>innodb_flush_log_at_trx_commit<\/strong> y la sincronizaci\u00f3n de Binlog influyen en la frecuencia con la que el sistema ejecuta fsyncs y en la intensidad de los picos a corto plazo. Mis pautas son:<\/p>\n\n<ul>\n  <li>1: M\u00e1xima durabilidad (se vuelve a escribir en el soporte de datos con cada commit). Es seguro, pero requiere un uso intensivo de fsync y puede resultar m\u00e1s irregular.<\/li>\n  <li>2: \u00abRedo\u00bb se vac\u00eda cada segundo, mientras que \u00abCommit\u00bb solo escribe en la cach\u00e9 del sistema operativo. Los picos son menores, pero a cambio me arriesgo a perder datos en caso de fallo del sistema operativo o del servidor.<\/li>\n  <li>0: Similar al 2, pero con un almacenamiento en cach\u00e9 a\u00fan m\u00e1s agresivo. Para sistemas de producci\u00f3n, utilizarlo solo con precauci\u00f3n.<\/li>\n<\/ul>\n\n<p>Junto con la sincronizaci\u00f3n de Binlog (<strong>sync_binlog<\/strong>) y los efectos de Group Commit, puedo agrupar las confirmaciones y reducir el n\u00famero de sincronizaciones r\u00edgidas. Es importante no abusar de estas herramientas como sustituto de un ajuste adecuado del \u00abadaptive flushing\u00bb. Siempre eval\u00fao conjuntamente el riesgo, los requisitos de cumplimiento normativo y el perfil de latencia deseado, y solo realizo ajustes en la medida en que lo permitan las reglas de negocio.<\/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_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hilos de purga, longitud del historial y hilos de larga duraci\u00f3n<\/h2>\n\n<p>He tenido la <strong>InnoDB-Purge<\/strong> A tener en cuenta: muchas l\u00edneas eliminadas o actualizadas generan datos de \u00abDeshacer\u00bb que se limpian de forma as\u00edncrona. Si la <em>Duraci\u00f3n del historial<\/em> Si es muy intensa, aumenta la carga de fondo y compite con los limpiadores de p\u00e1ginas por el acceso de E\/S. Esto puede ralentizar indirectamente el \u00abAdaptive Flushing\u00bb. Las soluciones son establecer un valor adecuado para la paralelidad de purga y evitar las transacciones de larga duraci\u00f3n que mantienen abierto el historial de forma artificial. Adem\u00e1s, planifico las operaciones por lotes de tal forma que controle el volumen de operaciones de redo y undo, en lugar de modificar millones de l\u00edneas de golpe en poco tiempo.<\/p>\n\n<h2>Fases de \u00abChange Buffer\u00bb y \u00abMerge\u00bb<\/h2>\n\n<p>Tengo en cuenta la <strong>Cambiar b\u00fafer<\/strong> durante actualizaciones intensivas de \u00edndices secundarios. Reduce las E\/S aleatorias en tiempo de ejecuci\u00f3n, pero traslada parte del trabajo a fases de fusi\u00f3n posteriores. Estas fusiones pueden generar una carga adicional de vaciado si coinciden de forma desfavorable con picos de producci\u00f3n. Por ello, superviso el tama\u00f1o y la actividad del b\u00fafer de cambios, lo limito cuando es necesario y distribuyo los cambios masivos de manera que las fases de fusi\u00f3n no coincidan con las horas punta. De este modo, la frecuencia de vaciado resulta m\u00e1s previsible y uniforme.<\/p>\n\n<h2>M\u00e9todos de vaciado y factores relacionados con el sistema de archivos<\/h2>\n\n<p>Decido conscientemente sobre la <strong>M\u00e9todo Flush<\/strong> y las opciones del sistema de archivos. O_DIRECT evita la duplicaci\u00f3n de cach\u00e9s y, con ello, a menudo suaviza las latencias de escritura, mientras que las rutas AIO y Fsync tienen sus propias caracter\u00edsticas. Mido c\u00f3mo influyen estos m\u00e9todos en la distribuci\u00f3n de la latencia y en la estabilidad del progreso de los puntos de control y, para cuestiones m\u00e1s detalladas, remito a las indicaciones sobre <a href=\"https:\/\/webhosting.de\/es\/mariadb-metodos-de-vaciado-innodb-fsync-guia-de-rendimiento-bufer\/\">M\u00e9todos de purga<\/a>. Adem\u00e1s, compruebo las opciones de montaje del sistema de archivos y las rutinas de mantenimiento (por ejemplo, estrategias coherentes de TRIM\/Discard en los SSD), para que la infraestructura subyacente no introduzca fluctuaciones sin que nos demos cuenta.<\/p>\n\n<h2>Diagn\u00f3stico: interpretar correctamente los mensajes de estado<\/h2>\n\n<p>Me voy <em>Mostrar el estado del motor InnoDB<\/em> para evaluar la antig\u00fcedad de los puntos de control y el progreso del vaciado. De <em>N\u00famero de secuencia de registro<\/em>, <em>Registro vaciado hasta<\/em> y <em>\u00daltimo punto de control en<\/em> Determino cu\u00e1l es la diferencia entre los cambios generados y los persistidos. Si esa diferencia crece de forma continua a un ritmo superior al que permite el tama\u00f1o del registro de redo, significa que mi vaciado en segundo plano es demasiado lento o que la latencia de E\/S es demasiado alta. Comparo estos valores con las m\u00e9tricas de InnoDB sobre p\u00e1ginas sucias, tasa de vaciado y actividad del limpiador de p\u00e1ginas, para poder ajustar los par\u00e1metros adecuados de forma espec\u00edfica, en lugar de limitarme a tratar los s\u00edntomas.<\/p>\n\n<h2>Escenarios operativos: Bulk, DDL y ventanas de mantenimiento<\/h2>\n\n<p>Estoy planeando <strong>Cargas a granel<\/strong> y exhaustivas <strong>DDL<\/strong>-Operaciones de tal manera que no se anule el \u00abAdaptive Flushing\u00bb. Para las ventanas de mantenimiento programables, aumento temporalmente <strong>innodb_io_capacity_max<\/strong>, para procesar de forma controlada las escrituras pendientes, y despu\u00e9s lo vuelvo a bajar al nivel normal. En importaciones de gran volumen, modero la frecuencia de las confirmaciones para que el crecimiento del redo log y el avance de los puntos de control vayan al mismo ritmo. Mientras tanto, superviso continuamente el nivel de llenado del registro de redo, la proporci\u00f3n de p\u00e1ginas sucias y los percentiles de latencia, para poder tomar medidas correctivas de inmediato en caso de desviaciones.<\/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-optimizierung-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ideas err\u00f3neas frecuentes y antipatrones<\/h2>\n\n<p>No voy a caer en la trampa, <strong>innodb_io_capacity_max<\/strong> utilizarlo como estado permanente. Un valor m\u00e1ximo demasiado alto puede saturar las colas de memoria y ralentizar los accesos de lectura en tiempo real. Tampoco \u201eescondo\u201c la memoria d\u00e9bil tras un registro de rehacer (redo log) enorme: los registros m\u00e1s grandes suavizan las fluctuaciones, pero no crean reservas de E\/S. Y no doy por sentados los picos de latencia: a menudo son el resultado de un preflushing demasiado tard\u00edo o de una carga en segundo plano muy fluctuante, que puedo mitigar mediante umbrales de LWM m\u00e1s bajos y valores de capacidad realistas. Por \u00faltimo, evito modificar varios par\u00e1metros al mismo tiempo; de lo contrario, pierdo la causalidad y no puedo hacer que las mejoras sean reproducibles.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Utilizo <strong>Adaptativo<\/strong> El flushing sirve para distribuir las operaciones de escritura de forma uniforme a lo largo del tiempo y, de este modo, evitar picos de latencia. La clave principal reside en una configuraci\u00f3n precisa de innodb_io_capacity y una relaci\u00f3n adecuada con innodb_io_capacity_max. Los umbrales de activaci\u00f3n temprana para el nivel de llenado del redo log y la proporci\u00f3n de p\u00e1ginas sucias me ayudan a mantener las colas de espera reducidas. Con los redo logs adecuados, un paralelismo razonable de los hilos del limpiador de p\u00e1ginas y una supervisi\u00f3n atenta, consigo rutinas de escritura m\u00e1s fiables. Seg\u00fan la documentaci\u00f3n de MariaDB sobre variables de sistema y vaciado de p\u00e1ginas, estos par\u00e1metros act\u00faan de forma conjunta; los ajusto paso a paso y vigilo el efecto hasta que el sistema funciona de forma estable y predecible.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optimizar el \u00abAdaptive Flushing\u00bb de MariaDB mediante el ajuste de InnoDB, la capacidad de E\/S y consejos pr\u00e1cticos para un rendimiento estable.<\/p>","protected":false},"author":1,"featured_media":21582,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21589","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":"83","_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":"Adaptive Flushing","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":"21582","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21589","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=21589"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21589\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21582"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}