A szabad memóriához azért pár félmondatot hozzá tennék: tök jó dolgok ezek a mutatók, de önmagukban gyakorlatban (ameddig nem kell elemezni valamit, hogy mennyi az annyi), nem túl érdemlegesek vagy informatívak, főleg az ilyen "mennyi a szabad ramom" kijelentésűek. A 386-os óta elérhető a védett mód, ahol minden egyes program saját címtérrel rendelkezik (és ma már minden OS így működik). Ennek egyik nagy előnye, hogy a háttérben lehet egy csomó okos dolgot művelni: ha már egyszer betöltöttünk egy shared libet, elég csak a második appnak a címterébe belemapelni, nem kell újra betölteni, stb. Egy ilyen eset az appnak a teljes memóriafoglalásába beleszámít, de gyakorlatban nulla byte plusz memóriát foglaltunk le neki.
Másik eset a file cache. Ma minden modern OS azt cachel, amit lehet. Hacsak az embernek nincs 32G ramja, akkor jó eséllyel átlag felhasználás mellett közel 0 byte szabad ramja van, ugyanis az OS megeszi azt file cachenek. (Windows, Linux, BSD, OSX, minden.) Természetesen, ha valami program igényel ramot akkor ennek a cachenak a kárára feláldozható. (Bár intenzív IO esetén dönthet úgy is a rendszer, hogy inkább egy-két alvó programot söpör ki a swapba, mert egy fél óránként egyszer felébredő folyamat visszaráncigálása még mindig kevésbé teljesítmény-igényes feladat, mintha valami, ami folyamatosan lemezről dolgozik tényleg a lemezről dolgozna).
(Apró intermezzo: XP óta létezik prefetch Windows vonalon, ami a rendszer az alapján, hogy mikor mit használsz sűrűn előtölthet neked cacheba dolgokat. Azt is valahova a ramba kell raknia nyilván, persze te azt szabadnak látod. Attól még valójában foglalt.)
Harmadik dolog, ami nem kicsit (és külső szemszögből nézve teljesen megjósolhatatlanul) meg tudja bolondítani a "mennyi az annyi?" kérdést a programok saját memóriamenedzsmentje. Ebben különösen élen járnak a menedzselt memóriakezeléssel rendelkező megoldások (pl. .NET vagy a Java), de alapvetően a dolog független ettől simán elképzelhető egy natív programnál is az a viselkedés, hogy monitorozza mennyi a szabad memória és eszerint változtatja meg a program működését, pl. hogyha sok a szabad ram, akkor többet cachel, ha fogy, akkor meg visszavesz. Tudnám hozni példának a nálunk futó MSSQL/Terminal szervert: a ramnak kb. 97%-a van kihasználva folyamatosan (a 12G ramból), aminek a nagyját az MSSQL eszi meg. Azonban, ha látja, hogy valami másnak is kellene ram, akkor azért visszavesz és felszabadít valamennyi cachet. De nem kell szerver oldalra menni, egy játék is simán működhet így: ha kevés a ram, hamarabb kidobálja a nem látható objektumok modelljeit, textúráit, szemben ha van sok ram, akkor nem dobja ki, hátha a következő pályán is kell. De akár egy szövegszerkesztő is működhet így: ha sok a ram, betölti előre a helyesírás-ellenőrzőt, ha nem, akkor mondjuk csak akkor, amikor tényleg használjuk is. Stb.
Ezt hívják egyébként skálázódásnak. Ez az, amit sokan nem vesznek figyelembe, mikor egy OS-ről nyilatkoznak. Pl. gyakori érv a Windows ellen, hogy "jaj, van 4G ramom, és X-et megesz belőle!!!444". Ja, de azért, mert 4G ramból még mindig mondjuk 2-3G marad az appnak 0. körben, amit egyből használhat, szemben 2G-n, ahol mondjuk csak 1G-re skálázza magát alapból (amiből mondjuk szükség esetén még mindig dobálhat vagy swapolhat ki) és 1G maradt csak a programnak (az értékek hasraütésszerűek.)
Így meg igazából az érdekes számunkra, hogy az adott program nyafog-e vagy sem, az, hogy mennyi a memóriafoglalás, az önmagában nem annyira érdekes infó.
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™