Gestión de memoria en Linux: guía completa y optimización

Informatec Digital » Recursos » Gestión de memoria en Linux: guía completa y optimización

Cuando trabajamos con servidores o equipos de escritorio basados en Linux, la gestión de memoria es uno de los pilares que marcan la diferencia entre un sistema ágil y uno que se arrastra. Ya sea Debian, Ubuntu, AlmaLinux, CentOS o cualquier otra distribución, entender cómo maneja Linux la RAM, la swap y el resto de mecanismos internos es clave para evitar cuelgues, pérdidas de rendimiento o problemas de estabilidad.

Además, en entornos modernos donde corren bases de datos exigentes, contenedores, escritorios completos y aplicaciones pesadas, no basta con “tener mucha RAM”: es fundamental saber cómo Linux usa la memoria, qué significan realmente los indicadores que vemos en herramientas como top, htop, free o vmstat, y qué opciones tenemos para afinar el comportamiento del kernel, la swap, cgroups o mecanismos como zram, zswap, EarlyOOM o systemd-oomd.

Fundamentos de la memoria en Linux

Linux está diseñado para aprovechar al máximo la memoria disponible, de forma que la RAM casi nunca aparezca “vacía”, porque el kernel la utiliza como caché de disco, buffers y almacenamiento temporal para acelerar el acceso a datos y aplicaciones. Esto genera muchos malentendidos: ver poca memoria “libre” no es sinónimo de problema, sino más bien de que el sistema está trabajando de forma eficiente.

La cantidad total de memoria que puede gestionar un equipo depende de la arquitectura del sistema operativo. Un sistema de 32 bits suele limitarse a unos 4 GB de memoria direccionable, mientras que uno de 64 bits puede manejar fácilmente decenas o cientos de gigas. A nivel teórico, la arquitectura de 64 bits permite llegar a cifras enormes (del orden de exabytes), aunque en la práctica el límite real lo imponen el hardware y el kernel utilizados.

Linux combina segmentación y paginación para organizar la memoria. La memoria se divide en páginas de tamaño fijo (típicamente 4 KiB, que se puede consultar con getconf PAGESIZE) y el kernel maneja estructuras internas llamadas tablas de páginas para traducir direcciones virtuales a direcciones físicas, aplicar permisos y controlar el estado de cada página.

La memoria física, es decir, la RAM instalada en el equipo, es un recurso caro pero extremadamente rápido. Linux la usa tanto para los procesos en ejecución como para cachés de datos, memoria compartida, buffers de E/S y estructuras internas del kernel. Cuando los procesos no llenan toda la RAM, el sistema rellena el hueco con caché de disco para acelerar el acceso a ficheros y dispositivos de almacenamiento más lentos.

Como la RAM es limitada, Linux recurre a mecanismos de memoria virtual y swap para ampliar de forma lógica el espacio disponible, permitiendo que los procesos vean un espacio de direcciones grande y continuo, aunque por debajo se estén reutilizando y moviendo páginas entre RAM y almacenamiento secundario.

Memoria virtual, física, swap y disco

En Linux se habla muchas veces de “memoria virtual” para referirse al espacio de memoria visible para cada proceso. Cada programa ve un espacio de direcciones propio, aislado y protegido, gracias a la combinación de la MMU del procesador y las tablas de páginas del kernel. Ese espacio es mucho mayor que la RAM disponible y se apoya tanto en memoria física como en swap y archivos mapeados.

La memoria física (RAM) es donde realmente residen las páginas que están en uso activo. Es crucial disponer de suficiente RAM para las cargas habituales. Por ejemplo, un servidor con bases de datos como MongoDB necesita que la memoria física supere la que requiere el motor de base de datos y el resto de servicios, porque si MongoDB se ve obligado a utilizar swap de forma intensiva, el rendimiento se desploma: el acceso a RAM se mide en nanosegundos, mientras que la swap en disco trabaja en milisegundos.

