Vam acabar la lliçó anterior amb una pregunta molt concreta: si ingestor i agregador tenen tots dos codi a l'adreça 0x400000, com és possible que no es trepitgin? La resposta a aquesta pregunta és la segona gran feina del sistema operatiu, i és més profunda del que sembla: implica el compilador, l'enllaçador, el carregador i un circuit específic dins de la CPU.

En aquesta lliçó entendràs com diversos processos comparteixen una memòria física limitada sense envair-se, quina diferència hi ha entre una adreça lògica i una de física, i per què la solució va evolucionar des d'un simple parell de registres fins als esquemes moderns. Veuràs també els dos tipus de fragmentació amb càlculs concrets, i acabaràs llegint el mapa de memòria real d'un procés de Meteora regió per regió. És la lliçó que prepara el terreny per a la següent, que és la que de debò explica com funciona un sistema modern.

1. El problema: memòria compartida sense invasions
2. Adreces lògiques i adreces físiques
3. Les tres fases de vinculació d'adreces
4. Reubicació amb registre base i límit
5. La MMU: el traductor al camí crític
6. Assignació contigua: particions fixes i variables
7. Estratègies d'assignació: primer, millor i pitjor ajust
8. Fragmentació interna i externa, amb números
9. Compactació i per què gairebé mai no es fa servir
10. Segmentació
11. Intercanvi (swapping) clàssic
12. La idea de la paginació
13. El mapa de memòria real d'un procés de Meteora

meteo-01 té 8 GB de RAM i executa uns 180 processos. El sistema operatiu ha de resoldre simultàniament cinc problemes que estiren en direccions diferents:

Fixa't en un detall que condiciona tota la resta: la protecció s'ha de comprovar a cada accés a memòria. No una vegada en arrencar el procés, sinó a cada mov que la CPU executa, milers de milions de vegades per segon. Això descarta de ple qualsevol solució basada en programari: si el sistema operatiu hagués de validar cada accés, un programa aniria mil vegades més lent.

Com ja vam veure a 01-06 amb les instruccions privilegiades, l'única solució possible és que ho faci el maquinari. I aquest maquinari és la MMU.

Quan compiles l'ingestor i mires on és la seva funció principal:

La CPU executarà instruccions que fan referència a l'adreça 0x401b40. Però aquesta no és la posició real als xips de RAM. És una adreça lògica (o virtual): un número que només té sentit dins de l'espai d'adreces d'aquest procés.

Això explica la paradoxa del principi: ingestor i agregador poden tenir tots dos codi a 0x401b40 perquè cadascun viu al seu propi espai d'adreces. La MMU tradueix aquesta mateixa adreça lògica a marcs físics diferents segons quin procés s'estigui executant.

Ho pots comprovar:

Els dos processos tenen el seu codi començant exactament a 0x401000. Cap dels dos no sap —ni necessita saber— on és realment a la RAM.

La traducció de "la variable total" a "el byte físic número 3.221.225.472" es pot fixar en tres moments diferents, i l'elecció té conseqüències molt diferents:

Vinculació en compilació. El compilador genera adreces absolutes: "carrega el que hi ha a la posició 2000". Si el programa no es carrega exactament al lloc previst, no funciona. És el que fan encara avui els microcontroladors de les estacions meteorològiques de Meteora: el microprogramari sap que la memòria comença a 0x20000000 perquè és una placa concreta i mai no canviarà.

Vinculació en càrrega. El compilador genera codi reubicable amb adreces relatives a l'inici del programa. El carregador hi suma l'adreça base real. És més flexible, però un cop carregat el procés no es pot moure, perquè les seves adreces ja han estat reescrites.

Vinculació en execució. El codi conserva adreces lògiques i la traducció es produeix a cada accés, en maquinari. Això permet moure un procés a la RAM mentre s'executa, i és la base de tot el que és modern: memòria virtual, copy-on-write, biblioteques compartides i ASLR.

De fet, ASLR (Address Space Layout Randomization) només és possible amb vinculació en execució. Comprova-ho:

Dues execucions del mateix cat amb la pila en adreces completament diferents. El sistema aleatoritza la disposició a cada arrencada perquè un atacant no pugui predir on hi haurà res. Hi tornarem al mòdul 5.

L'esquema de maquinari més simple que resol reubicació i protecció alhora fa servir dos registres:

• Registre base (o de reubicació): l'adreça física on comença el procés.
• Registre límit: la mida de l'espai d'adreces del procés.

A cada accés a memòria, el maquinari fa dues operacions:

Exemple numèric amb l'ingestor:

Aquí hi ha el mecanisme complet de la protecció de memòria, en dues línies de lògica. I observa el detall crucial que connecta amb 01-06: els registres base i límit només es poden modificar amb instruccions privilegiades. Si un procés pogués canviar el seu propi registre límit, la protecció no valdria res. Per això el nucli els carrega a cada canvi de context i el procés no els pot tocar.

Aquest esquema és elegant i rapidíssim (una comparació i una suma, uns pocs cicles), però té tres limitacions fatals:

1. Tot el procés ha de ser a la RAM i en un bloc contigu. Si necessita 8 MB, cal un forat de 8 MB seguits.
2. No permet permisos diferenciats. Tot l'espai té el mateix tractament: no pots marcar el codi com a no escrivible.
3. No permet compartir. Dos processos que executen el mateix binari necessiten dues còpies completes.

La MMU (Memory Management Unit) és el circuit que fa aquesta traducció. Als processadors moderns està integrada al nucli mateix de la CPU, al costat de les memòries cau, i no és un detall d'implementació: és una de les peces més crítiques del rendiment del sistema.

Tres característiques de la MMU que convé fixar des d'ara:

• Actua a cada accés. Cada mov, cada instrucció llegida, cada push a la pila. Si la traducció costés 10 ns, el sistema seria inutilitzable. Per això les MMU incorporen una memòria cau de traduccions (la TLB) que veurem a la lliçó vinent.
• És maquinari i no es pot eludir. Un programa en mode usuari no té cap manera d'accedir a una adreça física directament. Cap.
• La configura el sistema operatiu. El nucli decideix quines traduccions són vàlides; la MMU les aplica. És el mateix repartiment de papers que vam veure a 01-06: la política la posa el programari, el mecanisme l'imposa el maquinari.

Amb base i límit, cada procés ocupa un bloc contigu. Com es reparteix la memòria entre ells?

Es divideix la memòria en un nombre fix de particions de mida predeterminada en arrencar el sistema.

Simple d'implementar (n'hi ha prou amb una taula de 4 entrades), però rígid:

• Si meteo-api necessita 300 MB i li dones la partició 1 d'1 GB, es malbaraten 700 MB dins de la partició. Ningú més no els pot fer servir.
• Si l'agregador necessita 4 GB, no cap en cap, encara que sumant els forats lliures sobri espai.
• El grau de multiprogramació està limitat al nombre de particions: quatre processos com a màxim.

És l'esquema de l'IBM OS/MFT dels anys 60, que vam veure en parlar de multiprogramació a 01-02.

El sistema manté una llista de forats lliures i assigna a cada procés exactament el que demana. En acabar, el seu espai torna a la llista i es fusiona amb els forats adjacents.

Simulem una seqüència real en una memòria de 2.560 MB amb el nucli ocupant 400 MB:

Situació final: hi ha 1.360 MB lliures en total, però repartits en tres forats de 600, 500 i 260 MB. Si ara arriba un procés que necessita 900 MB, no hi cap, encara que n'hi hagi de sobres. Aquest és el problema al qual arribarem a l'apartat de fragmentació.

Quan hi ha diversos forats on cap un procés, cal triar. Tres estratègies clàssiques:

Comparem-les amb el mateix cas. Forats lliures, en aquest ordre:

Peticions successives: P1 = 212 MB, P2 = 417 MB, P3 = 112 MB, P4 = 426 MB.

Primer ajust:

Millor ajust:

Les quatre peticions se satisfan.

Pitjor ajust:

Resum:

Compte a generalitzar a partir d'un sol cas. Aquí guanya el millor ajust, però els estudis de simulació clàssics conclouen que:

• Primer ajust i millor ajust són equivalents en aprofitament, i el primer ajust és notablement més ràpid perquè no recorre tota la llista.
• El pitjor ajust és pitjor que tots dos en gairebé tots els escenaris: destrueix sistemàticament els forats grans, que són els més valuosos.
• El millor ajust té un defecte acumulatiu: deixa restes diminutes (83 MB, 88 MB) que mai no serviran per a res, i la llista de forats creix indefinidament. És fragmentació disfressada d'eficiència.

Per això el consens pràctic és el primer ajust, o la seva variant ajust següent (començar a buscar on va acabar la cerca anterior, en lloc de sempre des del principi), que reparteix millor el desgast.

La fragmentació és memòria que existeix físicament però no es pot fer servir. N'hi ha de dos tipus, i confondre'ls és un dels errors més freqüents:

Càlcul de fragmentació interna. Suposa particions fixes de 512 MB:

Gairebé la meitat de la memòria assignada no serveix per a res. I és un malbaratament invisible: el sistema informa de 2.048 MB en ús i és tècnicament cert.

Càlcul de fragmentació externa. Tornem a l'estat final de la simulació de particions variables:

La regla del 50 % quantifica com de dolent arriba a ser això: en un sistema amb particions variables i primer ajust, per cada N blocs assignats hi ha estadísticament 0,5·N blocs lliures perduts per fragmentació, cosa que significa que fins a un terç de la memòria pot quedar inutilitzable.

Un matís important per a més endavant: la paginació elimina totalment la fragmentació externa (perquè tots els blocs fan el mateix, així que qualsevol forat serveix per a qualsevol pàgina) però introdueix fragmentació interna acotada. Amb pàgines de 4 KB:

Canviar un terç de la memòria per un 0,09 % és un negoci excel·lent, i és la raó de fons per la qual tots els sistemes moderns paginen.

La solució òbvia a la fragmentació externa: moure els processos per ajuntar tots els forats en un de sol.

Ara el procés de 900 MB sí que hi cap. La compactació només és possible amb vinculació en temps d'execució: si les adreces estiguessin fixades a la càrrega, moure un procés el trencaria. Amb base i límit n'hi ha prou de copiar els bytes i actualitzar el registre base.

Per què, doncs, no es fa servir? Pel cost:

I això s'hauria de repetir cada vegada que la fragmentació es torni a acumular, que en un sistema amb processos entrant i sortint és constantment. En un servidor amb 64 GB, compactar podria costar segons.

Conclusió: la compactació funciona, però el remei és pitjor que la malaltia. La solució real va ser canviar el plantejament: si el problema és exigir que un procés ocupi un bloc contigu, eliminem aquest requisit. Això és la paginació.

Abans d'arribar a la paginació, hi va haver un intent intermedi amb una motivació diferent: que la memòria reflecteixi com el programador veu el seu programa.

Un programa no és un bloc uniforme de bytes. És un conjunt de peces lògiques: el codi, les dades globals, la pila, el monticle, cada biblioteca. La segmentació dona a cadascuna el seu propi espai, amb la seva pròpia mida i els seus propis permisos.

Una adreça segmentada té dues parts:

I la traducció fa servir una taula de segments per procés, amb una base i un límit per cada segment:

Traducció de <2, 0x1000> (segment 2, desplaçament 4096):

Traducció de <1, 0x3000> (desplaçament 12.288 al segment de dades de 8 KB):

Els avantatges de la segmentació sobre base i límit simples són reals:

• Protecció per segment. El segment de codi és r-x: un intent d'escriure-hi falla. Això és exactament el que impedeix que un desbordament de memòria intermèdia sobreescrigui instruccions.
• Compartició natural. El segment 4 (libc) pot apuntar a la mateixa base física en 180 processos. Una sola còpia de la biblioteca a la RAM.
• Creixement independent. El monticle pot créixer sense haver de moure la pila.
• Coincideix amb l'estructura del programa, cosa que facilita la feina a l'enllaçador i al depurador.

