{"id":20874,"date":"2026-08-21T18:22:37","date_gmt":"2026-08-21T16:22:37","guid":{"rendered":"https:\/\/webhosting.de\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/"},"modified":"2026-08-21T18:22:37","modified_gmt":"2026-08-21T16:22:37","slug":"vm-vfs-presion-de-cache-linux-ajuste-de-la-cache-del-sistema-de-archivos-optimizacion","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/","title":{"rendered":"Explicaci\u00f3n de vm.vfs_cache_pressure: c\u00f3mo aprovechar al m\u00e1ximo la cach\u00e9 del sistema de archivos de Linux"},"content":{"rendered":"<p>Voy a explicar c\u00f3mo funciona el par\u00e1metro del n\u00facleo <strong>vm.vfs_cache_pressure<\/strong> la ponderaci\u00f3n de la cach\u00e9 VFS frente a la cach\u00e9 de p\u00e1ginas y qu\u00e9 valores aportan mayor velocidad con un perfil de carga real. Con pasos claros, ajusto este par\u00e1metro, mido los efectos y as\u00ed aprovecho el <strong>Cach\u00e9 del sistema de archivos<\/strong> \u00f3ptimo.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<p>Para empezar r\u00e1pidamente, voy a resumir los aspectos m\u00e1s importantes sobre el tuning del <strong>Cach\u00e9s VFS<\/strong> en conjunto. De este modo, a la hora de elegir el valor, tengo en cuenta el efecto sobre las consultas de metadatos, la carga de E\/S y la presi\u00f3n sobre la RAM. Estos puntos me ayudan a optimizar de forma segura y repetible las funciones t\u00edpicas de los servidores.<\/p>\n\n<ul>\n  <li><strong>Mecanismo de acci\u00f3n<\/strong>: Controla el grado de agresividad con el que el n\u00facleo libera los dentries\/inodos en comparaci\u00f3n con la cach\u00e9 de p\u00e1ginas.<\/li>\n  <li><strong>Configuraci\u00f3n predeterminada<\/strong>: 100 significa un ajuste equilibrado sin dar preferencia a nadie.<\/li>\n  <li><strong>Valores bajos<\/strong>: Los valores de 50 a 80 mantienen los metadatos en la memoria RAM durante m\u00e1s tiempo y aceleran la b\u00fasqueda de archivos.<\/li>\n  <li><strong>Valores elevados<\/strong>: Entre 120 y 200, las cach\u00e9s VFS se liberan m\u00e1s r\u00e1pido y dejan espacio para los procesos.<\/li>\n  <li><strong>Pr\u00e1ctica<\/strong>: Cambiar paso a paso, medir, documentar; solo entonces seguir ajustando.<\/li>\n<\/ul>\n\n<p>Aplico estos principios de forma sistem\u00e1tica para lograr el equilibrio adecuado entre <strong>\u00cdndice de aciertos de la cach\u00e9<\/strong> y la memoria RAM libre. A continuaci\u00f3n, ajusto el valor de vm.vfs_cache_pressure poco a poco, observo los picos de carga y lo corrijo si es necesario. De esta forma consigo tiempos de respuesta estables sin cuellos de botella inesperados en la memoria.<\/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-cache-optimierung-4756.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00bfQu\u00e9 es vm.vfs_cache_pressure?<\/h2>\n\n<p>Este par\u00e1metro controla el nivel de rigidez con el que el n\u00facleo trata el <strong>Cach\u00e9 VFS<\/strong> En comparaci\u00f3n con otros tipos de memoria, se libera tan pronto como la RAM empieza a escasear. En la cach\u00e9 VFS se almacenan dentries e inodos, es decir, entradas de directorio y metadatos de archivos, lo que acelera notablemente las b\u00fasquedas de archivos. Un valor de 100 trata la cach\u00e9 VFS y la cach\u00e9 de p\u00e1ginas por igual, mientras que los valores m\u00e1s bajos dan prioridad al mantenimiento de los metadatos en la RAM. Los valores m\u00e1s altos hacen que el n\u00facleo descarte antes las entradas del VFS y libere memoria m\u00e1s r\u00e1pidamente. Utilizo este control de forma espec\u00edfica para mantener un alto porcentaje de aciertos de metadatos en cargas de trabajo web, de archivos y de CMS, sin desplazar procesos. As\u00ed controlo el equilibrio entre <strong>Velocidad de b\u00fasqueda<\/strong> y la memoria libre de forma muy directa.<\/p>\n\n<h2>\u00bfC\u00f3mo funciona exactamente la cach\u00e9 VFS?<\/h2>\n\n<p>El sistema de archivos virtual constituye una capa com\u00fan para ext4, XFS, Btrfs y otros, y almacena <strong>Dentries<\/strong> e inodos en la RAM, para que los escaneos de directorios y los accesos recurrentes sigan siendo r\u00e1pidos. La cach\u00e9 de p\u00e1ginas, por su parte, almacena los bloques de archivo propiamente dichos; ambas cach\u00e9s se complementan, pero compiten por la memoria cuando hay presi\u00f3n. Cuantos m\u00e1s archivos peque\u00f1os y accesos repetitivos haya, m\u00e1s se beneficia la aplicaci\u00f3n de una alta tasa de aciertos en los metadatos. Es precisamente aqu\u00ed donde entra en juego vm.vfs_cache_pressure: puedo determinar si Linux conserva estos metadatos o los desplaza r\u00e1pidamente. Para aspectos m\u00e1s detallados de la cach\u00e9 de p\u00e1ginas, utilizo adem\u00e1s el compacto <a href=\"https:\/\/webhosting.de\/es\/optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux\/\">Optimizador de rendimiento de la cach\u00e9 de p\u00e1ginas<\/a> como informaci\u00f3n de referencia para poder evaluar el VFS y la cach\u00e9 de p\u00e1gina en su contexto.<\/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\/linuxcachemeeting1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valor por defecto y rangos t\u00edpicos<\/h2>\n\n<p>En la mayor\u00eda de los sistemas, el valor est\u00e1 establecido en <strong>100<\/strong> y, de este modo, constituye una base equilibrada para las primeras pruebas. Si reduzco el valor, doy prioridad a los metadatos y estabilizo las b\u00fasquedas r\u00e1pidas, lo que resulta especialmente \u00fatil cuando hay muchos archivos peque\u00f1os. Si aumento el valor, Linux elimina m\u00e1s r\u00e1pidamente las entradas del VFS y libera m\u00e1s memoria intermedia para las aplicaciones o la cach\u00e9 de p\u00e1ginas. Solo utilizo con mucha precauci\u00f3n valores extremos como 0 o valores superiores a 500, ya que pueden provocar un comportamiento extremo y tener efectos secundarios. En el d\u00eda a d\u00eda, empiezo con 100, voy avanzando en pasos de entre 20 y 40 puntos y mido el efecto en <strong>Latencia de E\/S<\/strong> y tiempos de respuesta.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Valor<\/th>\n      <th>Significado<\/th>\n      <th>Cu\u00e1ndo utilizar<\/th>\n      <th>Riesgo\/Aviso<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>&lt; 100 (p. ej., 50-80)<\/td>\n      <td>La cach\u00e9 VFS permanece m\u00e1s tiempo en la RAM<\/td>\n      <td>Muchos archivos peque\u00f1os, b\u00fasquedas frecuentes<\/td>\n      <td>Mayor uso de la RAM en <strong>Metadatos<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>100<\/td>\n      <td>Ajuste equilibrado<\/td>\n      <td>Un valor inicial fiable para las mediciones<\/td>\n      <td>Bien <strong>L\u00ednea de base<\/strong>Valor \u2011<\/td>\n    <\/tr>\n    <tr>\n      <td>&gt; 100 (por ejemplo, 120-200)<\/td>\n      <td>La cach\u00e9 VFS se libera de forma m\u00e1s agresiva<\/td>\n      <td>Escasez de RAM, bases de datos con cach\u00e9 propia<\/td>\n      <td>Posible latencia de consulta<\/td>\n    <\/tr>\n    <tr>\n      <td>Extremo (0, &gt; 500)<\/td>\n      <td>Cambios significativos<\/td>\n      <td>Casos especiales: prueba r\u00e1pida<\/td>\n      <td>Amenaza para la estabilidad y <strong>Actuaci\u00f3n<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Con esta plantilla puedo identificar r\u00e1pidamente qu\u00e9 direcci\u00f3n es la adecuada, sin perder el rumbo. Evito dar pasos demasiado grandes y registro cada cambio con detalle. De este modo, el camino recorrido queda siempre claro y mantengo una comparaci\u00f3n clara con los puntos de medici\u00f3n anteriores.<\/p>\n\n<h2>Funci\u00f3n en la limpieza de la memoria<\/h2>\n\n<p>Cuando hay presi\u00f3n, el n\u00facleo debe liberar memoria RAM, y es precisamente aqu\u00ed donde vm.vfs_cache_pressure define el equilibrio entre <strong>Cach\u00e9 VFS<\/strong>, la cach\u00e9 de p\u00e1ginas y la memoria de procesos. Los valores bajos mantienen las entradas de directorios e inodos en la memoria durante m\u00e1s tiempo, lo que agiliza las consultas a los directorios y las aperturas repetidas de archivos. Los valores altos liberan memoria antes y proporcionan m\u00e1s espacio para los procesos o para la cach\u00e9 de p\u00e1ginas, lo que puede resultar \u00fatil cuando la RAM es escasa. En este sentido, presto especial atenci\u00f3n a las latencias de E\/S, ya que una cach\u00e9 de metadatos demasiado vac\u00eda ralentiza la b\u00fasqueda de archivos. Esta informaci\u00f3n me resulta \u00fatil para la interacci\u00f3n con las estrategias de liberaci\u00f3n de la cach\u00e9 de p\u00e1ginas, ya que me proporciona una visi\u00f3n sobre <a href=\"https:\/\/webhosting.de\/es\/servidor-pagina-cache-desalojo-linux-memoria-impresion-optimizacion-insight\/\">Eliminaci\u00f3n de la cach\u00e9 de p\u00e1ginas<\/a> valiosas referencias pr\u00e1cticas que me permitan tomar decisiones basadas en datos.<\/p>\n\n<h2>Metodolog\u00eda de medici\u00f3n: hacer que la cach\u00e9 VFS sea transparente<\/h2>\n\n<p>Antes de hacer cambios, lo pongo a la vista, <strong>donde<\/strong> la memoria est\u00e1 y <strong>qu\u00e9<\/strong> se desplaza. As\u00ed puedo determinar si los metadatos son realmente el cuello de botella, o si predominan la cach\u00e9 de p\u00e1gina, los procesos o las p\u00e1ginas sucias.<\/p>\n\n<ul>\n  <li><strong>\/proc\/meminfo<\/strong>: Analizo InodeCache, Cached, Buffers, SReclaimable y SUnreclaim para evaluar su proporci\u00f3n y recuperabilidad.<\/li>\n  <li><strong>losa<\/strong>: Vista en tiempo real de los \u00abslabs\u00bb, en concreto de \u00abdentry\u00bb, \u00abinode_cache\u00bb, \u00abext4_inode_cache\u00bb y \u00abxfs_inode\u00bb. As\u00ed puedo ver si los \u00abdentries\u00bb y los \u00abinodes\u00bb aumentan o disminuyen.<\/li>\n  <li><strong>Ruta de E\/S<\/strong>: Con vmstat\/iostat compruebo las latencias de lectura y si aumentan los accesos al disco durante las b\u00fasquedas.<\/li>\n<\/ul>\n\n<pre><code># Resumen r\u00e1pido\ngrep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' \/proc\/meminfo\n\n# Distribuci\u00f3n de slabs (ordenada por tama\u00f1o)\nsudo slabtop -s c\n\n# Filtrar solo los slabs de tipo dentry\/inode\ngrep -Ei 'dentry|inode' \/proc\/slabinfo | sort -k3 -nr | head\n\n# Tendencias de E\/S y memoria cada segundo\nvmstat 1\niostat -x 1\n<\/code><\/pre>\n\n<p>Creo que la interpretaci\u00f3n es clara: si SReclaimable crece junto con los bloques de dentry\/inode y, al mismo tiempo, aumentan las latencias de E\/S <em>no<\/em>, lo que confirma que la cach\u00e9 de metadatos funciona correctamente. Si estos valores suelen caer a cero y se disparan r\u00e1pidamente al acceder al directorio, es probable que vm.vfs_cache_pressure sea demasiado agresivo.<\/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-cache-optimization-tips-5467.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ejemplo pr\u00e1ctico: leer y modificar el valor actual<\/h2>\n\n<p>La comprobaci\u00f3n se realiza desde la l\u00ednea de comandos en cuesti\u00f3n de segundos y sin <strong>Reinicie<\/strong>. Leo el valor real y, en un primer momento, guardo los valores de prueba de forma temporal para poder aplicar inmediatamente los retrocesos en la ventana de prueba. Para los ajustes en producci\u00f3n, introduzco entradas en \/etc\/sysctl.conf o en un archivo de \/etc\/sysctl.d\/, las recargo y anoto el cambio en mi documentaci\u00f3n. Pruebo cada nivel bajo una carga realista, no solo en reposo, para que los efectos sean visibles. De este modo, garantizo comparaciones claras \u00abantes y despu\u00e9s\u00bb y eval\u00fao el cambio bas\u00e1ndome en indicadores cuantificables.<\/p>\n\n<pre><code># Comprobar el valor actual\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n# o bien\nsysctl vm.vfs_cache_pressure\n\n# Probar temporalmente (hasta el reinicio)\nsudo sysctl -w vm.vfs_cache_pressure=60\n# Alternativamente\necho 60 | sudo tee \/proc\/sys\/vm\/vfs_cache_pressure\n\n# Configurar de forma permanente\necho \"vm.vfs_cache_pressure = 60\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p\n<\/code><\/pre>\n\n<h2>Optimizaci\u00f3n de la cach\u00e9 en Linux: casos pr\u00e1cticos<\/h2>\n\n<p>En plataformas de alojamiento con muchos recursos est\u00e1ticos, repositorios de archivos o aplicaciones con su propio b\u00fafer, conviene realizar una <strong>ponderaci\u00f3n<\/strong> de la cach\u00e9 VFS. Los servidores web con numerosos archivos peque\u00f1os se benefician enormemente de valores m\u00e1s bajos, ya que las b\u00fasquedas en el SSD\/HDD son menos frecuentes. Los servidores de archivos con tama\u00f1os de archivo variados pueden utilizar valores moderadamente reducidos si se dispone de suficiente RAM. Los servidores de bases de datos con una elevada carga de RAM y una cach\u00e9 de base de datos grande prefieren valores m\u00e1s altos, para que los procesos dispongan de espacio suficiente. Eval\u00fao estos patrones en cada caso con datos de monitorizaci\u00f3n, para que la configuraci\u00f3n se adapte a la combinaci\u00f3n real de accesos.<\/p>\n\n<h3>Servidor web con muchos archivos est\u00e1ticos<\/h3>\n<p>En el caso de CSS, JS e im\u00e1genes, prefiero conservar los metadatos durante m\u00e1s tiempo en el <strong>Cache<\/strong>. Los valores entre 50 y 80 suelen dar buenos resultados, ya que la reapertura de archivos se realiza m\u00e1s r\u00e1pido. Analizo minuciosamente los picos de E\/S durante los picos de tr\u00e1fico y comparo los tiempos de respuesta antes y despu\u00e9s del cambio. Si las latencias se mantienen estables y se reducen los costes de b\u00fasqueda de errores 404, vamos por buen camino. Vigilo el uso de la RAM para garantizar que los procesos dispongan de espacio suficiente a pesar de un cach\u00e9 de metadatos m\u00e1s grande.<\/p>\n\n<h3>Servidores de archivos o sistemas NAS<\/h3>\n<p>Las numerosas conexiones de usuarios y los cambios de directorio se benefician de <strong>m\u00e1s bajo<\/strong> hasta alcanzar unos valores equilibrados. Si hay suficiente RAM, tiendo a situarme entre 50 y 80; si la memoria es m\u00e1s escasa, me mantengo m\u00e1s cerca de 100. Compruebo que los listados de directorios sigan siendo fluidos y que las instant\u00e1neas y copias de seguridad no desplacen en exceso las cach\u00e9s. Si la latencia de E\/S aumenta en los picos, la ajusto con cuidado al alza. As\u00ed mantengo el equilibrio entre comodidad y memoria libre.<\/p>\n\n<h3>Servidores de bases de datos y sistemas con poca memoria<\/h3>\n<p>Las bases de datos mantienen su propia cach\u00e9 de b\u00fafer, por lo que le asigno al <strong>Memoria de proceso<\/strong> Suele tener prioridad. Los valores entre 120 y 200 indican que es mejor vaciar las cach\u00e9s VFS y liberar memoria RAM. Para ello, presto atenci\u00f3n a las latencias de las consultas y a los patrones de fallos de p\u00e1gina de la aplicaci\u00f3n. Si la base de datos se ralentiza porque el sistema empieza a realizar swap, aumento ligeramente el valor y, de paso, reduzco vm.swappiness. Este enfoque evita que los metadatos ocupen espacio innecesariamente, que la base de datos aprovecha mejor.<\/p>\n\n<h2>Ejemplos de cargas de trabajo y valores orientativos<\/h2>\n\n<p>Empiezo con 100 y voy reduciendo en incrementos de 20 para valores cercanos a los de la web <strong>Cargas de trabajo<\/strong> y lo aumento en incrementos de 20 para los procesos que consumen mucha memoria. Pruebo cada nivel al menos durante una fase de pico, para poder detectar los efectos sobre las latencias, las aciertos de cach\u00e9 y la actividad de intercambio. Quien quiera profundizar m\u00e1s, encontrar\u00e1 en el compacto <a href=\"https:\/\/webhosting.de\/es\/optimizador-del-rendimiento-de-la-cache-de-paginas-de-linux\/\">Optimizador de rendimiento de la cach\u00e9 de p\u00e1ginas<\/a> Informaci\u00f3n complementaria sobre las estrategias de cach\u00e9 de archivos que tengo en cuenta paralelamente. Cuando los valores medidos coinciden con los objetivos, congelo la configuraci\u00f3n y documento los indicadores clave. De este modo, la optimizaci\u00f3n sigue siendo reproducible y puedo realizar ajustes posteriores con rapidez.<\/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_cache_nutzung_4387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riesgos y dificultades<\/h2>\n\n<p>Si establezco un valor demasiado bajo, el n\u00facleo apenas podr\u00e1 liberar entradas del VFS, lo que en momentos de pico puede provocar <strong>OOM<\/strong>\u2011Esto conlleva riesgos. Si lo elevo demasiado, aumenta la latencia en las b\u00fasquedas de archivos y los cambios de directorio, ya que hay que volver a cargar los metadatos. Sin pruebas bajo carga real, se corre el riesgo de sacar conclusiones err\u00f3neas a partir de intervalos de tiempo de poca actividad. Los cambios bruscos dificultan la evaluaci\u00f3n, por lo que procedo de forma gradual. Anoto cada modificaci\u00f3n con la hora, el perfil de carga y los valores medidos, para que las causas queden claras.<\/p>\n\n<h2>Seguimiento e indicadores<\/h2>\n\n<p>Los datos concretos revelan si merece la pena realizar un ajuste <strong>M\u00e9tricas<\/strong>. Superviso el uso de la RAM, la distribuci\u00f3n entre cach\u00e9s y procesos, las latencias de E\/S y la actividad del swap. Adem\u00e1s, eval\u00fao las tasas de aciertos de cach\u00e9 y las tendencias de fallos de p\u00e1gina para detectar r\u00e1pidamente los efectos secundarios. Especialmente con muchos archivos peque\u00f1os, las mejoras en el tiempo hasta el primer byte son evidentes. Si la latencia de E\/S se mantiene baja y se reduce el intercambio, esto confirma que vamos por buen camino.<\/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\/linuxcache_4242.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gu\u00eda de ajuste: de la hip\u00f3tesis al ajuste fiable<\/h2>\n\n<p>La estructura evita actuar a ciegas. Sigo un procedimiento fijo para que los resultados sean fiables y mis compa\u00f1eros de equipo puedan comprender los pasos que sigo.<\/p>\n\n<ol>\n  <li><strong>Registrar los datos de referencia<\/strong>: vm.vfs_cache_pressure=100, carga realista de 24 a 72 horas. Guardar los indicadores clave (latencias: mediana\/95.\/99. percentil, tiempo de espera de E\/S, \u00abCPU steal\u00bb, actividad de intercambio, tama\u00f1o de inodo\/dentry).<\/li>\n  <li><strong>Formular una hip\u00f3tesis<\/strong>: \u201eMuchos archivos peque\u00f1os, las consultas son costosas: unos valores m\u00e1s bajos aceleran el proceso\u201c o \u201eLa memoria RAM escasea: unos valores m\u00e1s altos mantienen los procesos sin obstrucciones\u201c.<\/li>\n  <li><strong>Modificar paso a paso<\/strong>: de \u00b120 a \u00b140 puntos. Mide al menos una fase de pico por nivel.<\/li>\n  <li><strong>Comparar<\/strong>: Compruebo si los SLO (por ejemplo, el percentil 95) mejoran de forma fiable, <em>sin<\/em> Ya no se producen eventos de swap ni de OOM.<\/li>\n  <li><strong>Criterio de reversi\u00f3n<\/strong>: Si aumentan las latencias 95.\/99., se alargan los tiempos de espera de E\/S o se acumulan los fallos de cach\u00e9, doy un paso atr\u00e1s.<\/li>\n  <li><strong>Freeze y documentaci\u00f3n<\/strong>: Anotar el valor final, la fecha, la ventana de carga y los indicadores.<\/li>\n<\/ol>\n\n<pre><code># Prueba r\u00e1pida para ventanas de medici\u00f3n controladas (\u00a1solo mantenimiento!)\n# Antes: capturar instant\u00e1neas de los indicadores clave\ndate; free -h; grep -E 'InodeCache|Cached' \/proc\/meminfo; vmstat 1 5\n\nsudo sysctl -w vm.vfs_cache_pressure=80\n# Prueba de carga\/esperar a que se alcance el pico, luego volver a registrar las m\u00e9tricas y compararlas\n<\/code><\/pre>\n\n<h2>Sistemas de archivos y opciones de montaje: el contexto es importante<\/h2>\n\n<p>El efecto de vm.vfs_cache_pressure tambi\u00e9n depende del sistema de archivos y de las opciones de montaje. Yo eval\u00fao estos factores de la siguiente manera:<\/p>\n\n<ul>\n  <li><strong>relatiempo\/notiempo<\/strong>: Evita las frecuentes operaciones de escritura de \u00abatime\u00bb. \u00abnoatime\u00bb reduce la carga de E\/S cuando hay muchas lecturas, lo que hace que las ventajas de los metadatos sean m\u00e1s evidentes.<\/li>\n  <li><strong>lazytime<\/strong>: Retrasa las actualizaciones de metadatos en la RAM; esto suaviza los picos, pero interfiere con los momentos de vaciado.<\/li>\n  <li><strong>ext4 frente a XFS frente a Btrfs<\/strong>: Diferentes estructuras de inodos y comportamientos del \u00abshrinker\u00bb. Siempre mido <em>en el FS de destino<\/em>, en lugar de trasladar suposiciones.<\/li>\n  <li><strong>NFS\/Sistema de archivos en red<\/strong>: El almacenamiento en cach\u00e9 y la invalidaci\u00f3n de atributos pueden limitar las ventajas del VFS. Una liberaci\u00f3n agresiva (valores altos) aumenta entonces el n\u00famero de consultas remotas.<\/li>\n  <li><strong>OverlayFS\/FUSE<\/strong>: Muchas operaciones peque\u00f1as relacionadas con los metadatos se benefician enormemente de la cach\u00e9 VFS; yo mantengo los valores entre moderados y bajos, siempre que haya memoria RAM disponible.<\/li>\n<\/ul>\n\n<h2>Aspectos relacionados con los contenedores y los cgroups<\/h2>\n\n<p>En entornos de contenedores, tengo presente que vm.vfs_cache_pressure es un <strong>en todo el servidor<\/strong> Bot\u00f3n. Los cambios afectan a <em>todos<\/em> Pods\/contenedores en el nodo. Por eso, opto por un enfoque conservador y coordino el ajuste a nivel de nodo.<\/p>\n\n<ul>\n  <li><strong>L\u00edmites de almacenamiento<\/strong>: Los cgroups de memoria limitan la memoria de proceso y la cach\u00e9 de p\u00e1ginas; la memoria slab puede contabilizarse proporcionalmente. Observo que los eventos Pod-OOM y Node-Pressure est\u00e1n relacionados.<\/li>\n  <li><strong>Combinaci\u00f3n de cargas de trabajo<\/strong>: Los nodos que albergan a la vez DB-Pods y interfaces web no registran valores extremos. Si es necesario, distribuyo las funciones entre diferentes nodos.<\/li>\n  <li><strong>Despliegue<\/strong>: Primero en Canaries (un nodo) y, a continuaci\u00f3n, se implementa de forma escalonada. Documento los cambios en la l\u00ednea base de Node (sysctl.d) y anoto las implementaciones afectadas.<\/li>\n<\/ul>\n\n<h2>Casos especiales de la pr\u00e1ctica<\/h2>\n\n<p>Algunos patrones se pueden abordar de forma espec\u00edfica si conozco las causas:<\/p>\n\n<ul>\n  <li><strong>Tareas de CI\/Build<\/strong>: Los accesos frecuentes a archivos y los escaneos de directorios se benefician de valores m\u00e1s bajos. Los vuelvo a aumentar una vez finalizado el trabajo, en caso de que se utilicen nodos de forma mixta.<\/li>\n  <li><strong>Ventana de copia de seguridad\/escaneo<\/strong>: Las operaciones prolongadas en los directorios borran las cach\u00e9s. De forma temporal, se puede <em>m\u00e1s alto<\/em> Valor (por ejemplo, 180) para evitar que los dentries\/inodes llenen la RAM durante la copia de seguridad; despu\u00e9s lo vuelvo a poner como estaba.<\/li>\n  <li><strong>Entradas negativas<\/strong>: Los archivos que no existen (404) tambi\u00e9n se almacenan en cach\u00e9. Las cargas de trabajo web con accesos fallidos frecuentes mejoran de forma apreciable si la cach\u00e9 VFS no se vac\u00eda de forma demasiado agresiva.<\/li>\n  <li><strong>Transmisi\u00f3n en continuo\/E\/S secuencial<\/strong>: Aqu\u00ed predomina la cach\u00e9 de p\u00e1ginas; unos valores demasiado bajos no aportan mucho y consumen RAM innecesariamente. Yo me mantengo cerca del 100 o un poco por encima.<\/li>\n<\/ul>\n\n<pre><code># Ejemplo: ser un poco m\u00e1s agresivo durante una copia de seguridad completa\nsudo sysctl -w vm.vfs_cache_pressure=180\n# Tras la copia de seguridad, volver al valor \u00f3ptimo determinado anteriormente\nsudo sysctl -w vm.vfs_cache_pressure=60\n<\/code><\/pre>\n\n<h2>Automatizaci\u00f3n y gobernanza<\/h2>\n\n<p>Tras unas pruebas satisfactorias, incorporo la configuraci\u00f3n a mis compilaciones est\u00e1ndar. Es importante que los equipos sepan que, <em>por qu\u00e9<\/em> se haya seleccionado un valor y <em>cuando<\/em> que debe comprobarse (por ejemplo, tras cambios de versi\u00f3n o de carga de trabajo).<\/p>\n\n<ul>\n  <li><strong>Gesti\u00f3n de la configuraci\u00f3n<\/strong>: Suelo definir valores predeterminados para cada funci\u00f3n (web, base de datos, servidor de archivos) en \/etc\/sysctl.d\/ y los distribuyo de forma centralizada.<\/li>\n  <li><strong>Control de derrape<\/strong>: Las auditor\u00edas peri\u00f3dicas comprueban si los valores en tiempo real y el repositorio coinciden.<\/li>\n  <li><strong>Runbooks<\/strong>: Documento los pasos de medici\u00f3n, los valores l\u00edmite para la reversi\u00f3n y los procedimientos de emergencia (por ejemplo, restablecimiento a 100).<\/li>\n<\/ul>\n\n<pre><code># Funci\u00f3n: servidor web (ejemplo)\ncat &lt;&lt;&#039;EOF&#039; | sudo tee \/etc\/sysctl.d\/50-web-vfs.conf\nvm.vfs_cache_pressure = 60\nEOF\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>vm.vfs_cache_pressure y otros par\u00e1metros del n\u00facleo<\/h2>\n\n<p>Un buen resultado solo se consigue en combinaci\u00f3n con <strong>vm.swappiness<\/strong> y los umbrales de p\u00e1ginas sucias. Un valor m\u00e1s bajo de \u00abswappiness\u00bb (por ejemplo, entre 10 y 20) tiende a mantener los procesos en la RAM y evita el traspaso innecesario a la memoria de paginaci\u00f3n. Con vm.dirty_background_ratio y vm.dirty_ratio regulo la rapidez con la que el sistema escribe las p\u00e1ginas modificadas, para que los picos de escritura no lo bloqueen todo. Ajusto estos valores de manera que las b\u00fasquedas de metadatos sigan siendo r\u00e1pidas y las operaciones de escritura se desarrollen de forma planificada. Para ello, utilizo esta concisa visi\u00f3n general sobre la interacci\u00f3n de las cach\u00e9s de archivos: <a href=\"https:\/\/webhosting.de\/es\/sistema-de-archivos-almacenamiento-en-cache-linux-cache-de-pagina-cacheboost\/\">Resumen del almacenamiento en cach\u00e9 del sistema de archivos<\/a>.<\/p>\n\n<h2>Recomendaciones sobre entornos de alojamiento y WordPress<\/h2>\n\n<p>Muchos temas, plugins y archivos multimedia generan innumerables archivos peque\u00f1os, por lo que es necesario un potente <strong>Cach\u00e9 VFS<\/strong> ayuda notablemente. Empiezo con 100, lo reduzco a 80 si hay suficiente RAM, luego a 60, y compruebo los tiempos de respuesta, el percentil 95 de las latencias y el \u00abCPU-Steal\u00bb. Si la memoria sigue siendo suficiente, pruebo con 50 y vuelvo a validar los resultados durante el pico de la tarde o en el transcurso de las campa\u00f1as. Si las latencias disminuyen sin que se active el swap ni el OOM-Killer, consolido la configuraci\u00f3n de forma permanente. Al mismo tiempo, vigilo la cach\u00e9 de p\u00e1ginas para que ambas cach\u00e9s se complementen de forma \u00f3ptima.<\/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-cache-optimierung-7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumen<\/h2>\n\n<p>Con vm.vfs_cache_pressure controlo la <strong>Saldo<\/strong> de forma muy espec\u00edfica, en funci\u00f3n de las b\u00fasquedas r\u00e1pidas de metadatos y la RAM libre. Para cargas de trabajo relacionadas con la web, reduzco el valor moderadamente; para aplicaciones que consumen mucha memoria, lo aumento. Justifico cada cambio con valores de medici\u00f3n sobre latencias de E\/S, aciertos de cach\u00e9 y actividad de swap. En combinaci\u00f3n con vm.swappiness y los par\u00e1metros \u00abdirty\u00bb, consigo una gesti\u00f3n de la memoria estable. De este modo, aprovecho de forma eficiente la cach\u00e9 del sistema de archivos de Linux y mantengo los tiempos de respuesta bajos de forma fiable incluso bajo carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo aprovechar al m\u00e1ximo la cach\u00e9 del sistema de archivos de Linux utilizando \u00abvm.vfs_cache_pressure\u00bb como palabra clave clave, c\u00f3mo controlar las cach\u00e9s de forma espec\u00edfica y c\u00f3mo mejorar el rendimiento de las cargas de trabajo de tus servidores.<\/p>","protected":false},"author":1,"featured_media":20867,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20874","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":"128","_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":"vm.vfs_cache_pressure","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":"20867","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20874","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=20874"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20874\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20867"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}