La memoria de intercambio, o swap, actúa como extensión más lenta de la RAM. Cuando la memoria física se satura, Linux puede mover páginas poco utilizadas al espacio de swap, que puede ser una partición dedicada o un archivo dentro de un sistema de ficheros. Ambos enfoques son válidos; la elección depende de la política de administración, facilidad de gestión y necesidades de hibernación.

Es importante desmitificar la swap: no es “la mala de la película”. No es, por sí sola, sinónimo de sistema lento, ni es un recurso que solo deba usarse “cuando todo se hunde”. Bien configurada, la swap permite liberar RAM de páginas anónimas inactivas (por ejemplo, partes de la memoria de procesos que no se usan desde hace mucho), dejando espacio disponible para cargas nuevas que sí necesitan velocidad.

Además de RAM y swap, entran en juego los dispositivos de almacenamiento. La memoria de disco almacena datos persistentes que sobreviven a reinicios y cortes de energía. Mientras el equipo está encendido, gran parte de esos datos se mantienen en caché en RAM (page cache), y el kernel decide qué páginas mantener y cuáles expulsar en función de heurísticas de uso reciente, con el objetivo de minimizar accesos costosos al disco.

Cómo fluye la utilización de memoria en Linux

El flujo típico de datos en un sistema Linux pasa por varios componentes: el usuario o las aplicaciones generan peticiones que el sistema traduce en accesos a memoria y disco. Los datos leídos de almacenamiento se cargan primero en RAM, donde pueden permanecer en la caché de página. Cuando se vuelven a solicitar, el kernel comprueba si ya están cacheados, evitando así un nuevo acceso al disco.

En ese proceso intervienen también la CPU y la MMU. La CPU opera sobre direcciones virtuales y, mediante las tablas de páginas, el hardware traduce cada acceso a una dirección física en RAM o lo resuelve mediante mecanismos de fallo de página si no está cargado. Si los datos deben persistir, se escriben en disco, pero mientras se trabaja con ellos se prioriza mantenerlos en memoria rápida para ganar rendimiento.

Cuando la RAM empieza a escasear, el kernel entra en juego con sus algoritmos de reclamación de memoria: libera caché de página menos usada, compacta zonas de memoria, recurre a la swap para páginas de menor prioridad y, si la situación se vuelve crítica, puede tomar medidas más drásticas como activar el OOM-killer.

Mapa de memoria de un proceso en Linux

Cada proceso que se ejecuta en Linux tiene un mapa de memoria o memory layout que define cómo se organiza su espacio de direcciones: dónde se ubica el código ejecutable, las variables globales, el heap, la pila, los argumentos de línea de comandos, las variables de entorno y los mapeos de archivos o librerías compartidas.

Ese mapa suele dividirse en varios segmentos bien diferenciados. En la parte baja del espacio virtual encontramos el segmento de texto (el código binario del programa), después los segmentos de datos inicializados y no inicializados (BSS), más arriba el heap donde se alojan las asignaciones dinámicas, y en la zona alta la pila del proceso. Los argumentos y el entorno se sitúan también en la zona superior del espacio de direcciones.

El segmento de texto contiene las instrucciones ejecutables del programa y de las librerías compartidas. Normalmente es de solo lectura y puede ser compartido por múltiples procesos que ejecuten el mismo binario, lo que ahorra memoria física. Cualquier intento de escribir en esa región provoca una violación de segmento.

El segmento de datos inicializados almacena las variables globales y estáticas que tienen un valor distinto de cero al inicio. Este segmento puede dividirse conceptualmente en una parte de solo lectura y otra de lectura-escritura, según el tipo de datos. El segmento BSS, en cambio, agrupa las variables globales o estáticas que no tienen un valor explícito en el código o que se inicializan a cero.

El heap es la región que se utiliza para la memoria dinámica gestionada por llamadas como malloc, calloc o realloc. Cuando el programa solicita memoria, el gestor de memoria de usuario la toma del heap; cuando la libera con free, se devuelve al heap pero no necesariamente al sistema operativo, lo que puede producir fragmentación interna. La pila (stack) se reserva para variables locales de funciones, direcciones de retorno y parámetros, y crece o decrece con cada llamada y retorno de función.

