El comando free -h y, dentro de él, la columna available son la referencia para comprobar cuánta memoria RAM queda realmente disponible en un sistema Linux. La cifra que marca la columna free, en cambio, no sirve para valorar si el equipo anda apurado de memoria: suele aparecer baja porque el núcleo reserva la RAM sobrante como caché de disco, no porque falte memoria de verdad.
El malentendido es antiguo y nace de cómo gestiona la memoria el núcleo de Linux. Tal y como sabemos ahora sobre el uso de memoria RAM en Linux, el sistema aprovecha la RAM sobrante para guardar en caché archivos de disco, lo que acelera las siguientes lecturas y hace que la columna free baje con el tiempo de uso. Esa caché no es un derroche: se libera sola en cuanto un programa necesita el espacio.
Por qué parece que Linux se come la RAM
La frase «Linux se come la RAM» nace de ver la columna free casi vacía en free -h o en cualquier monitor gráfico. En realidad esa memoria libre no estaba haciendo nada: el núcleo prefiere llenarla con caché de páginas antes que dejarla ociosa, porque una RAM vacía no acelera absolutamente nada.
Cada vez que se abre un archivo, Linux guarda una copia en memoria. Si se vuelve a acceder a él poco después, se carga desde la RAM en lugar del disco y el proceso resulta mucho más rápido. Esa caché no tiene dueño fijo: en el momento en que una aplicación pide memoria, el núcleo la cede sin que el usuario tenga que intervenir. Por eso la cifra que conviene vigilar no es free, sino available: la suma de lo que está realmente libre más la parte de la caché que se puede recuperar al instante.
Qué dice cada columna de free -h (y cuál mirar)
Al ejecutar free -h en la terminal, el sistema devuelve varias columnas con el estado de la memoria y la swap. La opción -h muestra las cifras en unidades legibles, calculadas en gibibytes (potencias de 1024), así que un equipo con 64 GB de RAM física puede aparecer como 61Gi.
En un portátil con CachyOS, procps-ng 4.0.7 y systemd 262, free -h devolvió estos valores: 61Gi de memoria total, 19Gi usados, 22Gi libres, 1,7Gi compartidos, 22Gi en buff/cache y 42Gi disponibles; la swap marcó 93Gi totales, con 4,0Gi usados y 89Gi libres. La diferencia entre los 22Gi «libres» y los 42Gi «disponibles» es, casi en su totalidad, caché recuperable: hay memoria de sobra para abrir más programas sin tocar la swap, aunque la columna free parezca escasa.
La columna available no es la suma directa de free y buff/cache: una parte de la caché, como la memoria compartida o los archivos guardados en tmpfs, no se puede liberar sin más, así que el cálculo del núcleo es algo más conservador. Además, en las versiones recientes de free, used se obtiene restando available de total, de modo que las columnas no siempre cuadran a la perfección si se suman a mano.
El comando admite algunas variantes útiles según lo que se quiera consultar:
free -h --si: cambia las unidades a potencias de 1000 en lugar de 1024.free -h -w: separa buffers y caché en dos columnas distintas.free -h -t: añade una fila con el total de RAM y swap sumadas.free -h -s 2 -c 5: repite la salida cada 2 segundos, cinco veces.free -h -L: condensa toda la información en una sola línea.
Quién está usando la memoria: top, htop y btop
Si free indica que la memoria se ha estrechado, el siguiente paso es averiguar qué proceso la está acaparando. Para eso sirven los monitores interactivos: top viene preinstalado en casi cualquier distribución, mientras que htop y btop ofrecen una interfaz más visual, con colores y gráficas.
En top basta pulsar la tecla M (mayúscula) para ordenar los procesos por consumo de memoria; resulta más útil fijarse en la columna RES, que refleja la memoria física real usada, y no en VIRT, que incluye memoria virtual reservada y suele dar cifras engañosas. htop añade una vista en árbol con la tecla F5, práctica para identificar navegadores que abren decenas de subprocesos, y btop suma gráficas históricas que ayudan a detectar picos de consumo repentinos. Para una lista rápida sin abrir ningún monitor, ps aux --sort=-%mem | head devuelve los procesos que más memoria ocupan en ese instante.
Cómo detectar una falta real de memoria con vmstat
Una ralentización repentina o que las aplicaciones se cierren sin aviso son la señal para comprobar si hay una presión de memoria real. El comando vmstat 1 muestra el movimiento de la memoria segundo a segundo y repite la lectura de forma indefinida hasta que se interrumpe con Ctrl+C, lo que permite ver la tendencia en lugar de una sola fotografía puntual. Las columnas que delatan un problema son si y so.
Si esas dos columnas, si (swap in) y so (swap out), muestran valores altos de forma sostenida, el sistema está moviendo datos constantemente entre la RAM y el disco, lo que se conoce como thrashing y provoca lentitud extrema. Para confirmar si el núcleo ha tenido que cerrar procesos por falta de memoria, basta con revisar los registros con journalctl -k buscando menciones al OOM killer (Out Of Memory), el mecanismo que mata procesos cuando la memoria se agota del todo. Conviene cruzar estos datos con la columna available de free -h: si esta se mantiene amplia mientras si y so permanecen en cero, la lentitud tiene otro origen.
Qué módulos de memoria lleva instalados el equipo
free, top o htop explican cómo se está usando la memoria en cada momento, pero ninguno de los tres dice nada sobre el hardware físico instalado. Para ver qué módulos de RAM lleva puestos la placa base, el comando es sudo dmidecode -t memory, que exige permisos de administrador porque accede directamente a la tabla SMBIOS/DMI del sistema.
dmidecode -t memory vuelca el tamaño, el tipo (DDR4, DDR5), la velocidad y el fabricante de cada módulo instalado, ranura por ranura. Es la herramienta a la que recurrir antes de ampliar la memoria, para comprobar si queda algún hueco libre o si hay que sustituir los módulos existentes por otros de mayor capacidad y la misma velocidad, algo que ningún comando de monitorización de uso puede indicar. Una alternativa que ofrece una vista parecida es sudo lshw -class memory, que también requiere permisos de administrador y organiza la información por ranura. Conocer estos datos antes de comprar evita adquirir módulos con una velocidad o un tipo de memoria incompatibles con los que ya lleva instalada la placa base.
¿Hay que vaciar la caché de memoria a mano?
Existe la tentación de forzar la liberación de la caché para «limpiar» el sistema, pero no es buena idea en un uso normal. Vaciar la caché obliga al disco a volver a cargar los mismos datos que ya estaban en RAM, lo que empeora el rendimiento justo después de hacerlo.
Solo tiene sentido recurrir a esto en pruebas de rendimiento o diagnósticos muy concretos, y siempre requiere permisos de administrador porque implica escribir en archivos del sistema. La gestión automática del núcleo ya está pensada para mantener la caché llena hasta el último momento posible; interferir manualmente suele jugar en contra de la fluidez del escritorio, no a favor.
La próxima vez que free -h devuelva una cifra de free ajustada, la comprobación sigue siendo la misma: mirar available. Si esa columna se mantiene con varios gigabytes de margen, el sistema tiene recursos de sobra, aunque la memoria «libre» parezca haberse esfumado.