En la lección anterior llegamos a la idea de la paginación y la dejamos planteada: si todas las piezas miden lo mismo, encajarlas deja de ser un problema. Ahora toca cumplir la promesa. Esta es la lección más densa del módulo y probablemente la más rentable de todo el curso, porque la memoria virtual es el mecanismo que explica una cantidad enorme de cosas que verás en producción: por qué un proceso reserva 400 MB y solo usa 31, por qué la primera petición a meteo-api tras un despliegue es lenta y las siguientes no, por qué un servidor que empieza a paginar deja de responder de golpe, y por qué el OOM killer elige lo que elige.

Vas a ver la traducción de direcciones con números concretos, calcular el tamaño imposible de una tabla plana de 64 bits, medir cuánto rendimiento depende de la TLB, seguir un fallo de página paso a paso, resolver los algoritmos de reemplazo sobre una misma cadena de referencias y mapear el fichero 2026-08-31.dat en memoria con mmap(). Al final sabrás interpretar free -h, vmstat y el rastro del OOM killer con criterio.

1. Páginas y marcos
2. Traducción de direcciones, con un ejemplo numérico completo
3. La tabla de páginas y sus bits de control
4. Por qué una tabla plana es imposible en 64 bits
5. Tablas multinivel
6. La TLB y el tiempo efectivo de acceso
7. Páginas grandes (huge pages)
8. Paginación por demanda y el fallo de página
9. Algoritmos de reemplazo de páginas
10. Asignación de marcos, hiperpaginación y conjunto de trabajo
11. Ficheros mapeados y memoria compartida con mmap()
12. Copy-on-write revisitado
13. Swap, swappiness y el OOM killer
14. Medición: VSZ frente a RSS, /proc/meminfo, free -h, vmstat

Los dos términos son la base de todo el vocabulario y conviene fijarlos sin ambigüedad:

Comprueba el tamaño de página de tu sistema:

Y los números de meteo-01:

Hay treinta y cuatro mil millones de veces más páginas posibles que marcos disponibles. Esa desproporción es exactamente lo que hace posible la memoria virtual: la inmensa mayoría de las páginas nunca existirá, y las que existan no tienen por qué estar todas en RAM a la vez.

Una dirección lógica se parte en dos campos:

• El desplazamiento ocupa tantos bits como haga falta para direccionar dentro de una página. Con páginas de 4 KB = 2^12 bytes, son 12 bits.
• El número de página ocupa el resto.

La traducción tiene tres pasos:

1. Extraer p y d de la dirección lógica.
2. Buscar en la tabla de páginas la entrada p, que contiene el número de marco f.
3. La dirección física es f × tamaño_página + d.

El desplazamiento no se traduce nunca. Página y marco miden lo mismo, así que la posición dentro de la página es idéntica a la posición dentro del marco. Solo cambia qué bloque, no dónde dentro del bloque.

Trabajemos con un espacio lógico pequeño para poder verlo todo: direcciones de 16 bits y páginas de 4 KB.

Tabla de páginas del ingestor:

Traducir la dirección lógica 0x2A5C.

Paso 1, descomponer:

Comprobación aritmética, que suele ser más rápida:

Paso 2, consultar la tabla: página 2 → marco 2, presente.

Paso 3, componer la dirección física:

Ha coincidido con la lógica por casualidad (la página 2 está en el marco 2). Probemos otra.

Traducir 0x105C:

Observa un detalle revelador: 0x105C → 0x905C. Los tres dígitos hexadecimales de la derecha no cambian (05C), porque son el desplazamiento. Solo cambia el dígito de la izquierda: 1 → 9, de página a marco. En hexadecimal la traducción es visualmente evidente cuando el tamaño de página es potencia de 16.

Traducir 0x3200:

Aquí no hay traducción posible. La MMU genera una excepción y el núcleo toma el control. Qué hace entonces es el apartado 8.

Cada entrada de la tabla de páginas (PTE, Page Table Entry) ocupa 8 bytes en x86-64 y contiene mucho más que un número de marco:

Los que importan de verdad y por qué:

Bit P (presente). Es el interruptor de toda la memoria virtual. Si vale 0, cualquier acceso provoca un fallo de página. El núcleo lo usa para tres situaciones distintas, y distingue entre ellas con los bits restantes de la entrada, que quedan libres cuando P=0: página nunca cargada, página expulsada a swap, o dirección simplemente inválida.

Bits R/W y NX. Aquí es donde se implementa la protección por región que veíamos en /proc/<pid>/maps. La región r-xp del código tiene R/W=0 (no escribible); las regiones rw-p de pila y montículo tienen NX=1 (no ejecutable). Ese par de bits es la política W^X.

Bits A y D. Son especiales porque los escribe el hardware, no el sistema operativo. Cada vez que la CPU accede a una página pone A=1; cada vez que escribe pone D=1. El núcleo los lee y los limpia periódicamente. Sin ellos sería imposible implementar los algoritmos de reemplazo: el núcleo no tiene forma de observar cada acceso a memoria, así que necesita que el hardware le deje esa pista.

