{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"indice-de-datos-sucios-de-linux-indice-de-fondo-sujo-optimizacion-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"\u00abDirty Ratio\u00bb y \u00abDirty Background Ratio\u00bb en Linux: ajuste preciso para un rendimiento \u00f3ptimo de escritura"},"content":{"rendered":"<p>Muestro c\u00f3mo <strong>linux sucio<\/strong> y el \u00abdirty background ratio\u00bb para controlar la cach\u00e9 de p\u00e1gina y, con ello, influir en el rendimiento de escritura, la latencia y la seguridad de los datos. De este modo, puedes establecer valores l\u00edmite concretos que activen los flusher a tiempo, eviten los bloqueos y aumenten el rendimiento de escritura de tus cargas de trabajo.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Para empezar, resumir\u00e9 brevemente las ideas principales antes de profundizar en el tema.<\/p>\n<ul>\n  <li><strong>P\u00e1ginas subidas de tono<\/strong> Almacena temporalmente los datos de Writes en la RAM y agrupa muchos peque\u00f1os accesos para obtener operaciones de E\/S m\u00e1s eficientes.<\/li>\n  <li><strong>dirty_background_ratio<\/strong> Inicia subprocesos de limpieza en segundo plano, lo que limita as\u00ed la cantidad de residuos sin que se note.<\/li>\n  <li><strong>cociente_sucio<\/strong> frena los procesos de escritura cuando se supera el l\u00edmite estricto.<\/li>\n  <li><strong>Relaci\u00f3n<\/strong> Ambos valores determinan los picos de latencia, el rendimiento y el tama\u00f1o del b\u00fafer.<\/li>\n  <li><strong>Variantes de bytes<\/strong> (dirty_bytes) permiten un control m\u00e1s preciso y absoluto en servidores de gran tama\u00f1o.<\/li>\n<\/ul>\n\n<h2>Entender las \u00abp\u00e1ginas obscenas\u00bb<\/h2>\n\n<p>Cuando un proceso escribe datos, estos van a parar primero al <strong>Cach\u00e9 de p\u00e1gina<\/strong> y se marcan como \u201edirty\u201c hasta que el n\u00facleo pueda volcarlas al disco. Este almacenamiento en b\u00fafer acelera las aplicaciones, ya que la RAM responde m\u00e1s r\u00e1pido que cualquier SSD o HDD, y las peque\u00f1as operaciones de escritura se agrupan para formar grandes transferencias secuenciales. Siempre tengo presente cu\u00e1nta \u201esuciedad\u201c permito, ya que un exceso de almacenamiento en b\u00fafer puede alargar las colas de espera o suponer un mayor riesgo de que se pierdan datos en caso de fallos del sistema. Quien comprenda c\u00f3mo funciona esto, tomar\u00e1 mejores decisiones en cuanto a la reescritura, la latencia y la presi\u00f3n de almacenamiento. Un breve art\u00edculo de fondo sobre el <a href=\"https:\/\/webhosting.de\/es\/cache-de-reescritura-cache-del-nucleo-de-linux\/\">Cach\u00e9 de reescritura<\/a> ayuda a clasificar esta mec\u00e1nica de forma clara.<\/p>\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\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguridad de los datos, fsync y ventana de fallo<\/h2>\n<p>Los valores l\u00edmite no solo influyen en el rendimiento, sino tambi\u00e9n en tu margen de riesgo. Lo calculo a grandes rasgos con una sencilla regla emp\u00edrica: la cantidad m\u00e1xima de datos no validados dividida por el rendimiento sostenido del dispositivo da, aproximadamente, el tiempo que tarda el b\u00fafer en vaciarse. Ejemplo: si permito 4 GB de datos \u00absucios\u00bb y el medio de destino alcanza los 500 MB\/s, la reescritura completa tardar\u00e1 unos 8 segundos. Durante ese tiempo, en caso de corte de corriente o de fallo del kernel, podr\u00edan perderse las \u00faltimas escrituras.<\/p>\n<p>Las aplicaciones pueden cerrar la ventana mediante <code>fsync()<\/code> o <code>fdatasync()<\/code> reducir, ya que estas llamadas obligan al sistema de archivos a escribir datos (y, seg\u00fan el modo de registro, tambi\u00e9n metadatos) en el soporte. Esto es m\u00e1s costoso, pero esencial para bases de datos o registros. Me aseguro de que mis l\u00edmites de datos sucios se ajusten al comportamiento de sincronizaci\u00f3n: frecuentes <code>fsync()<\/code>-Las visitas se benefician de un menor <em>cociente_sucio<\/em>, para que el n\u00facleo no aplique una limitaci\u00f3n adicional cuando, de todos modos, la persistencia se realiza con regularidad. Por el contrario, en el caso de los registros en los que predominan las operaciones de \u00abappend\u00bb y que rara vez se vac\u00edan, puedo permitir b\u00faferes m\u00e1s grandes, siempre teniendo en cuenta el riesgo de p\u00e9rdida aceptado.<\/p>\n<p>Tambi\u00e9n son importantes las barreras y el orden de escritura: los sistemas de archivos modernos utilizan comandos FUA\/Flush para vaciar correctamente las cach\u00e9s de los controladores. En soportes sin protecci\u00f3n contra p\u00e9rdidas de alimentaci\u00f3n (PLP), los b\u00faferes de gran tama\u00f1o aumentan el riesgo; con PLP o protecci\u00f3n de la cach\u00e9 de escritura, a menudo es aceptable utilizar b\u00faferes m\u00e1s grandes.<\/p>\n\n<h2>Proporci\u00f3n de fondo sucio: el umbral suave<\/h2>\n\n<p>Con <strong>dirty_background_ratio<\/strong> Indico a partir de qu\u00e9 porcentaje de la memoria disponible los hilos de vaciado comienzan a escribir en segundo plano. Este valor no bloquea ninguna aplicaci\u00f3n, sino que inicia de forma silenciosa las tareas de limpieza para que el b\u00fafer no se desborde. Los valores bajos generan una escritura en segundo plano m\u00e1s frecuente, pero m\u00e1s uniforme, y suavizan los picos de latencia. Los valores m\u00e1s altos permiten un mayor tama\u00f1o del b\u00fafer, lo que aumenta el rendimiento en el caso de grandes escrituras secuenciales, aunque puede provocar picos de E\/S considerables en caso de un vaciado repentino. Normalmente, los valores por defecto rondan el diez por ciento, pero yo ajusto este l\u00edmite en funci\u00f3n del soporte, la carga de trabajo y los requisitos de seguridad.<\/p>\n\n<h2>Dirty Ratio: la frenada brusca<\/h2>\n\n<p>El par\u00e1metro <strong>cociente_sucio<\/strong> marca el l\u00edmite a partir del cual el n\u00facleo limita los procesos de escritura hasta que se hayan reescrito suficientes p\u00e1ginas. Este l\u00edmite estricto protege la memoria frente a una avalancha de datos no persistentes y, por lo tanto, afecta directamente a las aplicaciones en cuanto estas intentan seguir generando datos. En el caso de las bases de datos, suelo establecer un valor bastante bajo para que las consultas mantengan tiempos de respuesta constantes y no se produzcan fases de vaciado prolongadas. En cambio, para las tareas de copia de seguridad utilizo b\u00faferes m\u00e1s generosos, con el fin de transferir bloques grandes de forma eficiente. Los valores predeterminados habituales oscilan entre el veinte y el cuarenta por ciento, pero yo siempre adapto este rango a la carga concreta.<\/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\/08\/linux_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interacci\u00f3n y relaciones t\u00edpicas<\/h2>\n\n<p>Ambos valores l\u00edmite funcionan como <strong>T\u00e1ndem<\/strong> y solo surten efecto cuando se combinan. Siempre mantengo el valor de `dirty_background_ratio` por debajo del de `dirty_ratio`, para que el n\u00facleo se inicie a tiempo en segundo plano y el freno duro se active en contadas ocasiones. Como regla general, suelo elegir entre una cuarta parte y la mitad del l\u00edmite m\u00e1ximo; por ejemplo, 5-10 frente a 20. De este modo, el \u00abwriteback\u00bb se inicia con la suficiente antelaci\u00f3n sin reducir innecesariamente el rendimiento. Quien no respete esta relaci\u00f3n se encontrar\u00e1, o bien con una limitaci\u00f3n demasiado prematura, o bien con un trabajo en segundo plano demasiado tard\u00edo, con picos de latencia perceptibles.<\/p>\n\n<h2>Control por dispositivo y detalles de la capa de bloques<\/h2>\n<p>Adem\u00e1s de los l\u00edmites globales, merece la pena fijarse en el nivel de los dispositivos. Linux distribuye la carga sucia a trav\u00e9s de los denominados <em>Dispositivos compatibles<\/em> (bdi). En <code>\/sys\/class\/block\/\/bdi\/<\/code> Me parecen par\u00e1metros como <code>max_ratio<\/code>, que determinan qu\u00e9 parte del \u00abDirty-Budget\u00bb global permitido puede consumir cada dispositivo. En sistemas que cuentan con unidades de disco lentas y r\u00e1pidas en paralelo, limito las unidades lentas para que no se conviertan en un cuello de botella.<\/p>\n<p>Tambi\u00e9n es relevante la limitaci\u00f3n de la capa de bloques a trav\u00e9s de <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Con ello establezco una latencia objetivo; el kernel limita la carga de escritura cuando se supera ese tiempo objetivo. En el caso de los discos duros SATA, suelo establecer valores conservadores para proteger la interactividad. En unidades NVMe muy r\u00e1pidas, desactivo o aumento la latencia objetivo para que el controlador pueda aprovechar al m\u00e1ximo su paralelismo. Elijo el programador de E\/S (mq-deadline, BFQ, none) seg\u00fan convenga: BFQ resulta \u00fatil en sistemas interactivos con carga mixta, mientras que <em>ninguno<\/em> o que mq-deadline suele funcionar mejor en trabajos de puro rendimiento con NVMe.<\/p>\n<p>La interacci\u00f3n es fundamental: si <em>dirty_background_ratio<\/em> Aunque el valor sea bajo, si el dispositivo se limita de forma agresiva mediante WBT, siguen produci\u00e9ndose atascos visibles. Por eso calibro ambos niveles a la vez: l\u00edmites globales de \u00abdirty\u00bb para el tama\u00f1o del b\u00fafer y la capa de bloques para la protecci\u00f3n contra la latencia.<\/p>\n\n<h2>Ratio frente a bytes: valores por defecto y variantes<\/h2>\n\n<p>En sistemas con mucho <strong>RAM<\/strong> Los porcentajes se convierten r\u00e1pidamente en grandes magnitudes absolutas. En ese caso, prefiero establecer l\u00edmites m\u00e1ximos absolutos con dirty_bytes y dirty_background_bytes para limitar claramente el tama\u00f1o del b\u00fafer a unos 2-8 GB. Esto desacopla el control de los niveles de memoria, que fluct\u00faan mucho, y mantiene predecible la cantidad de datos no persistentes. La elecci\u00f3n sigue siendo din\u00e1mica: para servidores peque\u00f1os con poca RAM, los porcentajes suelen ser m\u00e1s que suficientes. Quien disponga de una gran capacidad, a menudo tendr\u00e1 m\u00e1s facilidad para planificar utilizando valores en bytes.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metros<\/th>\n      <th>Significado<\/th>\n      <th>Valores predeterminados t\u00edpicos<\/th>\n      <th>\u00bfCu\u00e1ndo hay que cambiarlo?<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Inicio del <strong>Limpieza de fondo<\/strong> en porcentaje<\/td>\n      <td>\u2248 10%<\/td>\n      <td>En caso de fluctuaciones en la latencia o de SSD\/NVMe muy r\u00e1pidos<\/td>\n      <td>M\u00e1s bajo = latencia m\u00e1s estable; m\u00e1s alto = mayor capacidad de b\u00fafer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Duro <strong>L\u00edmite de estrangulamiento<\/strong> en porcentaje<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>En las bases de datos es menor, en las copias de seguridad es mayor<\/td>\n      <td>Demasiado alto \u2192 Posibles bloqueos al realizar un flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Inicio del \u00abflush\u00bb en segundo plano en <strong>Bytes<\/strong><\/td>\n      <td>Desactivado si se utiliza Ratio<\/td>\n      <td>Gran cantidad de RAM, objetivos de b\u00fafer fijos<\/td>\n      <td>Anula los par\u00e1metros de Ratio<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.bytes sucios<\/td>\n      <td>L\u00edmite estricto de modulaci\u00f3n en <strong>Bytes<\/strong><\/td>\n      <td>Desactivado si se utiliza Ratio<\/td>\n      <td>Gran capacidad de RAM, l\u00edmite m\u00e1ximo programable<\/td>\n      <td>Anula los par\u00e1metros de Ratio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Escenarios de carga de trabajo y recomendaciones<\/h2>\n\n<p>Cargas de escritura secuenciales como <strong>Copias de seguridad<\/strong> Se benefician de grandes b\u00faferes y de una escritura en segundo plano moderada, ya que el n\u00facleo puede escribir en el soporte a grandes rasgos. En este caso, suelo fijar dirty_ratio entre el 30 y el 40 por ciento, y dirty_background_ratio entre el 10 y el 20 por ciento. Las bases de datos y las peque\u00f1as aplicaciones de E\/S aleatoria se benefician de una latencia predecible, por lo que elijo un 10-15 % en modo \u00abduro\u00bb y un 3-5 % en modo \u00absuave\u00bb. Para servidores mixtos de web y aplicaciones, un 15-20 % de \u00abhard\u00bb y un 5-10 % de \u00absoft\u00bb resultan ser un buen t\u00e9rmino medio. Estos rangos sirven como punto de partida; a partir de ah\u00ed, lo que cuenta es la realidad medida de tu sistema.<\/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\/08\/linux-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos del sistema de archivos y opciones de montaje<\/h2>\n<p>La ruta de reescritura termina en el sistema de archivos, cuya estrategia determina las latencias y la seguridad. Ext4 con <em>datos=ordenados<\/em> (Por defecto) escribe los datos de usuario antes de las confirmaciones del diario; <em>data=respuesta<\/em> reduce la latencia, pero pone en riesgo los datos antiguos en caso de fallos del sistema. El par\u00e1metro <code>comprometer=<\/code> (segundos) determina la frecuencia con la que se guarda el registro. Los intervalos m\u00e1s cortos reducen la p\u00e9rdida de datos, pero consumen m\u00e1s E\/S. XFS utiliza un dise\u00f1o de registro muy maduro; los archivos grandes <em>logbsize<\/em> y una alineaci\u00f3n adecuada facilitan las tareas de alto rendimiento. Btrfs agrupa las escrituras mediante \u00abcopy-on-write\u00bb, lo que estabiliza las latencias, pero puede provocar fragmentaci\u00f3n en el caso de peque\u00f1as escrituras aleatorias y SSD con poca capacidad. Opciones como <em>nodatacow<\/em> pueden ayudar a desfragmentar determinadas rutas o de forma selectiva cuando se producen picos de latencia.<\/p>\n<p>Adem\u00e1s, tengo en cuenta que <em>relatime<\/em>\/<em>noatime<\/em> (reduce las operaciones de escritura de metadatos), <em>lazytime<\/em> (retrasa los valores de mtime\/atime de forma m\u00e1s persistente) y las barreras de registro. Precisamente en los controladores RAID o en las m\u00e1quinas virtuales, es fundamental que la sem\u00e1ntica de la cach\u00e9 sea correcta: unas cach\u00e9s de escritura mal configuradas echan por tierra todo el trabajo de \u00abdirty tuning\u00bb.<\/p>\n\n<h2>E\/S directa, O_SYNC y comportamiento de la aplicaci\u00f3n<\/h2>\n<p>No todas las aplicaciones pasan por la cach\u00e9 de p\u00e1ginas. Con <code>O_DIRECTO<\/code> o <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Algunos procesos eluden partes de la cach\u00e9 o requieren una persistencia inmediata. Las bases de datos suelen escribir un WAL\/registro de rehacer de forma sincr\u00f3nica y las \u00e1reas de datos de forma asincr\u00f3nica. Calibro los l\u00edmites de datos modificados especialmente para las rutas asincr\u00f3nicas, mientras que garantizo la latencia de las rutas sincr\u00f3nicas mediante registros r\u00e1pidos (NVMe, LUN dedicado). Cuando las aplicaciones realizan con mucha frecuencia <code>fsync()<\/code> a la hora de acceder a ellos, los b\u00faferes grandes no resultan muy \u00fatiles: en ese caso, la latencia depende m\u00e1s del controlador, la profundidad de la cola y el programador de E\/S que de <em>cociente_sucio<\/em>.<\/p>\n\n<h2>Ajustes pr\u00e1cticos paso a paso<\/h2>\n\n<p>Antes de cada modificaci\u00f3n, compruebo la <strong>valores reales<\/strong> con <code>sysctl vm.dirty_ratio<\/code> y <code>sysctl vm.dirty_background_ratio<\/code>, para documentar la situaci\u00f3n inicial. Para las pruebas a corto plazo, anoto los valores directamente en <code>\/proc\/sys\/vm\/<\/code>por ejemplo <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> y <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Si el ajuste es permanente, lo guardo en <code>\/etc\/sysctl.conf<\/code> o <code>\/etc\/sysctl.d\/*.conf<\/code>. Aplico los cambios con <code>sysctl -p<\/code> de inmediato, para poder medir el efecto lo antes posible. Quien se adentre m\u00e1s en el tema de las reglas del sistema se beneficiar\u00e1 de consejos pr\u00e1cticos sobre el <a href=\"https:\/\/webhosting.de\/es\/ajuste-de-sysctl-para-optimizar-el-rendimiento-de-un-servidor-de-alojamiento-web\/\">Ajuste de sysctl<\/a> en servidores de producci\u00f3n.<\/p>\n\n<h2>C\u00f3mo calcular valores: ejemplos de c\u00e1lculo<\/h2>\n<p>Me gusta empezar con valores concretos. Ejemplo 1: servidor web\/de aplicaciones con 64 GB de RAM y NVMe. El objetivo es una latencia baja. Yo utilizo <code>dirty_background_bytes=1073741824<\/code> (1 GB) y <code>dirty_bytes=3221225472<\/code> (3 GB). Con un rendimiento NVMe sostenido de 2 GB\/s, esto supone entre 0,5 y 1,5 segundos para vaciarlo, lo cual es adecuado para cargas interactivas. Ejemplo 2: nodo de copia de seguridad con 128 GB de RAM y un RAID SATA r\u00e1pido con 800 MB\/s. Elijo <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. En t\u00e9rminos absolutos, son unos 12,8 GB y 44,8 GB; el RAID tarda entre 16 y 56 segundos en vaciarse. No pasa nada, porque la tarea no es interactiva.<\/p>\n<p>Ejemplo 3: Servidor de base de datos con 256 GB de RAM, diario independiente en NVMe y datos en una matriz de SSD. Establezco un l\u00edmite absoluto para evitar valores at\u00edpicos: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Esto permite prever el tama\u00f1o de la ventana de colisi\u00f3n y reduce las frenadas bruscas durante los puntos de control.<\/p>\n\n<h2>Tiempo de reescritura y par\u00e1metros relacionados<\/h2>\n\n<p>Adem\u00e1s de los valores l\u00edmite, influyen <strong>Temporizador<\/strong> el comportamiento de reescritura y, por lo tanto, la sensaci\u00f3n que transmiten las aplicaciones. Con <code>vm.dirty_writeback_centisegundos<\/code> controlo el intervalo en el que el \u00abkernel flusher\u00bb se activa, mientras que <code>vm.dirty_expire_centisecs<\/code> define la antig\u00fcedad m\u00e1xima que pueden alcanzar las p\u00e1ginas sucias. Los intervalos m\u00e1s cortos garantizan vaciados m\u00e1s frecuentes, aunque de menor tama\u00f1o; los intervalos m\u00e1s largos ahorran llamadas de E\/S, pero conllevan el riesgo de que los lotes sean m\u00e1s grandes. Solo ajusto estos valores cuando las mediciones revelan desventajas reales, como vaciados demasiado espaciados en unidades NVMe r\u00e1pidas. Quien act\u00fae de forma met\u00f3dica en este sentido evitar\u00e1 oscilaciones entre una actividad de reescritura demasiado intensa y otra demasiado lenta.<\/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\/08\/linux_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguimiento y ajuste preciso<\/h2>\n\n<p>Tras realizar algunos ajustes, observo que <strong>continuo<\/strong> los indicadores clave para poner de manifiesto los logros y los efectos secundarios. En <code>\/proc\/meminfo<\/code> Compruebo \u201eDirty\u201c y \u201eWriteback\u201c para ver los niveles de la memoria intermedia y los flushing activos. Herramientas como iostat, sar o atop me muestran el rendimiento, las colas y las tendencias de latencia. Este art\u00edculo ofrece una buena introducci\u00f3n a las m\u00e9tricas sobre el <a href=\"https:\/\/webhosting.de\/es\/servidor-io-wait-analizar-iostat-vmstat-metricas-disco\/\">Analizar la espera de E\/S<\/a>. Solo a partir de estos datos reduzco o aumento los l\u00edmites poco a poco, para evitar que se produzcan efectos secundarios inesperados.<\/p>\n\n<h2>Contenedores, cgroups y distribuci\u00f3n equitativa<\/h2>\n<p>En entornos de contenedores, las cargas de trabajo comparten los mismos mecanismos del n\u00facleo. El \u00abwriteback\u00bb de cgroups garantiza que las p\u00e1ginas sucias se asignen a quien las ha generado. Utilizo los controladores de E\/S de los cgroups (blkcg) para limitar el ancho de banda o las IOPS por contenedor cuando algunos inquilinos almacenan en b\u00fafer de forma demasiado agresiva. L\u00edmites absolutos de bytes a nivel de host (<em>bytes_sucios<\/em>) para evitar que un solo invitado se lleve todo el presupuesto de \u00abDirty\u00bb. Adem\u00e1s, limito el espacio de almacenamiento mediante <code>memoria.max<\/code>, para que Writeback no reaccione solo ante una presi\u00f3n global. El objetivo sigue siendo el mismo: ninguna carga del invitado debe provocar restricciones a nivel del host en el <em>cociente_sucio<\/em> imponer.<\/p>\n\n<h2>Entornos de alojamiento y m\u00e1quinas virtuales<\/h2>\n\n<p>En entornos multicliente y m\u00e1quinas virtuales, presto atenci\u00f3n a <strong>Overbooking<\/strong> de la RAM y la E\/S, ya que los l\u00edmites porcentuales tienen all\u00ed un efecto diferente. Los l\u00edmites absolutos en bytes pueden evitar que determinados invitados acumulen demasiado b\u00fafer y ralenticen a los vecinos. Tengo en cuenta la deduplicaci\u00f3n de memoria, el \u00abballooning\u00bb y las cach\u00e9s de los controladores, ya que se superponen a los efectos del almacenamiento en b\u00fafer. En el caso de los servidores gestionados, resulta beneficioso que el proveedor establezca valores predeterminados adecuados para que los clientes disfruten de tiempos de respuesta constantes. Quien gestione sus propios nodos se beneficia de una configuraci\u00f3n de perfiles bien definida para cada clase de carga de trabajo.<\/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\/08\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Malentendidos y obst\u00e1culos habituales<\/h2>\n<ul>\n  <li><strong>\u201eM\u00e1s capacidad de reserva = cada vez m\u00e1s rendimiento\u201c.\u201c<\/strong> Esto no es adecuado para cargas de trabajo con un alto porcentaje de operaciones aleatorias o para dispositivos con poca profundidad de cola. Unos b\u00faferes demasiado grandes provocan picos de vaciado y colas.<\/li>\n  <li><strong>\u201edirty_ratio no afecta a las lecturas\u201c.\u201c<\/strong> Indirectamente, s\u00ed: las fases agresivas de reescritura desplazan las p\u00e1ginas de la cach\u00e9 y aumentan las latencias de lectura.<\/li>\n  <li><strong>\u201eLos bytes y la raz\u00f3n se suman\u201c.\u201c<\/strong> No. Si utilizas variantes de \u00abbytes\u00bb, anulan a sus equivalentes de \u00abratio\u00bb. Quedan bien claras.<\/li>\n  <li><strong>\u201efsync() hace que los l\u00edmites de datos sucios dejen de tener importancia\u201c.\u201c<\/strong> No. Aunque las sincronizaciones frecuentes reducen la ventana de riesgo, el resto de la carga sigue estando sujeta a los valores l\u00edmite.<\/li>\n  <li><strong>\u201eUn soporte de datos r\u00e1pido lo resuelve todo\u201c.\u201c<\/strong> No, si la capa de bloques reduce el rendimiento (WBT) o si el sistema de archivos est\u00e1 montado de forma sub\u00f3ptima.<\/li>\n  <li><strong>\u201eDrop_caches es una herramienta de optimizaci\u00f3n\u201c.\u201c<\/strong> Vaciar la cach\u00e9 distorsiona las mediciones y agrava los picos de latencia. En el entorno de producci\u00f3n, lo evito.<\/li>\n<\/ul>\n\n<h2>Soluci\u00f3n de problemas: s\u00edntomas t\u00edpicos y soluciones<\/h2>\n\n<p>Amontonar <strong>Picos de latencia<\/strong>, lo primero que hago es reducir el umbral de fondo para que los flusher se activen antes y se produzcan con menos frecuencia grandes oleadas de escritura. Si las aplicaciones se bloquean de forma intermitente, suele ser porque el l\u00edmite m\u00e1ximo es demasiado alto o porque el soporte no puede gestionar las r\u00e1fagas de flushing que se generan. En tales casos, reduzco el valor de dirty_ratio, compruebo la configuraci\u00f3n de lectura anticipada (readahead) y reviso las opciones de registro en diario del sistema de archivos. Con hardware NVMe muy r\u00e1pido, aumento gradualmente el umbral de fondo para no limitar artificialmente el rendimiento. Tras cada cambio, me gu\u00edo por los datos de medici\u00f3n, no por corazonadas.<\/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\/08\/linux-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumen breve para la pr\u00e1ctica<\/h2>\n\n<p>Con pocos <strong>Tornillos de ajuste<\/strong> Puedo influir en c\u00f3mo Linux almacena en b\u00fafer los datos de escritura, cu\u00e1ndo se inician los flusher y cu\u00e1ndo el kernel frena el sistema. El \u00abDirty Background Ratio\u00bb garantiza una limpieza silenciosa, mientras que el \u00abDirty Ratio\u00bb limita el consumo de RAM de forma m\u00e1s estricta. La relaci\u00f3n entre ambos valores determina si tu sistema se orienta m\u00e1s hacia latencias uniformes o hacia un rendimiento m\u00e1ximo. Documento los valores predeterminados, realizo cambios poco a poco y eval\u00fao las mediciones de forma sistem\u00e1tica. De este modo se crea una configuraci\u00f3n que equilibra de forma razonable la carga de trabajo, el medio y el riesgo, y que en la pr\u00e1ctica resulta notablemente m\u00e1s r\u00e1pida.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo optimizar de forma espec\u00edfica el rendimiento de escritura y el rendimiento del n\u00facleo de tu servidor mediante los par\u00e1metros \u00abdirty ratio\u00bb y \u00abdirty background ratio\u00bb de Linux, y c\u00f3mo gestionar de forma eficiente las p\u00e1ginas sucias.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"140","_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":"linux dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}