Si queremos inspeccionar el mapa de memoria de un proceso en ejecución, herramientas como pmap son muy útiles. Con pmap <PID> podemos ver las distintas regiones mapeadas, su tamaño, permisos, si son anónimas o asociadas a ficheros, así como el tamaño residente (RSS) en RAM y otras métricas que ayudan a comprender el consumo real de memoria de una aplicación.

Conceptos clave: páginas, fallos de página y caché

La unidad mínima de gestión de memoria en Linux es la página de memoria, típicamente de 4 KiB, aunque también existen páginas grandes (huge pages) para determinadas cargas. Todas las decisiones del kernel sobre qué mover, liberar o cachear se toman a nivel de páginas, no de bytes individuales.

Las tablas de páginas (page tables) son estructuras jerárquicas mantenidas por el kernel que indican cómo se traducen las direcciones virtuales a físicas. Cada entrada puede incluir información sobre permisos de lectura, escritura y ejecución, estado de la página (presente en memoria, en swap, sucia, compartida, etc.) y otros metadatos que la MMU utiliza durante la traducción.

Un fallo de página (page fault) se produce cuando un proceso accede a una dirección virtual válida, pero la página correspondiente no está lista para ser usada: puede no haber sido asignada aún, estar en disco o requerir un mapeo inicial. El kernel interviene para localizar o crear esa página. Si la página reside en RAM pero no estaba marcada correctamente, el coste del fallo es bajo; si hay que traerla desde disco (swap o archivo), el coste es mucho más elevado.

La page cache, o caché de páginas de archivos, es uno de los grandes secretos del buen rendimiento de Linux. El kernel guarda en RAM datos y metadatos de ficheros para acelerar lecturas y escrituras, reduciendo drásticamente el número de accesos al disco. Por eso, aunque parezca que la memoria libre es poca, mucha de esa RAM está en realidad disponible: el kernel puede liberar caché rápidamente si las aplicaciones necesitan más espacio.

Dentro del espacio virtual también distinguimos entre memoria de fichero (file memory), vinculada a archivos mapeados (por ejemplo, el código de binarios y librerías o ficheros mapeados explícitamente con mmap), y memoria anónima (anonymous memory), que corresponde al heap, la pila y otros mapeos sin respaldo de archivo. Esta última solo puede volcarse a swap en caso de ser necesario, porque no existe un archivo del que pueda regenerarse.

Presión de memoria, thrashing y OOM

Cuando la cantidad de páginas libres cae por debajo de ciertos umbrales, se dice que el sistema entra en un estado de memory pressure o presión de memoria. En ese escenario, el kernel debe dedicar más tiempo a encontrar páginas que se puedan liberar, compactar o mover a swap, y esto impacta en el rendimiento general.

En servidores web, una presión de memoria elevada puede traducirse en aumento de latencia: los workers deben esperar a que se liberen páginas antes de seguir atendiendo peticiones, y la CPU gasta ciclos en tareas de gestión de memoria en lugar de procesar carga útil. En escritorios, se percibe como tirones, ratón lento, ventanas que no responden e incluso congelaciones breves.

En accesos remotos por SSH, RDP o VNC, esta situación se nota como comandos que “se quedan pensando”, retardos al escribir y, en general, una interacción más torpe. Si además se está usando swap de forma intensiva, puede entrarse en un estado de thrashing, donde el sistema pasa más tiempo moviendo páginas entre RAM y almacenamiento que ejecutando código útil.

El thrashing ocurre cuando la RAM no es suficiente para mantener el conjunto de trabajo activo de los procesos. Con swap habilitada, las páginas anónimas viajan constantemente de la RAM al área de intercambio y viceversa, lo que dispara la E/S de disco. Sin swap, el kernel no tiene dónde volcar esas páginas anónimas, y la única salida posible es matar procesos mediante el OOM-killer.

Incluso si no hay swap, puede haber thrashing con memoria de fichero: páginas pertenecientes a la caché de archivos se expulsan y vuelven a recargarse continuamente desde disco, al ritmo que las aplicaciones las necesitan, generando un bucle de actividad de E/S y lentitud extrema.