Bit D (sucio). Determina el coste de expulsar la página. Si D=0, la página no ha cambiado desde que se cargó, así que se puede descartar sin más (si vuelve a hacer falta se relee del fichero). Si D=1, hay que escribirla en swap antes de reutilizar el marco. Es exactamente la distinción de la columna Dirty de pmap que vimos en 02-03, y la diferencia de coste es de cero frente a milisegundos.

Hagamos el cálculo que justifica toda la complejidad que viene después.

En x86-64 se usan actualmente 48 bits de dirección virtual (los 16 superiores son extensión de signo). Con páginas de 4 KB:

512 GB de tabla de páginas. Por proceso. En una máquina de 8 GB con 180 procesos, harían falta 92 TB solo para las tablas.

Es absurdo, y lo es por una razón muy concreta: la tabla plana reserva una entrada para cada página posible, incluidas las que nunca existirán. Recuerda el mapa de memoria del ingestor: el código está en 0x400000 y la pila en 0x7ffd8b3a1000. Entre ambos hay un abismo de 140 TB de direcciones que jamás se usarán, y una tabla plana necesitaría una entrada para cada una.

El proceso real usa unas 4.500 páginas de los 68.000 millones posibles: el 0,0000065 %. La estructura debe aprovechar esa dispersión extrema.

La solución es hacer la tabla jerárquica y dispersa: dividir el número de página en varios campos, cada uno indexando un nivel, y crear solo las tablas de nivel inferior que realmente hagan falta.

x86-64 usa cuatro niveles (cinco en las CPU más recientes). El número de página de 36 bits se parte en cuatro campos de 9 bits:

Cada nivel tiene 2^9 = 512 entradas de 8 bytes = exactamente 4.096 bytes, una página. Ese encaje no es casual: cada tabla ocupa justo una página, lo que simplifica enormemente su gestión.

El ahorro es espectacular. Para un proceso que usa código en la parte baja y pila en la alta:

60 KB frente a 512 GB. Un factor de ocho millones.

El precio: una traducción requiere cuatro accesos a memoria (uno por nivel) más el acceso a los datos. Cinco accesos donde antes había uno. A ~100 ns por acceso a RAM, eso serían 500 ns por cada lectura de memoria: el sistema sería 5 veces más lento que sin paginación. Inaceptable.

Esa es la razón exacta por la que existe la TLB.

La TLB (Translation Lookaside Buffer) es una caché asociativa, dentro de la MMU, que guarda las traducciones página→marco usadas recientemente. Es pequeña (entre 64 y 1.536 entradas en CPU modernas) y rapidísima (menos de 1 ns).

El flujo:

1. La CPU genera una dirección lógica.
2. La MMU busca el número de página en la TLB.
3. Acierto de TLB: se obtiene el marco directamente. Coste ≈ 0.
4. Fallo de TLB: hay que recorrer los cuatro niveles de tablas en memoria y luego insertar el resultado en la TLB.

El cálculo del tiempo efectivo de acceso (TEA) es la fórmula que hay que saber hacer:

donde h es la tasa de aciertos, t_TLB el tiempo de consulta de la TLB, t_mem el acceso a memoria y n el número de niveles.

Con valores realistas (t_TLB = 1 ns, t_mem = 100 ns, n = 4):

Detalle del caso del 99 %:

La conclusión práctica es contundente: con un 99 % de aciertos pierdes solo un 4 %; con un 70 % pierdes más del doble de rendimiento. La TLB no es una optimización menor, es lo que hace viable la paginación.

Y por eso importa tanto el coste del cambio de contexto que calculamos en 02-01: al cambiar cr3, las entradas de TLB del proceso anterior dejan de valer y se invalidan. El proceso entrante arranca con la TLB vacía y una ráfaga de fallos. Los PCID (identificadores de contexto de proceso) mitigan esto etiquetando cada entrada con el proceso al que pertenece, de modo que no haga falta vaciarla entera.

Puedes ver los fallos de TLB reales:

Un 0,84 % de fallos, es decir un 99,16 % de aciertos. Perfectamente sano. Si vieras un 15 % de fallos, tendrías un proceso con un patrón de acceso muy disperso, y ahí es donde entran las páginas grandes.

El problema aparece cuando un proceso trabaja con conjuntos de datos enormes. El agregador procesando un día entero de lecturas:

No caben. Recorrer los 17 MB provoca fallos de TLB continuos, porque las traducciones se expulsan entre sí. Y con 30 días de histórico serían 124.000 páginas: la TLB sería inútil.

Las páginas grandes resuelven esto usando un tamaño de página mayor: 2 MB o 1 GB en x86-64. Se consigue parando la jerarquía un nivel antes (una entrada del directorio de páginas apunta directamente a un bloque de 2 MB en lugar de a una tabla).

Los 17 MB del agregador pasan de 4.150 entradas de TLB a 9. Con eso caben de sobra y los fallos de TLB desaparecen prácticamente.

En Linux hay dos formas de usarlas:

