Explicación de vm.vfs_cache_pressure: cómo aprovechar al máximo la caché del sistema de archivos de Linux

Voy a explicar cómo funciona el parámetro del núcleo vm.vfs_cache_pressure la ponderación de la caché VFS frente a la caché de páginas y qué valores aportan mayor velocidad con un perfil de carga real. Con pasos claros, ajusto este parámetro, mido los efectos y así aprovecho el Caché del sistema de archivos óptimo.

Puntos centrales

Para empezar rápidamente, voy a resumir los aspectos más importantes sobre el tuning del Cachés VFS 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ón sobre la RAM. Estos puntos me ayudan a optimizar de forma segura y repetible las funciones típicas de los servidores.

• Mecanismo de acción: Controla el grado de agresividad con el que el núcleo libera los dentries/inodos en comparación con la caché de páginas.
• Configuración predeterminada: 100 significa un ajuste equilibrado sin dar preferencia a nadie.
• Valores bajos: Los valores de 50 a 80 mantienen los metadatos en la memoria RAM durante más tiempo y aceleran la búsqueda de archivos.
• Valores elevados: Entre 120 y 200, las cachés VFS se liberan más rápido y dejan espacio para los procesos.
• Práctica: Cambiar paso a paso, medir, documentar; solo entonces seguir ajustando.

Aplico estos principios de forma sistemática para lograr el equilibrio adecuado entre Índice de aciertos de la caché y la memoria RAM libre. A continuación, 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.

¿Qué es vm.vfs_cache_pressure?

Este parámetro controla el nivel de rigidez con el que el núcleo trata el Caché VFS En comparación con otros tipos de memoria, se libera tan pronto como la RAM empieza a escasear. En la caché VFS se almacenan dentries e inodos, es decir, entradas de directorio y metadatos de archivos, lo que acelera notablemente las búsquedas de archivos. Un valor de 100 trata la caché VFS y la caché de páginas por igual, mientras que los valores más bajos dan prioridad al mantenimiento de los metadatos en la RAM. Los valores más altos hacen que el núcleo descarte antes las entradas del VFS y libere memoria más rápidamente. Utilizo este control de forma específica para mantener un alto porcentaje de aciertos de metadatos en cargas de trabajo web, de archivos y de CMS, sin desplazar procesos. Así controlo el equilibrio entre Velocidad de búsqueda y la memoria libre de forma muy directa.

¿Cómo funciona exactamente la caché VFS?

El sistema de archivos virtual constituye una capa común para ext4, XFS, Btrfs y otros, y almacena Dentries e inodos en la RAM, para que los escaneos de directorios y los accesos recurrentes sigan siendo rápidos. La caché de páginas, por su parte, almacena los bloques de archivo propiamente dichos; ambas cachés se complementan, pero compiten por la memoria cuando hay presión. Cuantos más archivos pequeños y accesos repetitivos haya, más se beneficia la aplicación de una alta tasa de aciertos en los metadatos. Es precisamente aquí donde entra en juego vm.vfs_cache_pressure: puedo determinar si Linux conserva estos metadatos o los desplaza rápidamente. Para aspectos más detallados de la caché de páginas, utilizo además el compacto Optimizador de rendimiento de la caché de páginas como información de referencia para poder evaluar el VFS y la caché de página en su contexto.

Valor por defecto y rangos típicos

En la mayoría de los sistemas, el valor está establecido en 100 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úsquedas rápidas, lo que resulta especialmente útil cuando hay muchos archivos pequeños. Si aumento el valor, Linux elimina más rápidamente las entradas del VFS y libera más memoria intermedia para las aplicaciones o la caché de páginas. Solo utilizo con mucha precaución valores extremos como 0 o valores superiores a 500, ya que pueden provocar un comportamiento extremo y tener efectos secundarios. En el día a día, empiezo con 100, voy avanzando en pasos de entre 20 y 40 puntos y mido el efecto en Latencia de E/S y tiempos de respuesta.

Valor	Significado	Cuándo utilizar	Riesgo/Aviso
< 100 (p. ej., 50-80)	La caché VFS permanece más tiempo en la RAM	Muchos archivos pequeños, búsquedas frecuentes	Mayor uso de la RAM en Metadatos
100	Ajuste equilibrado	Un valor inicial fiable para las mediciones	Bien Línea de baseValor ‑
> 100 (por ejemplo, 120-200)	La caché VFS se libera de forma más agresiva	Escasez de RAM, bases de datos con caché propia	Posible latencia de consulta
Extremo (0, > 500)	Cambios significativos	Casos especiales: prueba rápida	Amenaza para la estabilidad y Actuación