Cuando el kernel agota todas sus opciones para conseguir memoria —liberar caché, mover páginas a swap, compactar y aplicar las políticas de cgroups— entra en estado Out-Of-Memory (OOM). En ese momento, el OOM-killer debe seleccionar uno o varios procesos para terminarlos y así recuperar memoria y salvar el resto del sistema.

Para escoger qué proceso matar, el kernel calcula un oom_score para cada PID, basado en factores como la cantidad de memoria usada, la importancia del proceso y otros parámetros internos. Este comportamiento puede modificarse mediante oom_score_adj, que ajusta el peso de un proceso concreto. Herramientas como choom permiten consultar y cambiar estos valores fácilmente.

Swap: mitos, buenas prácticas y variantes modernas

La swap arrastra una mala fama algo injusta. Muchos usuarios creen que es algo que debe evitarse a toda costa o que solo tiene sentido si la RAM es muy escasa. Sin embargo, en Linux la swap forma parte de la estrategia global de memoria virtual: permite al kernel mover páginas anónimas inactivas fuera de la RAM para dar prioridad a los datos activos y al page cache.

No es correcto pensar en la swap como un “último cartucho” que solo se usa cuando todo va mal. De hecho, incluso en sistemas con mucha RAM, disponer de swap da al kernel más margen para mantener ágil el conjunto de trabajo principal y aprovechar mejor la memoria física. Lo que sí es cierto es que, cuando la actividad sobre la swap es muy alta y sostenida, el rendimiento se resiente notablemente.

A nivel práctico, la vieja regla de que la swap debe ser de 1 a 2 veces la RAM ya no es una ley inamovible. En servidores con cantidades grandes de memoria, es más habitual asignar una swap mucho más pequeña en proporción, o incluso usar swap comprimida en RAM con tecnologías como zram o zswap para mejorar el rendimiento y reducir escrituras en disco.

Un caso de uso adicional de la swap es la hibernación: el sistema puede volcar el contenido de la RAM al área de intercambio y apagarse completamente, para luego restaurar el estado al encender. Esto requiere que el espacio de swap disponible sea al menos tan grande como la memoria que se desea guardar, y es algo que condiciona la elección entre soluciones como zram (que no permite hibernar) y swap en disco tradicional.

En los últimos años también se han reportado comportamientos discutibles del OOM-killer en algunos kernels, donde el sistema se bloquea antes de que el OOM entre en acción. En ciertos casos, activar atajos como Alt+SysRq+F (previa habilitación del parámetro /proc/sys/kernel/sysrq) permite forzar al OOM-killer para recuperar un sistema que parece congelado. Además, daemons como EarlyOOM, nohang o systemd-oomd han surgido precisamente para reaccionar antes de que el kernel llegue a situaciones extremas.

Herramientas para supervisar y gestionar la memoria

Para evitar problemas de memoria es fundamental apoyarse en las herramientas adecuadas. Comandos como free, top, htop, vmstat, ps o sar ofrecen una radiografía muy detallada del estado del sistema, tanto en tiempo real como a lo largo del tiempo.

El comando free muestra rápidamente la cantidad de memoria total, usada, libre, caché y buffers, así como información de swap. Es muy útil para comprobar si realmente falta memoria física o si lo que ocurre es que la mayor parte está en caché y puede reutilizarse sin problema.

El clásico top y su variante mejorada htop permiten ver el consumo de CPU y memoria por proceso, así como la carga del sistema, tiempo de actividad, uso de swap y otros indicadores en tiempo real. htop ofrece una interfaz más amigable, con barras de colores y atajos de teclado para ordenar, filtrar o matar procesos de forma rápida.

El comando vmstat aporta una visión más técnica: estadísticas de memoria, procesos, paginación, interrupciones y planificación de CPU. Es ideal para detectar si hay un exceso de fallos de página, mucha actividad de swap o un patrón de thrashing. Por su parte, ps permite listar procesos con gran detalle, incluyendo columnas de memoria residente (RSS), memoria virtual (VSZ) y otros parámetros que ayudan a localizar aplicaciones que se han “disparado”.