• THP (Transparent Huge Pages): el núcleo promueve automáticamente regiones grandes a páginas de 2 MB. Los 215 MB de AnonHugePages indican que ya está ocurriendo. Es cómodo, pero tiene un coste conocido: el demonio khugepaged compacta memoria en segundo plano y puede introducir pausas. Por eso muchas bases de datos recomiendan ponerlo en madvise o never.
• Huge pages explícitas: se reservan al arranque y la aplicación las pide expresamente. Más control, menos comodidad.

Regla de decisión: las páginas grandes ayudan cuando el conjunto de trabajo es grande y se recorre de forma dispersa; estorban cuando la memoria es escasa y hay que paginar, porque expulsar 2 MB de golpe es muy caro.

Aquí llega la pieza que convierte la paginación en memoria virtual: no hace falta que todas las páginas de un proceso estén en RAM.

La paginación por demanda consiste en no cargar nada hasta que se necesite. Al arrancar meteo-api, el núcleo no lee sus 820 KB de código: crea las entradas con P=0 y deja que los fallos de página traigan lo que haga falta. Esto explica los datos que vimos en 02-03: libssl con 12 KB de 1.024 KB cargados.

Cuando la CPU accede a una página con P=0:

Un detalle esencial del final: la instrucción que falló se vuelve a ejecutar desde cero. El proceso no se entera de nada. Para él, ese acceso a memoria simplemente tardó mucho.

Aquí es donde los números duelen. Hay dos tipos de fallo muy distintos:

La diferencia es de tres a cuatro órdenes de magnitud:

Y ahora el cálculo que explica por qué la tasa de fallos mayores tiene que ser minúscula. Con acceso normal a memoria de 100 ns y fallo mayor de 8 ms:

Con un fallo mayor por cada mil accesos, el sistema va 81 veces más lento. Para mantener la degradación por debajo del 10 % hace falta menos de un fallo por cada millón de accesos.

Esto no es una curiosidad académica: es exactamente lo que le ocurre a un servidor que empieza a paginar. No se degrada suavemente, cae por un precipicio. Y es la razón de la hiperpaginación que veremos en el apartado 10.

Puedes ver los fallos de tus procesos:

Los fallos menores son normales y abundantes: forman parte del funcionamiento habitual. Los mayores son los que importan: 112 en el agregador tras 22 horas es perfectamente sano. Si vieras 400.000, el proceso estaría leyendo constantemente de swap y ese sería el problema a resolver.

Cuando ocurre un fallo de página y no quedan marcos libres, hay que expulsar a alguien. La elección determina cuántos fallos habrá después.

Resolveremos todos los algoritmos sobre la misma cadena de referencias, que es la única forma honesta de compararlos:

Expulsa la página que tardará más en volver a usarse. Es imposible de implementar (requiere conocer el futuro), pero sirve como cota inferior con la que comparar.

9 fallos.

Expulsa la página que lleva más tiempo cargada, sin importar su uso.

15 fallos. Un 67 % más que el óptimo.

FIFO tiene un defecto que desafía la intuición: darle más memoria puede aumentar los fallos. Con esta cadena:

Con 3 marcos:

9 fallos.

Con 4 marcos:

10 fallos. Más memoria, más fallos.

La causa: FIFO no tiene la propiedad de pila (que el conjunto de páginas con n marcos esté contenido en el de n+1 marcos). Al añadir un marco, el orden de expulsión cambia por completo y puede expulsar justo lo que iba a hacer falta. LRU y OPT sí tienen esa propiedad y por eso están libres de la anomalía.

Es la razón principal por la que FIFO puro no se usa en ningún sistema real: un algoritmo del que no puedes afirmar "con más RAM irá mejor" es inaceptable.

Expulsa la página que lleva más tiempo sin usarse. Se apoya en el principio de localidad temporal: lo que se ha usado hace poco probablemente se vuelva a usar.

12 fallos. Entre el óptimo (9) y FIFO (15).

El problema de LRU es su coste de implementación. Requiere ordenar las páginas por último acceso, y eso significa actualizar una estructura en cada acceso a memoria. Sería necesario hardware que, en cada lectura, moviese una entrada al principio de una lista de miles de elementos. Ninguna CPU lo hace, porque sería carísimo.

Como LRU exacto es inviable, se aproxima usando el bit A (accedido) que el hardware sí mantiene gratis.

El algoritmo del reloj organiza los marcos en un círculo con un puntero:

1. El puntero apunta a un marco candidato.
2. Si su bit A = 0, se expulsa y el puntero avanza.
3. Si su bit A = 1, se le da una segunda oportunidad: se pone A = 0 y el puntero avanza al siguiente, sin expulsar nada.
4. Se repite hasta encontrar un marco con A = 0.

La intuición es exacta: una página con A=1 se ha usado desde la última vuelta del puntero, así que probablemente se siga usando. Una con A=0 no se ha tocado en toda una vuelta: es buena candidata.

Una variante mejor usa dos bits, A y D, que combinan reciente uso y coste de expulsión:

Linux usa una variante refinada: dos listas LRU (activa e inactiva) por zona de memoria, con promoción entre ellas según los accesos, más el bit A para el envejecimiento. Es LRU aproximado, con el coste amortizado a casi cero.

