El comando echo 3 > /proc/sys/vm/drop_caches es una herramienta de administración avanzada que sirve para liberar la memoria RAM que el kernel tiene ocupada como caché, sin reiniciar el sistema. Antes de lanzarlo a ciegas conviene entender qué está pasando realmente bajo el capó, porque su efecto es mucho más sutil de lo que parece.
1. ¿Qué hace exactamente este comando?
En Linux, la RAM libre es RAM desperdiciada. El kernel aprovecha cualquier hueco disponible para guardar en caché datos del disco: archivos leídos hace poco, metadatos, inodes, dentries. Esto vuelve al sistema ágil, porque leer de RAM es varios órdenes de magnitud más rápido que leer del disco.
Cuando ejecutas el comando como root, le estás dando una orden directa al subsistema de gestión de memoria virtual (vm): “vacía ya mismo las cachés que no estén en uso activo”. El número 3 indica el nivel de limpieza que aplicas. Es el más agresivo: vacía absolutamente todo lo que se pueda vaciar de forma segura.
2. Los valores que acepta drop_caches
El archivo /proc/sys/vm/drop_caches admite tres valores numéricos (1, 2 o 3). Cada uno apunta a una estructura de memoria distinta:
| Valor | Qué libera | Descripción técnica |
|---|---|---|
| 1 | Page Cache (caché de páginas) | “Libera las páginas con el contenido de los archivos leídos del disco. Suele ser el que más RAM recupera, sobre todo si acabas de mover archivos grandes.” |
| 2 | Dentries e Inodes | Libera los metadatos del sistema de archivos. Los inodes guardan atributos del archivo (permisos, tamaño, timestamps) y los dentries la estructura de rutas de los directorios. |
| 3 | Page Cache + Dentries + Inodes | La combinación de los dos anteriores (1 + 2). Es la limpieza total. |
3. ¿A qué afecta y a qué no?
Este comando no es destructivo con tus datos, pero sí altera temporalmente el rendimiento del sistema. La clave está en cómo gestiona el kernel las páginas.
El mecanismo de seguridad: clean pages vs. dirty pages
El kernel hace una cosa importante: solo borra las “páginas limpias” (clean pages). Si un proceso modificó un archivo en RAM y esos cambios todavía no se han escrito en disco, esa página se considera “sucia” (dirty page). drop_caches la ignora por completo, porque borrarla significaría perder datos.
Por eso, la forma correcta de usarlo es siempre con un sync delante. El sync obliga al kernel a vaciar las páginas sucias al disco, y así la limpieza posterior con 3 puede llegar lo más lejos posible:
sync && echo 3 > /proc/sys/vm/drop_cachesSi te saltas el sync, el comando funcionará, pero dejará en RAM justo las páginas que más recursos estaban consumiendo.
4. Pros y contras
Ejecutarlo provoca un “reset” en la optimización de memoria del sistema, y las consecuencias son bastante claras.
Por qué a veces se hace
- Recuperación visible de RAM: tras ejecutarlo,
free -mmuestra la columna de disponible/libre disparada y la debuff/cachedesplomada. Es tranquilizador a la vista, aunque no siempre significa lo que parece. - Bloques contiguos de memoria: puede ayudar a desfragmentar la memoria del kernel cuando necesitas asignar bloques físicos grandes de golpe (por ejemplo, para ciertas bases de datos o máquinas virtuales).
- Benchmarking honesto: este es, con diferencia, su uso legítimo. Si vas a medir cuánto tarda tu aplicación en leer un archivo del disco, necesitas la caché fuera para que la RAM no falsee la prueba.
Por qué no deberías automatizarlo
- Cache miss inmediato: justo después de ejecutarlo, el sistema se vuelve notablemente más lento. La próxima vez que un proceso pida un archivo, el kernel no lo encuentra en RAM y tiene que ir a buscarlo al disco, que es miles de veces más lento.
- Pico de I/O: se genera un cuello de botella temporal en disco mientras el sistema reconstruye la caché con los archivos de uso frecuente.
- No sirve si lo que falta es RAM de verdad: si tu sistema se ahoga porque Chrome, un IDE o una base de datos están consumiendo toda la memoria en espacio de usuario (anonymous memory), este comando no toca esa memoria. Además, Linux rellenará la caché automáticamente en cuanto haya algo de actividad.
5. El efecto a corto plazo que sí es real (y por qué engaña)
Cuando la RAM se llena, Linux entra en un estado de estrés que se llama memory pressure. En ese escenario pasan dos cosas que ralentizan la máquina, y drop_caches actúa directamente sobre ambas.
5.1. Reduces el thrashing de disco
Sin RAM libre, el kernel tiene que decidir constantemente qué sacar para dárselo a la aplicación que estás usando. Tiene dos opciones:
- Mover memoria de procesos a la Swap (el disco).
- Borrar páginas de la caché de archivos (lo que hace el comando).
Si el kernel se decanta por la Swap, el sistema se congela o se arrastra, porque escribir y leer Swap es lentísimo. Al lanzar echo 3 > ..., le estás diciendo al kernel: “olvídate de la Swap, borra la caché de archivos ya”. Creas un hueco enorme en RAM de golpe, el kernel deja de buscar espacio a tientas y la máquina se destraba unos minutos. Ese es el efecto que notas.
5.2. Duermes al kswapd
Con la RAM al 99%, un hilo del kernel llamado kswapd trabaja a tope escaneando memoria para decidir qué liberar. Eso consume CPU. Al vaciar la caché de golpe, kswapd ve de repente un montón de RAM libre y se va a dormir. Al bajar su consumo de CPU, el entorno de escritorio (GNOME, KDE, lo que uses) responde más ágil.
El precio oculto
Esa mejoría es real, pero tiene letra pequeña:
- Dura pocos minutos: si la falta de memoria viene de procesos pesados (Chrome con decenas de pestañas, un IDE, un juego, una JVM con heap grande), esa memoria es anonymous memory. El comando no la toca. Solo borró caché de archivos.
- Efecto rebote: la RAM queda libre, sí, pero vacía de cualquier optimización. En cuanto abras un menú, busques un archivo o cualquier cosa fuerce una lectura de disco, notarás un tirón: el kernel tiene que reconstruir la caché desde cero leyendo del disco físico.
El OOM Killer, el verdadero final de la película
Cuando un Linux “se cuelga” por falta de memoria, no es un cuelgue aleatorio. El sistema entra en thrashing total (el disco se satura con el tráfico de Swap) hasta que entra en escena el OOM Killer (Out Of Memory Killer), el mecanismo del kernel que mata procesos a la fuerza cuando ya no queda nada que liberar. Usar echo 3 retrasa la llegada del OOM Killer unos minutos, pero si la aplicación que está causando el problema sigue chupando memoria, el final será el mismo.
6. Soluciones de verdad para la falta de RAM
Si tu máquina se queda sin memoria a menudo, drop_caches es como achicar agua con un cubo en un barco que tiene una vía abierta. Mejor ataca la causa con dos herramientas nativas de Linux.
6.1. Activa o ajusta ZRAM
En lugar de una Swap tradicional en disco, ZRAM crea un espacio de intercambio comprimido dentro de la propia RAM. Cuando el sistema se queda sin memoria, en vez de congelarse escribiendo en disco, comprime los datos en RAM con algoritmos como LZO o ZSTD, que son absurdamente rápidos.
El resultado es que tu RAM rinde de forma efectiva hasta un 50% más y el PC deja de dar tirones. Es lo que usan por defecto Fedora, Android y ChromeOS precisamente por eso.
6.2. Ajusta el swappiness
El valor de swappiness le dice al kernel qué tan agresivo debe ser mandando datos a la Swap. Por defecto suele estar en 60. Si tienes poca RAM, bajarlo a 10 o 20 hace que el kernel intente mantener las cosas en RAM el mayor tiempo posible y recurra a la caché de archivos de forma más eficiente.
Puedes consultar tu valor actual con:
cat /proc/sys/vm/swappinessEn resumen, echo 3 > /proc/sys/vm/drop_caches sí te da un pico de rendimiento temporal, porque le quita trabajo de gestión al kernel y libera CPU. Pero es un analgésico, no la cura. Si cada semana tienes que recurrir a él, el problema está en otro sitio: o las aplicaciones que usas piden más memoria de la que tienes, o tu Swap/ZRAM no están bien configurados. Arregla eso y el comando desaparecerá de tu lista de favoritos.