En entornos Debian o AlmaLinux, paquetes como sysstat ofrecen comandos adicionales como sar, que pueden registrar el uso de memoria a lo largo del tiempo. Así es posible correlacionar picos de consumo con tareas programadas, despliegues o eventos concretos y ajustar la configuración del sistema en consecuencia.

Para inspeccionar el mapa de memoria de un proceso concreto, además de pmap, siempre es buena idea explorar el pseudo-sistema de ficheros /proc, donde cada proceso tiene su directorio con información detallada, incluyendo su mapa de memoria en /proc/<PID>/maps y estadísticas en /proc/<PID>/smaps.

Optimización básica: swap, caché y swappiness

Más allá de la teoría, hay varias acciones prácticas sencillas para afinar la gestión de memoria en Linux sin volverse loco. Una de las primeras es revisar el estado de la swap con swapon --show y, si es necesario, crear un archivo de swap en lugar de depender solo de una partición. Esto da flexibilidad para ajustar el tamaño sin tener que reparticionar discos.

El parámetro vm.swappiness controla cuán agresivo es el kernel a la hora de usar swap frente a liberar caché. Un valor alto hace que se utilice swap antes; un valor bajo reserva la swap para casos más extremos, priorizando mantener datos en RAM. Ajustes como swappiness=10 suelen dar buen resultado en muchos entornos de escritorio y servidores ligeros, y se pueden aplicar temporalmente con optimizacion del kernel con sysctl o de forma persistente en /etc/sysctl.conf.

En situaciones muy puntuales donde queremos liberar caché manualmente —por ejemplo, después de una carga intensa de lectura que ya ha terminado— se puede recurrir al ajuste vm.drop_caches. Combinando sync y la escritura de un valor adecuado (1, 2 o 3) en ese parámetro, el kernel descarta ciertas cachés. Eso sí, conviene usarlo con cabeza, porque la caché no es “memoria desperdiciada”, sino una optimización importante.

En distribuciones como Debian y AlmaLinux, es habitual complementar estos ajustes con una buena supervisión de procesos pesados mediante htop o ps, identificando servicios o aplicaciones que se “comen” la memoria y, si es necesario, reconfigurarlos o limitar su consumo.

Crear y ajustar el área de swap es una operación relativamente sencilla: basta con reservar un archivo con fallocate, asignarle permisos correctos, inicializarlo como swap con mkswap y activarlo con swapon. Para que el cambio sea persistente, se añade una entrada adecuada en /etc/fstab indicando que ese archivo se usará como swap en cada arranque.

Técnicas avanzadas: zram, zswap, cgroupv2 y OOM en espacio de usuario

Cuando queremos ir un paso más allá en la optimización, entran en juego mecanismos avanzados como zram, zswap y namespaces y cgroups, además de daemons como EarlyOOM, nohang o systemd-oomd, pensados para sacar el máximo partido a la memoria y mejorar la respuesta del sistema bajo presión.

zram utiliza un módulo del kernel para crear dispositivos de bloque comprimidos en la propia RAM. Sobre esos dispositivos se puede montar una swap, de manera que las páginas se comprimen antes de almacenarse. Esto hace que, en la práctica, cunda más la memoria disponible a costa de algo de CPU para la compresión, y elimina la necesidad de escribir en disco, aunque sacrifica la posibilidad de hibernar.

zswap, por su parte, actúa como una caché comprimida frente al espacio de swap real en disco. Las páginas que se van a intercambiar se almacenan inicialmente comprimidas en RAM, y solo cuando esa caché se llena o se decide expulsarlas, se escriben en la swap tradicional. Esto reduce la E/S de disco, prolonga la vida de unidades SSD y mejora el rendimiento en situaciones de uso moderado de swap.

En el terreno del control de recursos, cgroupv2 ofrece un mecanismo potente para organizar procesos en jerarquías y repartirles memoria, CPU y otros recursos. A través de parámetros como memory.low o ficheros como memory.pressure, se puede indicar al kernel qué grupos tienen prioridad y monitorizar el tiempo que las tareas pasan bloqueadas por falta de memoria, diferenciando si el problema afecta a algunas tareas o a todo el grupo.