Y aquí está la conclusión práctica que se suele pasar por alto: la diferencia entre el mejor algoritmo posible y uno decente es un 33 %; la diferencia entre tener suficiente RAM y no tenerla es un factor de 81. Optimizar el algoritmo de reemplazo importa mucho menos que dimensionar bien la memoria.

Con 180 procesos y 2 millones de marcos, ¿cuántos marcos le tocan a cada proceso?

Asignación equitativa: marcos / procesos. Simple e injusta: meteo-api con 116 MB de datos recibiría lo mismo que un sshd de 9 MB.

Asignación proporcional: repartir según el tamaño de cada proceso.

Y una distinción importante:

• Reemplazo local: un proceso que falla solo puede robar marcos a sí mismo. Su rendimiento es predecible pero no aprovecha la memoria ociosa de otros.
• Reemplazo global: puede robar a cualquiera. Mejor uso global, pero el rendimiento de un proceso depende del comportamiento de los demás. Linux usa reemplazo global.

Aquí está el fenómeno más importante de esta sección. Si un proceso no tiene marcos suficientes para su conjunto de trabajo, entra en un ciclo destructivo:

El bucle se realimenta: cuanta menos CPU se usa, más procesos se admiten, y menos memoria queda para cada uno.

Los síntomas son inconfundibles y merece la pena memorizarlos:

La combinación CPU al 10 % con carga media de 40 es el diagnóstico. Si vieras esto en meteo-01:

Los datos hablan solos: 85 % de %wa (espera de E/S), 27 procesos bloqueados en la columna b, y si/so en torno a 50.000 KB/s en ambas direcciones. El sistema está trayendo y llevando las mismas páginas continuamente. No hay ajuste de configuración que salve esto: falta memoria.

La solución conceptual la formuló Peter Denning en 1968. El conjunto de trabajo W(t, Δ) es el conjunto de páginas referenciadas por un proceso en las últimas Δ referencias.

La regla es simple y potente:

Y cuando eso ocurre, la única solución correcta es suspender procesos —reducir el grado de multiprogramación— para que los que queden tengan su conjunto de trabajo completo. Es contraintuitivo pero cierto: ejecutar menos procesos hace que el sistema avance más.

Linux no implementa el modelo de Denning literalmente, pero su presión de memoria y el OOM killer persiguen el mismo objetivo: cuando el sistema no puede sostener a todos, elimina a alguien en lugar de dejar que nadie avance.

mmap() es una de las llamadas al sistema más potentes de UNIX: hace que un fichero aparezca como memoria.

En lugar de open + read + copiar a un búfer, se mapea el fichero en el espacio de direcciones y se accede a él como si fuera un array.

Qué hace cada parte y por qué importa:

• mmap(NULL, tamaño, PROT_READ, MAP_PRIVATE, fd, 0) pide al núcleo que asocie el fichero a una región del espacio de direcciones. NULL deja que el núcleo elija la dirección; PROT_READ la hace de solo lectura; MAP_PRIVATE significa que las escrituras (si las hubiera) serían copy-on-write y no llegarían al fichero.
• No se lee nada del disco en este momento. El núcleo solo crea entradas de tabla de páginas con P=0. Los 17 MB llegan por demanda, cuando el bucle los toque: cada acceso a una página nueva provoca un fallo de página que la trae.
• close(fd) no invalida el mapeo. El mapeo mantiene su propia referencia al fichero. Es un detalle que sorprende y que permite cerrar descriptores sin perder el acceso.
• lecturas[i].temperatura es aritmética de punteros normal. El compilador genera un acceso a memoria; la MMU y el núcleo hacen el resto. No hay ninguna llamada al sistema en el bucle.

Ese último punto es la razón de fondo para usar mmap. Compara con la alternativa de read(), aplicando lo que calculamos en 01-06:

La última fila es especialmente valiosa para Meteora: si agregador y meteo-api mapean ambos 2026-08-31.dat, las páginas de la caché del núcleo se comparten físicamente. Un solo juego de 17 MB en RAM sirve a los dos procesos.

Cuándo mmap no conviene: para lecturas secuenciales de un solo paso de ficheros muy grandes, read() con un búfer grande puede ser igual o mejor, porque mmap provoca un fallo de página por cada 4 KB (miles de excepciones), y porque un fichero mayor que la RAM mapeado entero puede provocar presión de memoria.

Con MAP_SHARED en lugar de MAP_PRIVATE, las escrituras sí se propagan: al fichero y a todos los procesos que lo mapeen.

Esto es exactamente la región rw-s- que vimos en el pmap de meteo-api en 02-03: los cuatro trabajadores comparten una única caché de 8 MB. Los mecanismos de comunicación entre procesos y la sincronización que esto exige corresponden a Comunicación entre Procesos y Sincronización.

Ahora que conoces los bits de la tabla de páginas, el COW de fork() que vimos en 02-01 se puede explicar exactamente:

1. fork() copia las tablas de páginas del padre al hijo.
2. En ambas copias, todas las páginas escribibles se marcan con R/W = 0 (solo lectura), y el núcleo anota internamente que son COW.
3. Ambos procesos apuntan a los mismos marcos físicos. Cero copias de datos.
4. Cuando cualquiera de los dos escribe, la MMU detecta R/W=0 y genera un fallo de página de protección.
5. El núcleo lo distingue de un error real (comprueba que la región es COW y no de solo lectura genuina), copia esa única página de 4 KB, la asigna en exclusiva al que escribió y le pone R/W=1.
6. Si el contador de referencias del marco original baja a 1, el otro proceso también recupera R/W=1: ya no hay nada que proteger.