Però conserva el pecat original: cada segment continua sent contigu en memòria física, així que la fragmentació externa persisteix. Només es redueix, perquè els segments són més petits que un procés sencer.

A x86-64 la segmentació existeix però està essencialment desactivada: els segments de codi i dades abasten tot l'espai d'adreces (model flat), i només sobreviuen els registres FS i GS, que es fan servir per a l'emmagatzematge local del fil i per a dades per CPU al nucli. La història va triar la paginació.

Última peça de l'esquema clàssic: què fer si els processos actius no hi caben tots a la RAM?

L'intercanvi (swapping) consisteix a treure un procés complet a disc i tornar-lo a portar quan li toqui executar-se. És la funció del planificador de mitjà termini que vam esmentar a 02-02.

El cost és brutal. Amb un disc mecànic a 100 MB/s:

Vint segons durant els quals l'agregador no existeix. Amb un SSD NVMe a 3.000 MB/s baixaria a 0,67 segons, millor però encara desmesurat comparat amb els microsegons d'un canvi de context.

Per això l'intercanvi de processos complets és pràcticament mort. El que fan els sistemes moderns és intercanviar pàgines individuals de 4 KB, no processos sencers: si l'agregador té 1 GB però només fa servir activament 30 MB, s'expulsen les pàgines inactives i es queda la resta. Això ja és memòria virtual, i és el tema central de la lliçó vinent.

Tot i així, l'intercanvi clàssic continua viu en un cas concret: la hibernació. Quan suspens un portàtil a disc, el sistema escriu tota la RAM a l'àrea de swap. És exactament el mateix mecanisme, aplicat a la màquina sencera.

Recapitulem el problema central. La fragmentació externa existeix perquè exigim que l'espai d'un procés sigui contigu en memòria física. La compactació intenta arreglar el símptoma. La paginació ataca la causa:

I si un procés no hagués d'estar contigu en memòria física?

La idea, en tres passos:

1. Divideix la memòria física en trossos iguals i petits anomenats marcs (frames), típicament de 4 KB.
2. Divideix l'espai lògic de cada procés en trossos de la mateixa mida anomenats pàgines.
3. Col·loca cada pàgina en qualsevol marc lliure, sense importar l'ordre. Una taula de pàgines per procés registra quina pàgina és a quin marc.

Les conseqüències són enormes:

Aquest últim punt és el que cal resoldre bé, i no és trivial: si cada accés a memòria requereix consultar la taula de pàgines, que també és a memòria, cada accés costaria el doble. La solució és la TLB, i tot el mecanisme —taules multinivell, bits d'estat, fallades de pàgina, algorismes de reemplaçament— és el que desenvoluparem en detall a Memòria Virtual i Paginació.

De moment queda't amb la idea central: la paginació funciona perquè uniformitza la mida dels blocs. Quan totes les peces són iguals, el problema d'encaixar-les desapareix.

Tot l'anterior deixa de ser teoria tan bon punt llegeixes /proc/<pid>/maps. Vegem el de l'ingestor:

El format de cada línia, camp a camp:

• Rang: adreces lògiques d'inici i final (el final no s'hi inclou).
• Permisos: r lectura, w escriptura, x execució, i p privada (copy-on-write) o s compartida.
• Desplaçament: en quin punt del fitxer comença aquest mapatge.
• Dispositiu i inode: quin fitxer s'ha mapejat (00:00 i 0 si no és un fitxer).

Ara la interpretació regió per regió, que és on hi ha tot l'aprenentatge:

Cinc observacions que mereixen atenció:

1. Cap regió no és alhora escrivible i executable. Aquesta separació estricta s'anomena W^X (write xor execute) i és una defensa fonamental: encara que un atacant aconsegueixi injectar codi al monticle o a la pila, no el podrà executar perquè aquestes regions no tenen el bit x. És una aplicació directa de la protecció per regió que vam veure a segmentació, implementada aquí sobre pàgines. Tornarà al mòdul 5.