En escenarios donde se quiere evitar por todos los medios que el sistema se congele, han surgido varios demonios en espacio de usuario para gestionar situaciones de OOM de forma más proactiva. EarlyOOM supervisa periódicamente la RAM y la swap, y cuando detecta que ambas caen por debajo de ciertos umbrales (por defecto, menos del 10% libre para empezar a actuar), envía señales a los procesos con mayor oom_score para liberar memoria antes de que el kernel entre en pánico.

nohang ofrece un enfoque similar pero más configurable, soportando zram, analizando la memory pressure y permitiendo definir acciones personalizadas cuando se detecta un riesgo de bloqueo. Aunque el proyecto ha perdido algo de actividad en comparación con otros, sigue siendo una opción atractiva para usuarios avanzados que quieran un control fino sobre qué procesos se sacrifican y cuándo.

Por último, systemd-oomd, originado en Facebook y hoy integrado en muchas distribuciones con systemd moderno, ofrece una solución pensada tanto para grandes despliegues como para escritorios. Supervisa límites de cgroups, presión de memoria y otros indicadores, y decide qué unidades o servicios parar para recuperar la usabilidad del sistema, funcionando como un complemento más sofisticado al OOM-killer clásico del kernel.

Buenas prácticas para evitar problemas de memoria

En el día a día, más allá de tunear parámetros concretos, conviene seguir una serie de buenas prácticas para minimizar los sustos relacionados con la memoria en Linux. La primera es dimensionar correctamente la RAM y la swap en función de la carga real: bases de datos, servidores de aplicaciones, escritorios pesados o cargas de contenedores múltiples requieren más memoria que servicios simples.

En servidores, es recomendable revisar regularmente qué servicios están activos y desactivar o detener los que no se utilizan. En entornos con Docker u otros contenedores, tras completar pruebas o despliegues temporales conviene limpiar contenedores, imágenes y volúmenes que ya no hagan falta, para evitar que se queden procesos residuales consumiendo memoria de manera silenciosa.

Los discos RAM (ramdisks) pueden ser una herramienta útil para acelerar ciertos tipos de trabajos temporales: se define un sistema de ficheros en RAM y se usa para cachear datos de aplicación o áreas de trabajo de alta rotación. Como son volátiles, hay que tener claro que su contenido se pierde al apagar o reiniciar, pero a cambio pueden ser decenas de veces más rápidos que un SSD, algo muy interesante para tareas intensivas de lectura y escritura temporal.

Desde el punto de vista de la seguridad, es importante vigilar los puertos abiertos y exponer solo aquellos que sean estrictamente necesarios. Ataques de malware, como criptomineros, suelen dejar rastros en forma de procesos que consumen enormes cantidades de CPU y memoria, y pueden instalar tareas en crontab para persistir. Revisar y limpiar crons sospechosos, así como cerrar puertos no esenciales, ayuda a evitar que la memoria se consuma por procesos no deseados.

Por último, no hay que olvidar el impacto del sistema de ficheros en el rendimiento global. Opciones modernas como XFS o Btrfs pueden ofrecer ventajas frente a ext4 en determinados escenarios, especialmente en cargas intensivas o cuando se aprovechan funciones avanzadas. Cada caso requiere pruebas, pero la elección del sistema de ficheros también influye en la manera en que se gestionan los metadatos y el acceso a disco, afectando indirectamente a la percepción de fluidez del sistema.

Dominar la gestión de memoria en Linux implica entender cómo se reparten RAM, swap y almacenamiento, qué papel juegan conceptos como páginas, page cache, memory pressure o OOM, y cómo utilizar herramientas y mecanismos avanzados como zram, zswap, cgroupv2 o systemd-oomd; con ese conocimiento en la mano, es mucho más sencillo afinar cada equipo —desde un portátil modesto hasta un servidor de producción cargado de servicios— para que la memoria deje de ser una fuente de problemas y se convierta en un aliado para conseguir un sistema ágil, estable y preparado para soportar picos de carga sin dramas.