Los números para meteo-api con sus 148 MB:

Y ahora entiendes también por qué fork() puede parecer barato y luego costar: si el hijo escribe por toda la memoria heredada, acabarás pagando la copia página a página, con un fallo de página por cada 4 KB. Esa es la queja clásica contra fork() en procesos enormes, y la razón de que existan alternativas como posix_spawn() y vfork().

El área de intercambio (swap) es el espacio en disco donde se guardan las páginas anónimas expulsadas.

Interpretación de free -h, que es donde casi todo el mundo se equivoca:

Los 412 MB de free alarman a mucha gente sin motivo. Los 4,3 GB de buff/cache son páginas de ficheros que el núcleo mantiene por si vuelven a hacer falta, y son desechables al instante. La memoria realmente disponible son los 3,9 GB de available.

RAM libre no es RAM aprovechada. Un sistema con memoria libre está desperdiciando la oportunidad de cachear. Lo correcto es que free sea bajo y available sea alto.

Controla la agresividad con que el núcleo expulsa páginas anónimas frente a descartar caché de ficheros:

Para meteo-01 un valor de 10 sería razonable: es preferible descartar caché de páginas (recuperable con una lectura secuencial rápida) antes que mandar a swap la caché de respuestas de meteo-api (que provocaría fallos mayores en el camino crítico de las peticiones).

Un aviso importante: swappiness=0 no desactiva el swap, y desactivar el swap por completo tampoco es buena idea. Sin swap, las páginas anónimas inactivas —que en cualquier sistema son muchas— se quedan ocupando RAM eternamente, y ante presión de memoria el núcleo pasa directamente al OOM killer sin tener alternativas intermedias.

Cuando no hay memoria ni marcos que expulsar, el núcleo activa el Out Of Memory killer: elige un proceso y lo mata.

La elección se basa en una puntuación:

oom_score es proporcional a la memoria consumida, con ajustes: penaliza a los procesos grandes y de usuarios normales, y protege a los de root y al PID 1. oom_score_adj va de −1000 (nunca matarlo) a +1000 (matarlo primero) y es lo que puedes ajustar tú:

El rastro que deja en el registro:

Cómo leerlo línea a línea, que es lo que hay que saber hacer en una guardia:

• agregador invoked oom-killer: quien provocó el OOM fue el agregador al pedir memoria. No implica necesariamente que sea el culpable, aunque aquí lo es.
• La tabla de tareas lista todos los procesos con su rss en páginas. El agregador tiene 1.180.221 páginas × 4 KB = 4,5 GB. meteo-api tiene 33.785 × 4 KB = 132 MB.
• Killed process 1877 (agregador) con anon-rss:4720884kB: se eligió al que más memoria anónima consumía, que es el criterio habitual.
• anon-rss frente a file-rss: los 4,7 GB son anónimos, es decir, memoria dinámica sin respaldo en fichero. Matar el proceso los libera de inmediato. Si fuera file-rss, matarlo apenas liberaría nada.

Esa cifra de 4,5 GB en un agregador que en condiciones normales usa 31 MB es el diagnóstico completo: procesar un día entero cargando todo en memoria en lugar de por bloques. La corrección es de diseño —mmap o lectura por bloques—, no de configuración.

Recuerda además lo que vimos en 02-01: cuando el OOM killer mata un proceso, este muere por SIGKILL (señal 9), lo que tu supervisor detectaría con WIFSIGNALED(estado) y WTERMSIG(estado) == 9.

Cerramos con las herramientas y cómo interpretarlas sin equivocarse.

El problema del RSS con un ejemplo concreto: si meteo-api tiene 4 trabajadores y cada uno reporta 148 MB de RSS, sumar da 592 MB, pero el consumo real puede ser 200 MB porque comparten código, libc y la caché de /dev/shm. PSS lo resuelve dividiendo cada página compartida entre quienes la usan:

94 MB reales frente a 148 MB de RSS. Para contabilizar memoria en un servidor con procesos que comparten mucho, PSS es la métrica correcta.

/proc/meminfo da la foto global:

Las líneas que informan de verdad:

• MemAvailable: 3,9 GB. La única que responde a "¿cuánta memoria puedo usar?".
• AnonPages 2,9 GB: memoria anónima de los procesos. Solo puede ir a swap.
• Cached 4 GB: páginas de fichero. Desechables al instante.
• Dirty 28 MB: modificadas pero aún no escritas a disco. Si esta cifra sube mucho, hay un cuello de botella de escritura. Su vaciado forzado es lo que hace fsync().
• Slab 298 MB: estructuras del propio núcleo (inodos, dentries, task_struct). No es memoria de procesos.

Y vmstat para ver la dinámica:

Las columnas críticas para memoria:

• si/so (swap in / swap out, en KB/s): la métrica más importante. Un swpd de 512 MB con si/so a cero es inofensivo: son páginas viejas expulsadas hace tiempo que nadie reclama. Lo grave es si/so sostenidos: ahí sí hay hiperpaginación.
• b: procesos bloqueados en E/S ininterrumpible (el estado D de 02-01).
• wa: porcentaje de CPU esperando E/S.

La regla de diagnóstico que resume la lección: mira si/so, no swpd. Tener swap ocupado es normal; tener swap en movimiento constante significa que falta RAM.

Alarmarse porque free es bajo. La columna correcta es available. Un sistema sano tiene poca memoria libre y mucha caché, porque la RAM ociosa es RAM desperdiciada.

Confundir swpd con estar paginando. Que haya 512 MB en swap no dice nada por sí solo: pueden llevar días ahí sin que nadie los reclame. Lo que indica un problema son si/so sostenidos en vmstat.

Desactivar el swap "para que el sistema no se ralentice". Sin swap, el núcleo pierde su herramienta intermedia y ante presión de memoria pasa directamente al OOM killer. La configuración razonable es tener swap y bajar swappiness, no eliminarlo.

Sumar los RSS de varios procesos. Da un total inflado porque las páginas compartidas se cuentan varias veces. Para sumar, usa PSS.

Creer que el OOM killer mata al culpable. Mata al que tiene la mayor puntuación, que suele ser el más grande. Si el agregador provoca la escasez y meteo-api es el que más memoria tiene, muere meteo-api. Protege lo crítico con oom_score_adj negativo.

Activar THP en todo. Las páginas transparentes de 2 MB ayudan a cargas con conjuntos de trabajo grandes, pero khugepaged compactando memoria puede introducir pausas de decenas de milisegundos. Las bases de datos suelen recomendar madvise o never justo por eso.

Interpretar un SIGSEGV como un bug del sistema. Es la MMU haciendo su trabajo: el proceso accedió a una dirección sin traducción válida o sin los permisos adecuados. Compara la dirección con /proc/<pid>/maps para saber si fue un puntero corrupto (cae en un hueco) o una escritura en zona de solo lectura.

Consejo de diagnóstico: ante una sospecha de problema de memoria, este es el orden que funciona: free -h (mirar available), vmstat 1 (mirar si/so y wa), ps -eo pid,rss,maj_flt --sort=-rss | head (quién consume y quién falla), pmap -x <pid> (qué región crece) y dmesg -T | grep -i oom (si ya ha muerto alguien). Cinco órdenes y tienes el cuadro completo.

Un sistema tiene direcciones lógicas de 32 bits y páginas de 4 KB.

1. ¿Cuántos bits ocupan el número de página y el desplazamiento? ¿Cuántas páginas hay como máximo?
2. Con esta tabla de páginas, traduce las direcciones lógicas 0x00003ABC, 0x00001234 y 0x00006000:

3. Calcula el tamaño de una tabla plana con entradas de 4 bytes. Compáralo con el caso de 64 bits del apartado 4 de la lección.
4. Con una TLB del 96 % de aciertos, acceso a memoria de 80 ns, TLB de 2 ns y 2 niveles de tabla, calcula el tiempo efectivo de acceso.

El agregador genera esta cadena de referencias a páginas:

1. Calcula los fallos de página con 3 marcos para: óptimo, FIFO y LRU. Muestra el estado de los marcos en cada paso.
2. Repite con 4 marcos.
3. ¿Qué algoritmo presenta la anomalía de Belady? Demuéstralo con tus números.
4. Si cada fallo mayor cuesta 8 ms, calcula el tiempo total perdido en cada caso con 3 marcos.

meteo-01 responde con lentitud extrema. Recoges estos datos:

1. Diagnostica qué le pasa al sistema. Nombra el fenómeno y justifícalo con al menos cuatro datos.
2. ¿Por qué el uso de CPU es del 3 % si el sistema va lentísimo?
3. Identifica la causa raíz. ¿Cuánta memoria debería usar el agregador, sabiendo que procesa un día de lecturas?
4. Propón tres soluciones: una inmediata, una de configuración y una de diseño. Indica cuál es la correcta.
5. Escribe el fragmento de código que resolvería el problema de raíz.

Solución 1

1. Descomposición de la dirección.

2. Traducciones.

0x00003ABC:

Atajo hexadecimal: los tres dígitos de la derecha (ABC) se conservan y los de la izquierda pasan de 00003 a 0002C.

0x00001234:

0x00006000:

Es importante distinguir este caso del de la página 4, que sí existe pero tiene Presente = No: allí el fallo sería recuperable (el núcleo la traería de swap o del fichero y reintentaría la instrucción), mientras que aquí es un error genuino del programa.

3. Tamaño de la tabla plana en 32 bits.

Comparación con 64 bits:

Y aquí está la observación clave del ejercicio: 4 MB por proceso ya es demasiado. Con 180 procesos son 720 MB solo de tablas, casi el 9 % de los 8 GB de meteo-01, y la inmensa mayoría de esas entradas estarían vacías. Por eso incluso los sistemas de 32 bits usaban tablas multinivel (x86 de 32 bits tenía dos niveles). La tabla plana nunca fue viable; en 64 bits pasa de inviable a directamente absurda.

