{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"cache-de-reescritura-cache-del-nucleo-de-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Entender la cach\u00e9 de reescritura y las p\u00e1ginas sucias en el n\u00facleo de Linux"},"content":{"rendered":"<p>La cach\u00e9 de reescritura del n\u00facleo de Linux controla cu\u00e1ndo los datos modificados se guardan como <strong>P\u00e1ginas sucias<\/strong> permanecen en la RAM y cu\u00e1ndo el n\u00facleo los escribe agrupados en el soporte de almacenamiento. Voy a explicar c\u00f3mo funciona este proceso <strong>Actuaci\u00f3n<\/strong>, c\u00f3mo influyen en las latencias y la seguridad de los datos, y qu\u00e9 controles son realmente importantes en el d\u00eda a d\u00eda.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>P\u00e1ginas sucias<\/strong> marcan las p\u00e1ginas modificadas en la memoria RAM que a\u00fan no se han guardado en el soporte de datos.<\/li>\n  <li><strong>Writeback<\/strong> agrupa los cambios y los graba de forma eficiente en bloques m\u00e1s grandes.<\/li>\n  <li><strong>Valores umbral<\/strong> Al igual que vm.dirty_ratio, controlan la velocidad y la limitaci\u00f3n.<\/li>\n  <li><strong>Sincronizaci\u00f3n<\/strong> El uso de fsync\/Flush evita la p\u00e9rdida de datos.<\/li>\n  <li><strong>Monitoreo<\/strong> A trav\u00e9s de \/proc y las herramientas se muestra la carga y los retrasos.<\/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\/08\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>C\u00f3mo funciona la cach\u00e9 de p\u00e1ginas<\/h2>\n\n<p>Leo un archivo, el n\u00facleo almacena los datos en la cach\u00e9 de p\u00e1ginas y los accesos posteriores se realizan desde la <strong>Memoria<\/strong> en lugar de desde el disco. Al escribir, el sistema marca las p\u00e1ginas modificadas como <strong>Sucio<\/strong> y suele confirmar la solicitud de inmediato para que la aplicaci\u00f3n siga funcionando. Esta desconexi\u00f3n reduce los tiempos de espera, ya que los accesos de E\/S lentos no ralentizan directamente a todas las aplicaciones. Adem\u00e1s, la cach\u00e9 mantiene disponibles los bloques de uso frecuente y aumenta la tasa de aciertos en los accesos posteriores. Quien quiera profundizar m\u00e1s, encontrar\u00e1 informaci\u00f3n adicional en mi resumen sobre <a href=\"https:\/\/webhosting.de\/es\/sistema-de-archivos-almacenamiento-en-cache-linux-cache-de-pagina-cacheboost\/\">Almacenamiento en cach\u00e9 del sistema de archivos<\/a>, que muestra el papel que desempe\u00f1an las rutas de lectura y escritura en la vida cotidiana.<\/p>\n\n<h2>\u00abDirty Pages\u00bb: significado y repercusiones<\/h2>\n\n<p>Las \u00abp\u00e1ginas sucias\u00bb son p\u00e1ginas de memoria modificadas que a\u00fan no se han guardado de forma permanente y, por lo tanto, solo est\u00e1n disponibles en el <strong>RAM<\/strong> existen. Mientras est\u00e9n sucias, me pongo un poco de <strong>Riesgo<\/strong>: Un corte de corriente podr\u00eda anular estos cambios. Aun as\u00ed, de esta forma se consigue una mayor velocidad de escritura, ya que el n\u00facleo agrupa muchas peque\u00f1as actualizaciones. Si aumenta la proporci\u00f3n de p\u00e1ginas sucias, crece la presi\u00f3n sobre los m\u00f3dulos de reescritura. En ese caso, el sistema puede liberar memoria escribiendo las p\u00e1ginas en cuesti\u00f3n en la unidad de forma prioritaria.<\/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_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Reversi\u00f3n: factores desencadenantes y proceso<\/h2>\n\n<p>La reversi\u00f3n se inicia de forma programada, en respuesta a un evento y bajo demanda <strong>Aplicaciones<\/strong>. El n\u00facleo agrupa las p\u00e1ginas sucias, crea secuencias de E\/S adecuadas y las env\u00eda a trav\u00e9s de la capa de bloques al <strong>Dispositivo de almacenamiento<\/strong>. En este proceso, intervienen los sistemas de archivos, los recuperadores y los programadores de E\/S para controlar el orden y el tama\u00f1o. Las llamadas de sincronizaci\u00f3n, como fsync, garantizan que determinados datos se guarden de forma segura en el soporte antes de continuar. En fases de alta actividad, observo en las estad\u00edsticas un aumento de la proporci\u00f3n de \u00abwriteback\u00bb, que vuelve a descender tras el \u00abflush\u00bb.<\/p>\n\n<h2>Mecanismos internos: balance_dirty_pages, BDI y Writeback-Worker<\/h2>\n\n<p>En el fondo, hay varios componentes que se complementan entre s\u00ed. Los hilos de escritura pasan por <strong>balance_dirty_pages()<\/strong>, que tiene en cuenta la carga actual de datos sucios, la velocidad del dispositivo y los l\u00edmites establecidos. Regula la velocidad de escritura de los procesos (throttling) para que la reescritura en segundo plano pueda seguir el ritmo. Cada <strong>Dispositivo de respaldo<\/strong>-Contexto (bdi) \u2014normalmente un dispositivo de bloques o un backend de sistema de archivos\u2014 dispone de sus propias colas de trabajo con <strong>Hilos de Flusher<\/strong>, que convierten las \u00abDirty Pages\u00bb en solicitudes de E\/S ordenadas. Esta distribuci\u00f3n evita que un dispositivo lento ralentice al resto y mejora la equidad entre las cargas de trabajo.<\/p>\n\n<p>La limitaci\u00f3n es adaptativa: cuando detecto operaciones de escritura m\u00e1s r\u00e1pidas o bloques contiguos de mayor tama\u00f1o, las cantidades de datos \u00absucios\u00bb permitidas aumentan a corto plazo. En caso de atascos, latencias elevadas o colas saturadas, el n\u00facleo aplica el freno de forma m\u00e1s agresiva y obliga a los escritores a hacer pausas hasta que el b\u00fafer vuelva a tener margen. Es precisamente esta interacci\u00f3n la que explica por qu\u00e9 peque\u00f1os cambios en los par\u00e1metros pueden dar lugar a perfiles de latencia notablemente diferentes.<\/p>\n\n<h2>Valores umbral: vm.dirty_background_ratio y vm.dirty_ratio<\/h2>\n\n<p>Controlo el comportamiento mediante dos l\u00edmites importantes que determinan la proporci\u00f3n de p\u00e1ginas contaminadas en relaci\u00f3n con el <strong>RAM<\/strong> definir. Si supero el valor de fondo, el n\u00facleo comienza en el <strong>Antecedentes<\/strong> de escritura. Si alcanzo el l\u00edmite m\u00e1ximo, el sistema limita los procesos de escritura hasta que se hayan devuelto suficientes datos. De este modo, la memoria sigue siendo utilizable, incluso si algunos programas generan grandes cantidades de cambios. Quien trabaje con l\u00edmites basados en bytes, deber\u00e1 establecer los par\u00e1metros *_bytes correspondientes en lugar de los valores de ratio.<\/p>\n\n<h2>Tabla: Par\u00e1metros y indicadores relevantes del n\u00facleo<\/h2>\n\n<p>Utilizo unos pocos controles centrales para gestionar de forma espec\u00edfica la reescritura, la latencia y el rendimiento, y para hacerlos visibles; el siguiente resumen sirve de ayuda para <strong>Clasificaci\u00f3n<\/strong> y r\u00e1pido <strong>Examen<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e1metro\/Indicador<\/th>\n      <th>Efecto<\/th>\n      <th>Valores iniciales\/Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Inicia la reescritura en segundo plano cuando el porcentaje de p\u00e1ginas da\u00f1adas supere este umbral.<\/td>\n      <td>En el caso de los servidores, es mejor optar por un valor m\u00e1s conservador, para que el flush se active antes.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>L\u00edmite m\u00e1ximo para las \u00abDirty Pages\u00bb; a partir de aqu\u00ed se limita la actividad de los escritores.<\/td>\n      <td>Si es demasiado alta, aumenta los riesgos de latencia; si es demasiado baja, se desperdicia el rendimiento.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisegundos<\/td>\n      <td>Intervalo en el que el n\u00facleo comprueba las p\u00e1ginas sucias para el vaciado en segundo plano.<\/td>\n      <td>Los intervalos m\u00e1s cortos suavizan los picos de carga, pero generan m\u00e1s activaciones.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>Edad a partir de la cual las \u201eDirty Pages\u201c se consideran \u00abmaduras\u00bb y se escriben de forma preferente.<\/td>\n      <td>Los valores m\u00e1s altos agrupan en mayor medida, pero reducen las garant\u00edas de consistencia en caso de error.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>N\u00famero actual de p\u00e1ginas sucias o que se han revertido de forma activa.<\/td>\n      <td>\u00datil para la observaci\u00f3n en tiempo real durante las pruebas de carga.<\/td>\n    <\/tr>\n    <tr>\n      <td>Opciones de montaje\/FS (por ejemplo, barreras, modo de registro)<\/td>\n      <td>Influyen en el orden, la persistencia y el coste de cada vaciado.<\/td>\n      <td>Selecciona la opci\u00f3n adecuada en funci\u00f3n del sistema de archivos y del dispositivo.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Leo estos valores con regularidad y los relaciono con los tiempos de espera de E\/S en Top, iostat o herramientas similares. <strong>Herramientas<\/strong>. Esto permite saber con claridad si es el propio Writeback el que impone la limitaci\u00f3n o si es el <strong>Almacenamiento<\/strong> est\u00e1 al l\u00edmite.<\/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-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguimiento y diagn\u00f3stico: lo que mido<\/h2>\n\n<p>Primero compruebo \/proc\/meminfo y observo los campos \u00abDirty\u00bb y \u00abWriteback\u00bb, mientras que de forma espec\u00edfica <strong>Carga<\/strong> genero. Si los \u00abdirty\u00bb suben mucho y se mantienen altos, a menudo faltan los \u00abflushes\u00bb oportunos o el <strong>Medio<\/strong> est\u00e1 a plena capacidad. Si el \u00abwriteback\u00bb aumenta, pero el \u00abdirty\u00bb solo desciende lentamente, el dispositivo de destino o la ruta de E\/S se ralentizan. Si los picos de latencia coinciden con los picos de \u00abwriteback\u00bb, suavizo el intervalo o reduzco los valores de la relaci\u00f3n. Para familiarizarme con los patrones t\u00edpicos, me resulta \u00fatil un breve <a href=\"https:\/\/webhosting.de\/es\/optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux\/\">Potenciador de la cach\u00e9 de p\u00e1gina<\/a>, que recoge los tornillos de ajuste y los puntos de medici\u00f3n.<\/p>\n\n<h2>Puntos de medici\u00f3n avanzados, vmstat y traza<\/h2>\n\n<p>Adem\u00e1s de \/proc\/meminfo, utilizo contadores de gran detalle para distinguir entre causa y efecto. En <strong>\/proc\/vmstat<\/strong> Campos como nr_dirty, nr_writeback, nr_dirtied y nr_written ofrecen indicaciones sobre la din\u00e1mica: \u00bfa qu\u00e9 velocidad se ensucian los bloques y a qu\u00e9 velocidad se vac\u00edan? Adem\u00e1s, observo la longitud de las colas de E\/S y las tasas de interrupci\u00f3n de las operaciones de fusi\u00f3n en la capa de bloques.<\/p>\n\n<ul>\n  <li>vmstat 1: muestra por segundo la deriva de \u00abDirty\/Writeback\u00bb y la espera de E\/S (wa),<\/li>\n  <li>\/proc\/pressure\/memory: muestra la presi\u00f3n de memoria que desencadena indirectamente el \u00abwriteback\u00bb,<\/li>\n  <li>Puntos de seguimiento (writeback:*) y eventos de bloque: revelan el orden y el tama\u00f1o de los vaciados,<\/li>\n  <li>perf\/ftrace: identifica los puntos cr\u00edticos en balance_dirty_pages y en las colas de trabajo de Flusher.<\/li>\n<\/ul>\n\n<p>Si veo que nr_dirtied se mantiene constantemente por encima de nr_written, es una se\u00f1al clara de que se avecina una limitaci\u00f3n de rendimiento o de que los vaciados en segundo plano se est\u00e1n realizando demasiado tarde. Si los picos en los puntos de seguimiento de writeback coinciden con los picos de latencia, optimizo el intervalo y el tama\u00f1o de los lotes.<\/p>\n\n<h2>HDD frente a SSD: repercusiones en el dise\u00f1o de la escritura diferida<\/h2>\n\n<p>En las mesas giratorias, las secuencias largas y consecutivas son especialmente rentables, ya que evitan la costosa b\u00fasqueda <strong>Evite<\/strong>. Los SSD tambi\u00e9n se benefician, aunque en este caso lo que cuenta es la distribuci\u00f3n de las operaciones de escritura y la interacci\u00f3n con el <strong>Controlador<\/strong>. Evito un n\u00famero excesivo de peque\u00f1as sincronizaciones para que el firmware pueda funcionar de forma eficiente. Al mismo tiempo, en el caso de los SSD, presto especial atenci\u00f3n a las barreras de consistencia y a la sem\u00e1ntica de vaciado para aprovechar realmente las garant\u00edas del dispositivo. Las cargas de trabajo mixtas con lecturas y escrituras aleatorias responden de forma notable a peque\u00f1os ajustes en los umbrales de datos sucios y en la sincronizaci\u00f3n del vaciado.<\/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\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cach\u00e9 del dispositivo, sem\u00e1ntica de vaciado y protecci\u00f3n contra cortes de corriente (PLP)<\/h2>\n\n<p>Que un flush se mantenga realmente depende tambi\u00e9n de <strong>Cach\u00e9 del dispositivo<\/strong> ... Muchas unidades almacenan los datos en su propia memoria DRAM. Sin <strong>Protecci\u00f3n contra p\u00e9rdidas de potencia (PLP)<\/strong> Corro el riesgo de perder datos si la cach\u00e9 no se vac\u00eda a tiempo. Aunque el \u00abwriteback\u00bb se beneficia de la cach\u00e9 del dispositivo, me aseguro de que se respeten las barreras y los comandos de vaciado. En sistemas con controladores RAID, eval\u00fao si hay una cach\u00e9 respaldada por bater\u00eda o por memoria flash; en ese caso, las escrituras sincronizadas suelen ser m\u00e1s adecuadas, sin sacrificar la seguridad.<\/p>\n\n<p>Adem\u00e1s, distingo lo siguiente: el FUA (Force Unit Access) impone la persistencia por cada operaci\u00f3n de E\/S, pero consume IOPS. Las barreras de vaciado pueden guardar varias escrituras a la vez. Para rutas especialmente cr\u00edticas (como los diarios), acepto la sobrecarga de FUA\/flush, mientras que mantengo los datos masivos en el flujo de escritura diferida. Quien modifique las opciones de montaje o la configuraci\u00f3n del controlador debe verificar posteriormente, mediante pruebas de carga, que la sem\u00e1ntica de vaciado prevista funciona correctamente.<\/p>\n\n<h2>Consistencia de los datos: uso correcto de fsync, Flush y FUA<\/h2>\n\n<p>Utilizo fsync espec\u00edficamente para datos con un alto <strong>Valor<\/strong>, que necesitan una garant\u00eda clara de durabilidad. El n\u00facleo puede llevar las operaciones de vaciado hasta el soporte de almacenamiento y, mediante FUA, exigir que una escritura se realice realmente <strong>persiste<\/strong>, antes de que se reciba la confirmaci\u00f3n. Este m\u00e9todo requiere tiempo e IOPS, pero evita la p\u00e9rdida de datos en caso de fallos del sistema. Sin estas barreras, el sistema notificar\u00eda que las operaciones se han realizado con \u00e9xito, aunque los bytes a\u00fan se encuentren en la cach\u00e9 del SSD o en la RAM. Adapto estas decisiones a la aplicaci\u00f3n: los registros de transacciones se guardan de forma definitiva, mientras que las actualizaciones masivas se guardan de forma provisional.<\/p>\n\n<h2>Ejemplos de optimizaci\u00f3n para cargas de trabajo de alojamiento y bases de datos<\/h2>\n\n<p>En el caso de los servidores web y de bases de datos, suelo establecer un valor moderado para `dirty_background_ratio` y mantengo `dirty_ratio` bastante por encima de ese valor, para que el vaciado en segundo plano se realice a tiempo. <strong>iniciar<\/strong>, sin que Schreiber se adelantara demasiado <strong>Freno<\/strong>. En las r\u00e1fagas de escritura, reduzco el intervalo de reescritura para que los mecanismos de reescritura se activen antes. En sistemas con mucha RAM, prefiero los valores *_bytes, para que se utilicen magnitudes reales en lugar de porcentajes. Pruebo cada cambio con pruebas de rendimiento repetibles y mido la latencia, el rendimiento y los percentiles 95 y 99. Esta gu\u00eda pr\u00e1ctica me ofrece una visi\u00f3n general concisa sobre el funcionamiento de la cach\u00e9 de p\u00e1ginas: <a href=\"https:\/\/webhosting.de\/es\/optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux\/\">Optimizador del rendimiento de la cach\u00e9 de p\u00e1ginas de Linux<\/a>.<\/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\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S directa y mmap: cuando se omite la cach\u00e9 de p\u00e1ginas<\/h2>\n\n<p>No todas las aplicaciones utilizan la cach\u00e9 de p\u00e1gina de la misma manera. Con <strong>O_DIRECTO<\/strong> Puede eludir deliberadamente la cach\u00e9 y escribir o leer directamente en el dispositivo. Esto alivia la carga de la RAM y acorta los recorridos, pero me priva de las ventajas del procesamiento por lotes y la lectura anticipada. Para transferencias grandes y puntuales, esto puede resultar \u00fatil; sin embargo, en el caso de muchas operaciones de escritura peque\u00f1as, pierdo las ventajas del \u00abwriteback\u00bb.<\/p>\n\n<p>Con <strong>mmap<\/strong> y, con Copy-on-Write, marco las p\u00e1ginas como \u00abdirty\u00bb cuando se modifican; el vaciado se realiza a trav\u00e9s de la ruta normal de Writeback o mediante <strong>msync<\/strong>. Lo tengo en cuenta cuando las aplicaciones recurren en gran medida a la E\/S mapeada en memoria: pueden producirse picos de datos sucios de forma inesperada, aunque la aplicaci\u00f3n \u201esolo\u201c escriba en memoria. Tambi\u00e9n en este caso, los l\u00edmites de ratio y bytes ayudan a controlar el momento en que se realiza la escritura en el disco.<\/p>\n\n<h2>Entornos de contenedores y cgroup-Writeback<\/h2>\n\n<p>En entornos multitenant, evito los \u201evecinos ruidosos\u201c mediante <strong>cgroups<\/strong>. El n\u00facleo asigna las p\u00e1ginas sucias al grupo responsable (cgroup-Writeback), de modo que el vaciado en segundo plano y la limitaci\u00f3n de rendimiento se distribuyen de forma m\u00e1s equitativa. Con l\u00edmites de memoria (<strong>memoria.alta<\/strong>, memory.max) limito los picos de memoria sucia por contenedor. Adem\u00e1s, establezco cuotas de E\/S a trav\u00e9s del controlador de E\/S para evitar que determinadas cargas de trabajo ocupen toda la cola del dispositivo.<\/p>\n\n<p>En la pr\u00e1ctica, defino l\u00edmites m\u00e1ximos realistas para cada clase de servicio: a los trabajos por lotes con gran carga de escritura se les asignan \u00abbudgets sucios\u00bb amplios, mientras que a los frontends en los que la latencia es cr\u00edtica se les asignan l\u00edmites m\u00e1s ajustados. De este modo, la latencia total se mantiene m\u00e1s estable, ya que el \u00abwriteback\u00bb no reduce bruscamente el rendimiento para todos en cuanto un \u00fanico contenedor se sale de la l\u00ednea.<\/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-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sistemas de archivos en red (NFS, SMB, sistemas de archivos distribuidos)<\/h2>\n\n<p>En los sistemas de archivos en red se a\u00f1ade un nivel adicional de b\u00fafer. Las p\u00e1ginas sucias locales solo indican que hay datos en tr\u00e1nsito; si <strong>remoto<\/strong> El protocolo (sem\u00e1ntica de commit) y el servidor son los que deciden si se han guardado de forma permanente. No conf\u00edo en los vaciados impl\u00edcitos: los datos cr\u00edticos los sincronizo de forma expl\u00edcita. Al mismo tiempo, tengo en cuenta los costes de ida y vuelta: las sincronizaciones demasiado frecuentes a trav\u00e9s de la red empeoran notablemente las latencias.<\/p>\n\n<p>En cargas de trabajo mixtas, separo las rutas: los archivos locales y temporales se benefician al m\u00e1ximo de la cach\u00e9 de p\u00e1ginas; a los montajes de red se les asignan puntos de sincronizaci\u00f3n m\u00e1s estrictos. De este modo, evito que la escritura diferida a trav\u00e9s de la red se convierta en un cuello de botella, mientras que los trabajos locales a\u00fan dispondr\u00edan de reservas.<\/p>\n\n<h2>Programador de E\/S, blk-mq y profundidad de cola<\/h2>\n\n<p>La eficiencia con la que los lotes de reescritura llegan al dispositivo depende tambi\u00e9n de <strong>Blocklayer<\/strong> a partir de. Con <strong>blk-mq<\/strong> Las operaciones de E\/S se distribuyen entre varias colas; los programadores como mq-deadline o kyber establecen prioridades y ordenan las operaciones. Elijo el programador m\u00e1s adecuado para cada soporte: en NVMe suele ser recomendable \u201enone\u201c, mientras que en SATA o SAS, Deadline ayuda a ordenar las operaciones de escritura.<\/p>\n\n<p>El <strong>Profundidad de la cola<\/strong> Lo configuro de tal forma que el dispositivo est\u00e9 a pleno rendimiento, pero sin saturarse. Una profundidad demasiado baja reduce el rendimiento; una demasiado profunda aumenta la dispersi\u00f3n de la latencia y dificulta la regulaci\u00f3n del tr\u00e1fico. El \u201ewriteback\u201c se beneficia de profundidades moderadas y de solicitudes grandes y contiguas. Superviso las tasas de fusi\u00f3n y los contadores \u00abinflight\u00bb; una disminuci\u00f3n de las tasas de fusi\u00f3n indica que los lotes son demasiado peque\u00f1os o que hay cargas de trabajo aleatorias que compiten entre s\u00ed.<\/p>\n\n<h2>Pruebas reproducibles y reversi\u00f3n segura<\/h2>\n\n<p>Antes de ajustar los reguladores, compruebo el estado actual y realizo una prueba <strong>Reproducible<\/strong> y planifico los retrocesos. Utilizo cargas de trabajo id\u00e9nticas, vol\u00famenes de datos id\u00e9nticos y precaliento la cach\u00e9 de forma selectiva o la vac\u00edo deliberadamente para que las pruebas sean comparables. Primero aplico los cambios en la configuraci\u00f3n de forma temporal, observo las m\u00e9tricas y solo despu\u00e9s los guardo de forma permanente.<\/p>\n\n<pre><code># Ejemplo: ajustes temporales (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Prueba de carga breve (ejemplo, depende de la carga de trabajo)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Mientras tanto, leo en paralelo \/proc\/meminfo, vmstat e iostat y correlaciono los picos. Tras la prueba, restablezco los valores o los incorporo de forma controlada a la configuraci\u00f3n del sistema. Para ello, documento <strong>fecha<\/strong>, <strong>N\u00facleo<\/strong>-Versi\u00f3n, detalles del dispositivo y del sistema de archivos, para que las comparaciones posteriores sean fiables.<\/p>\n\n<h2>Problemas habituales y soluciones<\/h2>\n\n<p>Si el sistema parece funcionar con fluidez, pero las operaciones de escritura se ralentizan, compruebo si se debe a una limitaci\u00f3n de rendimiento causada por un valor demasiado bajo de <strong>cociente_sucio<\/strong>. Si el \u00abDirty\u00bb se mantiene en un nivel alto, falta ancho de banda o el <strong>Intervalo<\/strong> Es demasiado largo para el flush. Si las latencias se disparan ante breves picos de sincronizaci\u00f3n, distribuyo la carga en lotes m\u00e1s peque\u00f1os y optimizo la planificaci\u00f3n de E\/S. Si la cach\u00e9 apenas se activa, es posible que un l\u00edmite de *_bytes demasiado peque\u00f1o impida una agrupaci\u00f3n en lotes adecuada. Un an\u00e1lisis m\u00e1s detallado de <a href=\"https:\/\/webhosting.de\/es\/servidor-pagina-cache-desalojo-linux-memoria-impresion-optimizacion-insight\/\">Expulsi\u00f3n de la cach\u00e9 al imprimir<\/a> ayuda cuando, adem\u00e1s, la falta de espacio de almacenamiento supone un obst\u00e1culo.<\/p>\n\n<h2>Buenas pr\u00e1cticas y breve lista de comprobaci\u00f3n<\/h2>\n\n<p>Distingo claramente entre los datos que deben guardarse de inmediato y aquellos que pueden almacenarse m\u00e1s tarde, con el fin de <strong>Actuaci\u00f3n<\/strong> para ganar. En el caso de los registros y los diarios de transacciones, fuerzo las sincronizaciones; para los artefactos temporales, dejo que el \u00abwriteback\u00bb funcione libremente y solo vigilo el l\u00edmite de restricci\u00f3n. Antes de cada ajuste, mido el estado actual y realizo comparaciones A\/B mediante escenarios definidos. Mantengo bajo control el n\u00famero de escritores simult\u00e1neos, ya que las oleadas descoordinadas reducen la utilidad del procesamiento por lotes. Y documento los cambios de inmediato, para que los an\u00e1lisis futuros se basen en datos claros <strong>Datos<\/strong> con base.<\/p>\n\n<h2>Resumen pr\u00e1ctico para alcanzar el \u00e9xito r\u00e1pidamente<\/h2>\n\n<p>La cach\u00e9 de reescritura agrupa los cambios en el <strong>P\u00e1gina<\/strong> La cach\u00e9 reduce los costes de E\/S y alivia la carga de las aplicaciones. Las p\u00e1ginas sucias no son un error, sino un recurso espec\u00edfico para ganar velocidad, siempre y cuando conozca los l\u00edmites y los requisitos de consistencia. Con los par\u00e1metros vm.dirty_background_ratio y vm.dirty_ratio regulo cu\u00e1ndo el n\u00facleo trabaja silenciosamente en segundo plano y cu\u00e1ndo frena las operaciones de escritura. Las herramientas y el directorio \/proc me proporcionan la visibilidad necesaria sobre las p\u00e1ginas sucias y la reescritura, para que no vaya a ciegas. Si domino estos controles, la web, las bases de datos y los trabajos por lotes funcionan notablemente m\u00e1s r\u00e1pido, sin que ello afecte a la <strong>Integridad<\/strong> poner en peligro mis datos.<\/p>","protected":false},"excerpt":{"rendered":"<p>La cach\u00e9 de reescritura en el n\u00facleo de Linux: explicaci\u00f3n clara de las p\u00e1ginas sucias, la cach\u00e9 de p\u00e1ginas y la reescritura.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","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":"144","_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":null,"_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":"Writeback Cache","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":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}