2. El binari ocupa quatre regions, no una. El carregador ELF separa les seccions segons els seus permisos, exactament pel que hem dit.

3. libc apareix amb la mateixa estructura de quatre regions, i les seves parts r-xp estan compartides físicament amb els altres 179 processos del sistema. Una sola còpia del codi de libc a la RAM serveix per a tots. Aquí hi ha la compartició que la segmentació prometia, aconseguida amb paginació.

4. [vdso] és un truc brillant. El nucli mapeja un petit tros del seu propi codi a l'espai de cada procés, perquè crides molt freqüents com gettimeofday() o clock_gettime() es resolguin sense creuar al mode nucli. Recorda el cost del syscall que vam calcular a 01-06: entre 50 i 500 ns. El vDSO el redueix a uns pocs nanosegons, i per això existeix.

5. La pila és a 0x7ffd... i el codi a 0x0040..., amb un abisme entre tots dos. Aquest forat enorme no costa res: són adreces lògiques sense traducció assignada, i no consumeixen ni un byte de RAM. Reservar espai d'adreces és de franc; només costa la memòria física efectivament suportada.

pmap presenta el mateix amb les mides ja calculades, cosa que és més còmoda en el dia a dia:

Les tres columnes numèriques diuen coses molt diferents i confondre-les porta a diagnòstics equivocats:

• Kbytes: espai d'adreces reservat. És la suma que dona el VSZ de ps.
• RSS: quant d'això és realment a la RAM. Fixa't en libc.so.6: reserva 1.568 KB de codi però només 692 KB estan carregats. La resta són funcions de libc que aquest procés no ha cridat mai, i que per tant mai no s'han portat del disc.
• Dirty: pàgines modificades, que no es poden descartar sense escriure-les abans en algun lloc. El codi mai no està brut (mai no es modifica), així que es pot expulsar sense cost: si torna a caldre, es torna a llegir del binari.

Aquesta distinció entre pàgina neta i bruta és la que governa què s'expulsa primer quan falta memòria, i és una de les claus de la lliçó vinent.

Confondre fragmentació interna amb externa. Regla mnemotècnica: la interna és dins del que t'han donat (et sobra lloc al teu bloc); l'externa és fora, entre blocs aliens (hi ha lloc però no en un sol tros). Particions fixes i paginació produeixen interna; particions variables i segmentació, externa.

Creure que VSZ és la memòria que fa servir un procés. No ho és. Un procés pot reservar 100 GB d'espai d'adreces en una màquina de 8 GB sense problema, perquè les adreces són de franc. La memòria real és RSS, i encara així amb matisos: les pàgines compartides de libc es compten al RSS de tots els processos que la fan servir, així que sumar els RSS dona un total molt superior a la RAM instal·lada.

Pensar que el millor ajust és el millor. El nom enganya. Deixa engrunes inservibles i obliga a recórrer tota la llista de forats. El primer ajust és igual de bo en aprofitament i força més ràpid.