4. Tiempo efectivo de acceso.

Degradación frente al acceso puro (80 ns): 88,4 / 80 = 1,105, un 10,5 %.

Vale la pena observar cuánto pesa ese 4 % de fallos: aporta 9,68 ns de los 88,4 totales, un 11 % del tiempo, siendo solo el 4 % de los accesos. Es la aritmética típica de las cachés, y explica por qué mejorar del 96 % al 99 % de aciertos merece la pena:

Solución 2

1. Con 3 marcos.

Óptimo (expulsa la que tardará más en reaparecer):

Las decisiones de expulsión: en la posición 4 sale 3 (reaparece en la 10, más tarde que 1 y 2); en la 7 sale 4 (reaparece en la 11); en la 10 sale 1 (no vuelve nunca); en la 11 sale 2 (tampoco vuelve).

7 fallos.

FIFO:

9 fallos.

LRU:

10 fallos.

2. Con 4 marcos.

Óptimo:

Con 4 marcos caben 1, 2, 3 y 4 desde el principio. Al llegar el 5 se expulsa el 4, porque reaparece en la posición 11, más tarde que 1, 2 y 3. En la posición 10 el 3 ya está residente, así que no hay fallo. En la 11 hay que traer el 4 y se expulsa el 1, que no vuelve a usarse.

6 fallos.

FIFO:

10 fallos.

LRU:

Traza de las expulsiones: al llegar el 5 (posición 7), el orden de uso es 3, 4, 1, 2, así que sale el 3. En la posición 10 hace falta el 3 y el menos usado recientemente es el 4. En la 11 hace falta el 4 y sale el 5. En la 12 hace falta el 5 y sale el 1. Fíjate en el patrón: las tres últimas referencias fallan porque LRU acaba de expulsar justo lo que se pide a continuación.

8 fallos.

3. La anomalía de Belady.

FIFO presenta la anomalía: pasar de 3 a 4 marcos aumenta los fallos de 9 a 10.

La explicación estructural: FIFO no cumple la propiedad de pila. Formalmente, un algoritmo la cumple si el conjunto de páginas residentes con n marcos es siempre un subconjunto del conjunto con n+1 marcos. LRU y OPT la cumplen porque su decisión depende del patrón de referencias, que no cambia al añadir marcos. FIFO decide por orden de llegada, y ese orden se altera completamente al cambiar el número de marcos: con 4 marcos, las páginas 1 y 2 sobreviven más tiempo y acaban siendo expulsadas justo antes de volver a usarse.

Es un resultado importante porque rompe una intuición que parecía segura, y es la razón práctica por la que ningún sistema real usa FIFO puro: no puedes prometer que ampliar la RAM mejorará el rendimiento.

4. Tiempo perdido con 3 marcos.

Una observación honesta sobre estos números: aquí LRU sale peor que FIFO, lo que contradice la intuición general. Es un artefacto de esta cadena concreta, diseñada precisamente para exhibir la anomalía de Belady. Con cadenas reales, que presentan localidad temporal fuerte, LRU supera claramente a FIFO. Es un buen recordatorio de que una cadena de doce referencias no demuestra nada sobre el comportamiento general de un algoritmo; para eso hacen falta trazas reales de millones de referencias.

Lo que sí demuestra la comparación es el orden de magnitud del problema: 12 accesos a memoria que deberían costar 1,2 microsegundos han costado entre 56 y 80 milisegundos. Un factor de 50.000. Cuando faltan marcos, el algoritmo de reemplazo es lo de menos.

Solución 3

1. Diagnóstico: hiperpaginación (thrashing).

Los datos que lo confirman, uno a uno:

El dato definitivo es si y so altos a la vez. Si solo hubiera so, el sistema estaría liberando memoria de forma ordenada. Que entre y salga a la vez a 40 MB/s significa que las mismas páginas se expulsan y se vuelven a traer sin parar: el conjunto de trabajo no cabe en RAM y cada página expulsada se necesita inmediatamente después. Es la definición exacta del bucle de realimentación del diagrama de la lección.

2. Por qué la CPU está al 3 %.

Porque no hay nada que ejecutar. Casi todos los procesos están en estado D, bloqueados esperando que el disco traiga una página. La columna r (ejecutables) marca 0 o 1, mientras que b (bloqueados) marca 31.

Este es el patrón más engañoso de todos: CPU casi ociosa con el sistema completamente parado. Quien mire solo el uso de CPU concluirá que el servidor está bien y buscará el problema en otro sitio. La combinación que hay que reconocer al instante es us+sy bajos + wa altísimo + b alto.

Un cálculo que lo dimensiona: 892.104 fallos mayores del agregador, a unos 100 µs cada uno con SSD, son 89 segundos de espera pura. Con disco mecánico a 8 ms serían ~2 horas de disco.

3. Causa raíz.

El agregador tiene 4.720.884 KB = 4,5 GB de RSS en una máquina de 7,8 GB. Es él solo el 60 % de la RAM total. Ni meteo-api (148 MB) ni ingestor (18 MB) son relevantes en comparación.