Con esta plantilla puedo identificar rápidamente qué dirección 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ón clara con los puntos de medición anteriores.

Función en la limpieza de la memoria

Cuando hay presión, el núcleo debe liberar memoria RAM, y es precisamente aquí donde vm.vfs_cache_pressure define el equilibrio entre Caché VFS, la caché de páginas y la memoria de procesos. Los valores bajos mantienen las entradas de directorios e inodos en la memoria durante más tiempo, lo que agiliza las consultas a los directorios y las aperturas repetidas de archivos. Los valores altos liberan memoria antes y proporcionan más espacio para los procesos o para la caché de páginas, lo que puede resultar útil cuando la RAM es escasa. En este sentido, presto especial atención a las latencias de E/S, ya que una caché de metadatos demasiado vacía ralentiza la búsqueda de archivos. Esta información me resulta útil para la interacción con las estrategias de liberación de la caché de páginas, ya que me proporciona una visión sobre Eliminación de la caché de páginas valiosas referencias prácticas que me permitan tomar decisiones basadas en datos.

Metodología de medición: hacer que la caché VFS sea transparente

Antes de hacer cambios, lo pongo a la vista, donde la memoria está y qué se desplaza. Así puedo determinar si los metadatos son realmente el cuello de botella, o si predominan la caché de página, los procesos o las páginas sucias.

• /proc/meminfo: Analizo InodeCache, Cached, Buffers, SReclaimable y SUnreclaim para evaluar su proporción y recuperabilidad.
• losa: Vista en tiempo real de los «slabs», en concreto de «dentry», «inode_cache», «ext4_inode_cache» y «xfs_inode». Así puedo ver si los «dentries» y los «inodes» aumentan o disminuyen.
• Ruta de E/S: Con vmstat/iostat compruebo las latencias de lectura y si aumentan los accesos al disco durante las búsquedas.

# Resumen rápido
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Distribución de slabs (ordenada por tamaño)
sudo slabtop -s c

# Filtrar solo los slabs de tipo dentry/inode
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# Tendencias de E/S y memoria cada segundo
vmstat 1
iostat -x 1

Creo que la interpretación es clara: si SReclaimable crece junto con los bloques de dentry/inode y, al mismo tiempo, aumentan las latencias de E/S no, lo que confirma que la caché de metadatos funciona correctamente. Si estos valores suelen caer a cero y se disparan rápidamente al acceder al directorio, es probable que vm.vfs_cache_pressure sea demasiado agresivo.

Ejemplo práctico: leer y modificar el valor actual

La comprobación se realiza desde la línea de comandos en cuestión de segundos y sin Reinicie. 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ón, introduzco entradas en /etc/sysctl.conf o en un archivo de /etc/sysctl.d/, las recargo y anoto el cambio en mi documentación. Pruebo cada nivel bajo una carga realista, no solo en reposo, para que los efectos sean visibles. De este modo, garantizo comparaciones claras «antes y después» y evalúo el cambio basándome en indicadores cuantificables.

# Comprobar el valor actual
cat /proc/sys/vm/vfs_cache_pressure
# o bien
sysctl vm.vfs_cache_pressure

# Probar temporalmente (hasta el reinicio)
sudo sysctl -w vm.vfs_cache_pressure=60
# Alternativamente
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# Configurar de forma permanente
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Optimización de la caché en Linux: casos prácticos

En plataformas de alojamiento con muchos recursos estáticos, repositorios de archivos o aplicaciones con su propio búfer, conviene realizar una ponderación de la caché VFS. Los servidores web con numerosos archivos pequeños se benefician enormemente de valores más bajos, ya que las búsquedas en el SSD/HDD son menos frecuentes. Los servidores de archivos con tamaños 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é de base de datos grande prefieren valores más altos, para que los procesos dispongan de espacio suficiente. Evalúo estos patrones en cada caso con datos de monitorización, para que la configuración se adapte a la combinación real de accesos.

Servidor web con muchos archivos estáticos

En el caso de CSS, JS e imágenes, prefiero conservar los metadatos durante más tiempo en el Cache. Los valores entre 50 y 80 suelen dar buenos resultados, ya que la reapertura de archivos se realiza más rápido. Analizo minuciosamente los picos de E/S durante los picos de tráfico y comparo los tiempos de respuesta antes y después del cambio. Si las latencias se mantienen estables y se reducen los costes de búsqueda 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é de metadatos más grande.

Servidores de archivos o sistemas NAS

Las numerosas conexiones de usuarios y los cambios de directorio se benefician de más bajo hasta alcanzar unos valores equilibrados. Si hay suficiente RAM, tiendo a situarme entre 50 y 80; si la memoria es más escasa, me mantengo más cerca de 100. Compruebo que los listados de directorios sigan siendo fluidos y que las instantáneas y copias de seguridad no desplacen en exceso las cachés. Si la latencia de E/S aumenta en los picos, la ajusto con cuidado al alza. Así mantengo el equilibrio entre comodidad y memoria libre.