Assumir que segmentació i paginació són alternatives excloents. Històricament es van combinar: x86 de 32 bits feia segmentació i paginació (l'adreça passava per la taula de segments i el resultat per la de pàgines). A x86-64 la segmentació va quedar reduïda a un model pla, però no va desaparèixer del tot: FS i GS continuen fent-se servir.

Interpretar malament una "violació de segment". El missatge és històric i confon: avui gairebé sempre significa que s'ha accedit a una adreça sense traducció vàlida a la taula de pàgines, no a un segment fora de límits. Per diagnosticar-la, compara l'adreça que ha fallat amb les regions de /proc/<pid>/maps: si cau en un forat, és un punter corrupte; si cau en una regió r--p i era una escriptura, és un intent d'escriure en memòria de només lectura (típicament, modificar una cadena literal).

Consell pràctic: quan un procés "consumeix molta memòria", l'ordre correcte d'investigació és pmap -x <pid> per veure quina regió creix. Si creix [heap], és malloc sense free. Si creixen regions [anon] soltes, són blocs grans mapejats amb mmap. Si creix [stack], hi ha recursió descontrolada. Cada cas té una causa i un arranjament diferents, i el mapa t'ho diu sense tocar el codi.

meteo-01 té els forats lliures següents, en aquest ordre de memòria:

Arriben aquestes peticions, en ordre: A = 230 MB, B = 140 MB, C = 310 MB, D = 190 MB.

1. Resol l'assignació amb primer ajust, millor ajust i pitjor ajust.
2. Per a cada estratègia, indica quantes peticions se satisfan i quina és la fragmentació externa resultant.
3. Quina hauria funcionat millor? Pots concloure d'aquí quina és superior en general?

Els quatre processos de Meteora necessiten: ingestor 180 MB, agregador 490 MB, meteo-api 300 MB, backup 60 MB.

1. Calcula la fragmentació interna total amb particions fixes de 512 MB.
2. Calcula la fragmentació interna total amb paginació de 4 KB, suposant que cada procés té 15 regions de memòria.
3. Compara tots dos resultats en valor absolut i percentatge.
4. Explica per què la paginació no produeix fragmentació externa.

Aquest és el mapa resumit de meteo-api després de 22 hores en marxa:

1. Quina regió domina el consum i què representa probablement?
2. La regió de libssl.so.3 reserva 1.024 KB però només té 12 KB a la RAM. És un problema? Per què passa?
3. El mode de /dev/shm/meteora-cache és rw-s-. Què significa la s i què implica?
4. Si el sistema necessités alliberar memòria urgentment, quines pàgines d'aquest procés podria expulsar sense escriure res al disc? Calcula quants KB són.
5. Amb aquestes dades, diries que meteo-api té una fuita de memòria? Justifica quina comprovació faries.

Solució 1

Primer ajust (el primer forat on hi càpiga, recorrent des d'H1):

4 de 4 satisfetes. Forats finals: 10, 170, 10, 60, 180 = 430 MB lliures, bloc més gran 180 MB.

Millor ajust (el forat més petit on hi càpiga):

4 de 4 satisfetes. Forats finals: 10, 210, 20, 10, 180 = 430 MB lliures, bloc més gran 210 MB.

Pitjor ajust (el forat més gran):

3 de 4 satisfetes. C queda sense servir tot i haver-hi 930 MB lliures abans d'intentar-ho.

Resum:

3. Anàlisi. Primer i millor ajust empaten en peticions servides; el millor ajust deixa el bloc contigu més gran una mica més gran (210 davant de 180), cosa que li dona un avantatge marginal per a una petició futura.

El pitjor ajust falla, i la seva fallada és instructiva: en destinar el forat de 400 MB a una petició de 230 MB, va destruir l'únic forat on després hi hauria cabut C (310 MB). Aquesta és la crítica de fons al pitjor ajust: consumeix sistemàticament el recurs més escàs, que són els forats grans.

Es pot concloure quina és superior en general? No. Aquest exercici mostra una seqüència concreta. Canviant l'ordre de les peticions el resultat s'inverteix: si C arribés primer, el pitjor ajust la serviria sense problema. Les conclusions vàlides vénen de simulacions amb milers de seqüències aleatòries, i aquestes diuen que primer i millor ajust són estadísticament equivalents en aprofitament, que el primer ajust és més ràpid —no recorre tota la llista— i que el pitjor ajust és sistemàticament inferior. El primer ajust guanya per velocitat, no per aprofitament.

Solució 2

1. Particions fixes de 512 MB.

Gairebé la meitat. I observa com de desigual és el repartiment: l'agregador (490 MB) malbarata només 22 MB, mentre que backup (60 MB) en malbarata 452. La fragmentació interna amb particions fixes castiga desproporcionadament els processos petits, que són majoria en qualsevol sistema real.

2. Paginació de 4 KB amb 15 regions per procés.

La clau del càlcul: dins d'una regió, totes les pàgines són plenes tret de l'última, que de mitjana s'omple fins a la meitat.

3. Comparació.

La diferència no és de grau, és de naturalesa. I la raó és purament aritmètica: el malbaratament per fragmentació interna és proporcional a la mida del bloc d'assignació. Amb blocs de 512 MB malbarates fins a 512 MB per procés; amb blocs de 4 KB malbarates com a molt 4 KB per regió. Reduir el bloc en un factor de 131.072 redueix el malbaratament en la mateixa proporció.

Això també explica per què les pàgines grans (2 MB) no són de franc: milloren la TLB però multipliquen per 512 la fragmentació interna. Ho veurem a la lliçó vinent.

4. Per què la paginació no produeix fragmentació externa.

La fragmentació externa apareix quan hi ha prou memòria lliure però no en un bloc contigu de la mida necessària. Requereix dues condicions simultànies:

1. Que les peticions tinguin mides diferents.
2. Que l'assignació hagi de ser contigua.

La paginació elimina totes dues:

• Totes les unitats fan exactament el mateix (4 KB), així que qualsevol marc lliure serveix per a qualsevol pàgina. No existeix el concepte de "no hi cap": si hi ha un marc lliure, la pàgina hi cap.
• No s'exigeix contigüitat: les pàgines 0, 1, 2 i 3 d'un procés poden ser als marcs 847, 12, 5.301 i 92. La taula de pàgines s'encarrega que el procés vegi un espai continu.

Formulat de manera exacta: amb paginació, si hi ha N marcs lliures, es pot satisfer qualsevol petició de fins a N pàgines, sense importar on siguin aquests marcs. Aquesta garantia és impossible amb assignació contigua, i és la raó per la qual també desapareix la necessitat de compactar.

Solució 3

1. La regió dominant.

118.784 KB = 116 MB, el 88 % del RSS total del procés (118.784 de 135.140). És memòria anònima —no suportada per cap fitxer—, escrivible, privada, i amb RSS = Kbytes = Dirty: és sencera a la RAM i sencera modificada.

Que comenci a 0x1a40000, just per damunt del binari, indica que és el monticle expandit amb brk (o una arena gran de malloc). Per la seva mida i pel fet de tractar-se de meteo-api, el més probable és una memòria cau de respostes o un conjunt de lectures carregades en memòria per servir consultes sense tocar /var/lib/meteora/lectures/.

Un contrast útil: 116 MB a 24 bytes per Lectura són uns 5,07 milions de lectures, prop de set dies de dades a 800 lectures/segon.

2. La regió de libssl.so.3 amb 12 KB d'1.024 KB.

No és cap problema: és exactament el que ha de passar.

Passa per la paginació per demanda: quan es mapeja una biblioteca, el nucli no llegeix el seu codi del disc. Només crea les entrades a la taula de pàgines marcades com a no presents. Una pàgina es porta del disc únicament quan el procés intenta executar-la i es produeix una fallada de pàgina.

meteo-api ha fet servir 12 KB (tres pàgines) d'OpenSSL. Tota la resta —algorismes de xifratge que no fa servir, funcions de gestió de certificats, codi de compatibilitat— no s'ha tocat mai i per tant mai no ha ocupat RAM.

L'estalvi agregat és enorme: si 20 processos mapegen libssl i cadascun fa servir unes poques pàgines diferents, el consum real és una fracció mínima dels 20 × 1.024 KB nominals. I com que el codi és de només lectura, les pàgines que sí que es carreguen es comparteixen entre tots.

3. El mode rw-s-.

La s significa compartida (shared), davant de la p de privada que porten totes les altres. La diferència és fonamental:

Com que és sobre /dev/shm/ (un sistema de fitxers a la RAM), es tracta de memòria compartida entre processos: probablement els quatre treballadors de meteo-api que vèiem al pstree de 02-01 comparteixen una única memòria cau de 8 MB en lloc de tenir-ne quatre còpies.

Implicació important: escriure-hi des de diversos processos alhora exigeix sincronització. Sense ella, dos treballadors actualitzant la mateixa entrada la corromprien. Aquest és precisament el terreny del mòdul 3.

4. Pàgines expulsables sense escriure al disc.

Són les pàgines netes (Dirty = 0) suportades per un fitxer: si tornen a caldre, es tornen a llegir del binari original, així que descartar-les és de franc.

Només 692 KB de 135 MB. I aquí hi ha la lliçó incòmoda: el 99,5 % de la memòria d'aquest procés és anònima i bruta, així que alliberar-la exigeix escriure-la a l'àrea de swap, amb el cost de disc que això implica. Si meteo-01 no tingués swap configurat, aquesta memòria seria directament irrecuperable i el sistema hauria de recórrer a l'OOM killer.

Nota addicional sobre els 512 KB de /dev/shm: com que resideixen en tmpfs, no tenen suport al disc; només poden anar a swap, mai no es poden descartar.

5. Hi ha fuita de memòria?

Amb aquestes dades no es pot afirmar. Una foto no distingeix una memòria cau legítima d'una fuita: totes dues es veuen igual, com una regió anònima gran i bruta.

La comprovació correcta és mesurar l'evolució en el temps:

La interpretació de la sèrie resultant:

Un càlcul que orienta des del primer moment: 116 MB després de 22 hores són uns 5,3 MB/hora. Si aquest ritme fos constant, en una setmana serien 890 MB i en un mes 3,8 GB, cosa que en una màquina de 8 GB acabaria a l'OOM killer. Que la resposta depengui de si el ritme es manté o s'aplana és justament el motiu pel qual cal mesurar dues vegades.

Comprovacions complementàries: pmap -x repetit per veure quina regió creix; sudo cat /proc/1901/status | grep VmPeak per conèixer el màxim històric; i al codi, revisar si la memòria cau té una política d'expulsió o creix sense límit, que és la causa més freqüent d'aquest perfil.

Gestionar la memòria significa resoldre alhora reubicació, protecció, compartició, organització lògica i capacitat, i amb una restricció duríssima: la protecció s'ha de comprovar a cada accés, cosa que obliga a resoldre-la en maquinari.

La peça clau és la separació entre adreces lògiques i físiques. Vincular-les en temps d'execució —i no en compilació ni en càrrega— és el que permet que la MMU tradueixi a cada accés, que un procés es pugui moure, que existeixi ASLR i que dos processos facin servir la mateixa adreça 0x401000 sense trepitjar-se. L'esquema mínim que ho aconsegueix són els registres base i límit: una comparació i una suma, protecció completa, i impossible d'eludir perquè només es poden carregar des del mode nucli.

L'assignació contigua —particions fixes o variables, amb primer, millor o pitjor ajust— funciona però xoca contra la fragmentació: interna (fins al 49,7 % de l'espai assignat en el nostre càlcul amb particions de 512 MB) o externa (fins a un terç de la memòria, per la regla del 50 %). La compactació la resol, però costaria 40 ms cada vegada, així que no és una solució. La segmentació va aportar el millor de l'assignació contigua —permisos per regió i compartició— sense curar la fragmentació externa, i l'intercanvi de processos complets va morir tan bon punt es van fer els números: 20 segons per un agregador d'1 GB.

La sortida no va ser millorar l'assignació contigua, sinó abandonar el requisit de contigüitat. Si totes les peces fan el mateix, encaixar-les deixa de ser un problema: això és la paginació. I tot això deixa de ser teoria en llegir /proc/<pid>/maps i pmap -x, on veus codi compartit i no escrivible, libc amb només el 44 % del seu codi realment carregat, W^X protegint pila i monticle, i la diferència entre Kbytes, RSS i Dirty que decideix què es pot expulsar i què no.

Queda la part gran: com funciona realment la paginació. Com es tradueix una adreça amb número de pàgina i desplaçament, per què una taula plana de 64 bits seria impossible i com ho arreglen les taules multinivell, què és la TLB i quant rendiment en depèn, què passa exactament quan una pàgina no és a la RAM, quina pàgina expulsar quan no queda forat i per què un sistema pot entrar en hiperpaginació i deixar d'avançar. Tot això, i mmap() mapejant 2026-08-31.dat en memòria, és a Memòria Virtual i Paginació.