Cuánto debería usar:

Y con 24 bytes por lectura, esos 4,5 GB equivalen a unos 196 millones de lecturas: más de 270 días de datos. El diagnóstico es inmediato: el agregador está cargando en memoria todo el histórico en lugar del día que necesita procesar, muy probablemente por un readdir sobre /var/lib/meteora/lecturas/ sin filtro de fecha, acumulándolo todo en una estructura en memoria.

4. Tres soluciones.

Inmediata (recuperar el servidor ahora):

Libera 4,5 GB al instante. El sistema deja de paginar en segundos. Es una tirita, no una cura: volverá a ocurrir en la próxima ejecución.

De configuración (contener el daño):

Con MemoryMax=512M (un límite de cgroup, tema de 06-02), el agregador que intente pasar de 512 MB muere él solo sin arrastrar al resto del sistema. Esto convierte una caída global en un fallo aislado, que es exactamente lo que se quiere. No arregla el bug, pero lo contiene.

De diseño (la correcta):

Procesar por flujo, no cargando todo. Dos variantes válidas: leer por bloques con read(), o mapear el fichero del día con mmap() y dejar que la paginación por demanda gestione la memoria.

5. Código que lo resuelve.

Versión con mmap(), que aplica directamente lo visto en la lección:

Por qué esto resuelve el problema de raíz:

• Un solo día por ejecución. La ruta se construye con la fecha recibida: es imposible cargar el histórico completo por accidente.
• Los acumuladores tienen tamaño fijo: 64 × 24 × 32 bytes = 48 KB, independiente del volumen de datos. Esta es la clave del arreglo: la memoria del proceso ya no crece con la entrada.
• mmap no consume RSS propio. Las páginas mapeadas pertenecen a la caché de páginas del núcleo, que es desechable bajo presión de memoria (son limpias y respaldadas por fichero, como vimos en 02-03). Si falta RAM, el núcleo las descarta sin escribir nada y las relee después. Frente a los 4,5 GB anónimos de la versión anterior —que solo podían ir a swap—, esto cambia por completo el comportamiento del sistema bajo presión.
• madvise(MADV_SEQUENTIAL) le dice al núcleo que el acceso será secuencial. El núcleo activa lectura anticipada agresiva y descarta antes las páginas ya recorridas. Es una optimización pequeña de escribir y muy efectiva en recorridos completos.

Consumo resultante:

Un factor de 140 de reducción, y ninguna página anónima que pueda arrastrar al sistema a la hiperpaginación.

La paginación divide el espacio lógico en páginas y la memoria física en marcos del mismo tamaño, y traduce cada dirección separando número de página y desplazamiento —que nunca se traduce—. Cada entrada de la tabla lleva el marco y unos bits de control que lo gobiernan todo: P habilita la memoria virtual, R/W y NX implementan W^X, y A y D, que escribe el hardware, son la única pista que el núcleo tiene para decidir a quién expulsar y a qué coste.

Una tabla plana en 64 bits ocuparía 512 GB por proceso, así que las tablas son multinivel y dispersas: cuatro niveles de 9 bits, cada tabla ocupando exactamente una página, y 60 KB reales en lugar de 512 GB. El precio son cuatro accesos a memoria por traducción, y por eso existe la TLB: con un 99 % de aciertos pierdes un 4 % de rendimiento, con un 70 % pierdes más del doble. Las páginas grandes reducen 4.150 entradas de TLB a 9 para los 17 MB del agregador, a costa de fragmentación interna y de una granularidad de expulsión grosera.

La paginación por demanda hace que nada se cargue hasta que se toca, lo que explica libc con solo el 44 % de su código en RAM. Un fallo menor cuesta microsegundos y es normal; un fallo mayor cuesta milisegundos, y con uno por cada mil accesos el sistema va 81 veces más lento. Los algoritmos de reemplazo —óptimo como cota, FIFO con su anomalía de Belady, LRU inviable en exacto y el reloj como aproximación barata usando el bit A— se mueven en un margen del 33 %, mucho menos de lo que importa tener RAM suficiente. Cuando el conjunto de trabajo no cabe, aparece la hiperpaginación: CPU al 3 %, wa al 88 % y el sistema parado.

Y todo esto se toca con las manos: mmap() convierte 4.219 llamadas al sistema en una y permite que dos procesos compartan físicamente el mismo 2026-08-31.dat; el copy-on-write de fork() es simplemente R/W=0 más un fallo de protección; swappiness decide qué se sacrifica antes; y el OOM killer deja en dmesg un rastro que se lee proceso a proceso. La regla que resume la parte operativa: mira available y no free, mira si/so y no swpd, y suma PSS y no RSS.

Con esto cerramos la memoria. Nos queda el otro gran recurso que el sistema operativo administra y que ha aparecido en cada fallo mayor de esta lección: el almacenamiento. Cuánto cuesta realmente ese acceso a disco que hemos estado contando en milisegundos, por qué un SSD cambia todas las reglas, cómo se ordenan las peticiones para minimizar el movimiento del cabezal y qué configuración de RAID merece /var/lib/meteora. Es lo que veremos en Gestión de Almacenamiento.