Servidores de bases de datos y sistemas con poca memoria

Las bases de datos mantienen su propia caché de búfer, por lo que le asigno al Memoria de proceso Suele tener prioridad. Los valores entre 120 y 200 indican que es mejor vaciar las cachés VFS y liberar memoria RAM. Para ello, presto atención a las latencias de las consultas y a los patrones de fallos de página de la aplicación. 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.

Ejemplos de cargas de trabajo y valores orientativos

Empiezo con 100 y voy reduciendo en incrementos de 20 para valores cercanos a los de la web Cargas de trabajo 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é y la actividad de intercambio. Quien quiera profundizar más, encontrará en el compacto Optimizador de rendimiento de la caché de páginas Información complementaria sobre las estrategias de caché de archivos que tengo en cuenta paralelamente. Cuando los valores medidos coinciden con los objetivos, congelo la configuración y documento los indicadores clave. De este modo, la optimización sigue siendo reproducible y puedo realizar ajustes posteriores con rapidez.

Riesgos y dificultades

Si establezco un valor demasiado bajo, el núcleo apenas podrá liberar entradas del VFS, lo que en momentos de pico puede provocar OOM‑Esto conlleva riesgos. Si lo elevo demasiado, aumenta la latencia en las búsquedas 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óneas a partir de intervalos de tiempo de poca actividad. Los cambios bruscos dificultan la evaluación, por lo que procedo de forma gradual. Anoto cada modificación con la hora, el perfil de carga y los valores medidos, para que las causas queden claras.

Seguimiento e indicadores

Los datos concretos revelan si merece la pena realizar un ajuste Métricas. Superviso el uso de la RAM, la distribución entre cachés y procesos, las latencias de E/S y la actividad del swap. Además, evalúo las tasas de aciertos de caché y las tendencias de fallos de página para detectar rápidamente los efectos secundarios. Especialmente con muchos archivos pequeños, 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.

Guía de ajuste: de la hipótesis al ajuste fiable

La estructura evita actuar a ciegas. Sigo un procedimiento fijo para que los resultados sean fiables y mis compañeros de equipo puedan comprender los pasos que sigo.

1. Registrar los datos de referencia: 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, «CPU steal», actividad de intercambio, tamaño de inodo/dentry).
2. Formular una hipótesis: „Muchos archivos pequeños, las consultas son costosas: unos valores más bajos aceleran el proceso“ o „La memoria RAM escasea: unos valores más altos mantienen los procesos sin obstrucciones“.
3. Modificar paso a paso: de ±20 a ±40 puntos. Mide al menos una fase de pico por nivel.
4. Comparar: Compruebo si los SLO (por ejemplo, el percentil 95) mejoran de forma fiable, sin Ya no se producen eventos de swap ni de OOM.
5. Criterio de reversión: Si aumentan las latencias 95./99., se alargan los tiempos de espera de E/S o se acumulan los fallos de caché, doy un paso atrás.
6. Freeze y documentación: Anotar el valor final, la fecha, la ventana de carga y los indicadores.

# Prueba rápida para ventanas de medición controladas (¡solo mantenimiento!)
# Antes: capturar instantáneas de los indicadores clave
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Prueba de carga/esperar a que se alcance el pico, luego volver a registrar las métricas y compararlas

Sistemas de archivos y opciones de montaje: el contexto es importante

El efecto de vm.vfs_cache_pressure también depende del sistema de archivos y de las opciones de montaje. Yo evalúo estos factores de la siguiente manera:

• relatiempo/notiempo: Evita las frecuentes operaciones de escritura de «atime». «noatime» reduce la carga de E/S cuando hay muchas lecturas, lo que hace que las ventajas de los metadatos sean más evidentes.
• lazytime: Retrasa las actualizaciones de metadatos en la RAM; esto suaviza los picos, pero interfiere con los momentos de vaciado.
• ext4 frente a XFS frente a Btrfs: Diferentes estructuras de inodos y comportamientos del «shrinker». Siempre mido en el FS de destino, en lugar de trasladar suposiciones.
• NFS/Sistema de archivos en red: El almacenamiento en caché y la invalidación de atributos pueden limitar las ventajas del VFS. Una liberación agresiva (valores altos) aumenta entonces el número de consultas remotas.
• OverlayFS/FUSE: Muchas operaciones pequeñas relacionadas con los metadatos se benefician enormemente de la caché VFS; yo mantengo los valores entre moderados y bajos, siempre que haya memoria RAM disponible.

Aspectos relacionados con los contenedores y los cgroups

En entornos de contenedores, tengo presente que vm.vfs_cache_pressure es un en todo el servidor Botón. Los cambios afectan a todos Pods/contenedores en el nodo. Por eso, opto por un enfoque conservador y coordino el ajuste a nivel de nodo.

• Límites de almacenamiento: Los cgroups de memoria limitan la memoria de proceso y la caché de páginas; la memoria slab puede contabilizarse proporcionalmente. Observo que los eventos Pod-OOM y Node-Pressure están relacionados.
• Combinación de cargas de trabajo: 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.
• Despliegue: Primero en Canaries (un nodo) y, a continuación, se implementa de forma escalonada. Documento los cambios en la línea base de Node (sysctl.d) y anoto las implementaciones afectadas.

Casos especiales de la práctica

Algunos patrones se pueden abordar de forma específica si conozco las causas:

• Tareas de CI/Build: Los accesos frecuentes a archivos y los escaneos de directorios se benefician de valores más bajos. Los vuelvo a aumentar una vez finalizado el trabajo, en caso de que se utilicen nodos de forma mixta.
• Ventana de copia de seguridad/escaneo: Las operaciones prolongadas en los directorios borran las cachés. De forma temporal, se puede más alto Valor (por ejemplo, 180) para evitar que los dentries/inodes llenen la RAM durante la copia de seguridad; después lo vuelvo a poner como estaba.
• Entradas negativas: Los archivos que no existen (404) también se almacenan en caché. Las cargas de trabajo web con accesos fallidos frecuentes mejoran de forma apreciable si la caché VFS no se vacía de forma demasiado agresiva.
• Transmisión en continuo/E/S secuencial: Aquí predomina la caché de páginas; unos valores demasiado bajos no aportan mucho y consumen RAM innecesariamente. Yo me mantengo cerca del 100 o un poco por encima.

# Ejemplo: ser un poco más agresivo durante una copia de seguridad completa
sudo sysctl -w vm.vfs_cache_pressure=180
# Tras la copia de seguridad, volver al valor óptimo determinado anteriormente
sudo sysctl -w vm.vfs_cache_pressure=60

Automatización y gobernanza

Tras unas pruebas satisfactorias, incorporo la configuración a mis compilaciones estándar. Es importante que los equipos sepan que, por qué se haya seleccionado un valor y cuando que debe comprobarse (por ejemplo, tras cambios de versión o de carga de trabajo).

• Gestión de la configuración: Suelo definir valores predeterminados para cada función (web, base de datos, servidor de archivos) en /etc/sysctl.d/ y los distribuyo de forma centralizada.
• Control de derrape: Las auditorías periódicas comprueban si los valores en tiempo real y el repositorio coinciden.
• Runbooks: Documento los pasos de medición, los valores límite para la reversión y los procedimientos de emergencia (por ejemplo, restablecimiento a 100).

# Función: servidor web (ejemplo)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure y otros parámetros del núcleo

Un buen resultado solo se consigue en combinación con vm.swappiness y los umbrales de páginas sucias. Un valor más bajo de «swappiness» (por ejemplo, entre 10 y 20) tiende a mantener los procesos en la RAM y evita el traspaso innecesario a la memoria de paginación. Con vm.dirty_background_ratio y vm.dirty_ratio regulo la rapidez con la que el sistema escribe las páginas modificadas, para que los picos de escritura no lo bloqueen todo. Ajusto estos valores de manera que las búsquedas de metadatos sigan siendo rápidas y las operaciones de escritura se desarrollen de forma planificada. Para ello, utilizo esta concisa visión general sobre la interacción de las cachés de archivos: Resumen del almacenamiento en caché del sistema de archivos.

Recomendaciones sobre entornos de alojamiento y WordPress

Muchos temas, plugins y archivos multimedia generan innumerables archivos pequeños, por lo que es necesario un potente Caché VFS 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 «CPU-Steal». 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ñas. Si las latencias disminuyen sin que se active el swap ni el OOM-Killer, consolido la configuración de forma permanente. Al mismo tiempo, vigilo la caché de páginas para que ambas cachés se complementen de forma óptima.

Resumen

Con vm.vfs_cache_pressure controlo la Saldo de forma muy específica, en función de las búsquedas rápidas 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ón sobre latencias de E/S, aciertos de caché y actividad de swap. En combinación con vm.swappiness y los parámetros «dirty», consigo una gestión de la memoria estable. De este modo, aprovecho de forma eficiente la caché del sistema de archivos de Linux y mantengo los tiempos de respuesta bajos de forma fiable incluso bajo carga.