Pár gondolat a memóriáról

Nem rég IRC-en belekeveredtem egy vitába. A vita kiindulópontja az volt, hogy "iszonyú sok" az, hogy 7,7G ram volt kihasználva a gépemen (+12G cachelve). Mi foglalt 7,7G-t? Két pluginekkel jól megpakolt Visual Studio solutiononként kb. 40-50 projekttel, a fejlesztés alatt lévő szerver és kliens, egy PostgreSQL, Skype, egy jó sok lappal megnyitott Firefox (önmagában vagy 1-1,5G) meg még néhány aprólék. Az itthoni gépemben 32G ram van. Engem az se érdekelt volna, ha 31G-t használ ki.

Munkahelyi gépemben 8G ram van, ugyanez a felállás néhány egyéb dologgal megtoldva (3-4 excel, 1-2 word, outlook, eclipse, meg még néhány egyéb bazár) nagyjából ugyanúgy 7-7,5G ramot szokott kihasználni (bár ott már rak dolgokat a swapba is). Egyébként ugyanúgy nem érdekel, hogy 4G vagy 7G-t használ ki.

Miért nem érdekel? Mert azért van a RAM a gépben, hogy használni lehessen. Igen, fontosnak tartom, hogy feleslegesen ne pazaroljon memóriát egy program. Ez trivialitás. Viszont ha van elég szabad ram a gépben, akkor igenis használja, ha ezzel gyorsabb lesz a munkám. Mert végső soron nem azért pattintok be 32G ramot a gépembe, mert túl sok pénzem volt és nem tudtam vele mit kezdeni, hanem azért, hogy ha rákattintok valamire, akkor az tegye a dolgát. Azonnal.

1-2 hete kellett konfigolnom picit egy MySQL memóriabeállításait. Katasztrófa. Ilyen globális buffer, olyan globális buffer, ilyen /connection buffer, olyan /connection buffer. Aztán számoljam össze, hogy ennyi meg annyi plusz connection*(amannyi meg azamannyi). Ki a pöcsöm akar ezzel szenvedni? Miért nem képes adaptívan alkalmazkodni a géphez? Normális esetben ez úgy nézne ki, hogy megmondom, hogy ennyi max connection meg maximum ennyi G/% ramot használhat ki és csókolom, oldja meg magának úgy, ahogy épp szüksége van. (Sajnos, e téren a PostgreSQL sem áll jobban és ott kivételesen a multi process architektúra sem kedvez ennek). Akárhányszor belépek az egyik MSSQL-es szerverünkre mindig azt látom, hogy 97%-on van a RAM kihasználtsága. Függetlenül attól, hogy 1 adminisztrátor vagy 10 user van benn még terminal servicen, mert távolról kell használnia az ügyviteli rendszert.) Sokkal-sokkal inkább követendő módszer. (Hozzáteszem: csak usere vagyok annak az MSSQL-nek, nem tudom milyen memória konfigurációkat enged, de a konstans 97%-ból következtetek arra, hogy viszonylag adaptív tud lenni, mint ahogy a Windows esetén is látok arra utaló jeleket, hogy alkalmazkodik, hogy mennyi RAM van a gépben.)

Szóval ennyi, az számít, hogy mennyire hatékonyan használja ki a RAM-ot egy program, nem az, hogy mennyire keveset használ. Az a RAM modul, amit az ember nem használ semmire (még akár file cachera sem), az nem más, mint kidobott pénz.

( deje | 2014. 04. 03., cs – 21:05 )

+1

Kíváncsi leszek, mennyire borítja majd fel az operatív tár/háttértár párost a memristor :)

( Boobek | 2014. 04. 04., p – 11:23 )

Félig meddig egyet értek. De én azért szeretem, ha van még szabad ram, mert:
- tudok új programot indítani, és az nem lassítja a rendszert.
- nem kezdi a gép tömöríteni a memória tartalmát
- nem használ swapet.

Persze a 2. és 3. az konfigolható, de nem szeretek konfigolni :)

Bizonyos szempontból meg azért mérnökibb, ha már egy adatbázis szerverről van szó, hogy ha poolonként be tudod állítani a memória használatot, mert így tervezhetőbb a szerver upgrade. Nem?

Akkor látom, nem értetted meg az MSSQL-es példát. Miért lassítaná a gépet? Pont, hogy gyorsítani tudja az, hogy a memóriában van készen, amit esetenként (újra) ki kellene számolni vagy (újra) betölteni a lemezrő.

Swapról, memóriatömörítésről (toplel eleve) meg senki nem beszélt. Arról volt szó, hogy _HA_ van szabad memória, akkor használja nyugodtan. Ha másnak is kell, vegye vissza magát. (Ld. MSSQL-es szerverünk, ami mindig 97%-ra próbálja belőni: ha több másik programnak is kell RAM, akkor visszavesz).

"mert így tervezhetőbb a szerver upgrade. Nem?"

Miért lenne? Most mit csinálsz egy My/PgSQL esetén? Kézzel szötymörögsz különféle konfig beállítások finomhangolásán (aminek automatikusan kellene történnie) és az alapján megpróbálod megsaccolni, hogy mennyi RAM kellhet. Aztán hozol egy döntést, hogy elégséges-e a sebessége vagy még lehet tuningolni plusz RAM hozzáadásával. A helyzet attól, hogy megadhatod, hogy a RAM X%-át használja a rendszer nem változik, csak a finomhangolással való szöszölés terhét veszi le a váladról.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem azt mondtam, hogy tökéletes a mysql memória beállítása, azt mondtam, hogy ha tudod mennyi kell egy poolnak, és azt is hogy neked mennyi pool kell a jövőben várhatólag, azzal lehet kalibrálni.

A swap, mem tömörítést az én laposomon mondtam, ami mondjuk egyértelműen nem szerver, csak van benne memória ... :)

Azt a részét nem tudom viszont, hogy a programok és az oprendszer között van-e linuxon, windowson olyan opció, ami olyan cachere ad lehetőséget, ami alkalmazásával a program felszabadítja maga a memóriát, amennyiben az oprendszer arra kéri dióhéjban. Mert gyakorlatilag, ha jól vettem ki szavaidból, te ezt a megoldást pártolod.

Szerintem pont nem. Egyrészt sokban egyszerűsíti a munkát az, hogy nem kell kézzel matatni azt, hogy egyes alkalmazások merre hány méter (persze, néha nem árt), másrészt meg sokszor szimplán nem foglalkoznak vele, mert "úgy is működik". (Igen, van, ahol igen, de a gyakorlat inkább az, hogy max ha baj van).

Egyébként nem feltétlen cache. Az már program szempontjából csak egy adat. Lehet akár például egy játék pályája, modellje, textúrája is. Hogy őszinte legyek, alapvetően egyvalami számít itt, az pedig az, hogy mennyi szabad ram van. Azt meg azért a legtöbb rendszer viszonylag egyszerű API-n keresztül visszaadja.

Viszont úgy nézem, hogy Windowsra van valami ilyesmi:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366541%28v=vs…

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt a reszet alairom, hogy lehetne szebb, ellenben attol rosszul vagyok amikor megy kb 4 program es elinditanek egy otodiket es annak hirtelen mar csak a swapben van hely (ez altalaban desktopon problema, de baromira idegesito es egyre altalanosabb 32 giga ram mellett is). Egy desktop app foglaljon annyi ramot, amennyi a tokeletes es reszponziv mukodesehez kell, nem kell nekem hogy becache-eljen olyan dolgokat ahol elhanyagolhato a sporolas, mert a legvegso problemat majd ugy is az okozza, hogy ki kell irni IO-ra is a vegeredmenyt, epp eleg gyors ma mar a memoriakezeles, mikozben az "ez most barmikor eldobhato cache ha uj programot inditanal, ami kell memoria mas indulo programnak" kerdeskor meg eleg gyengen megoldott es tobbet veszitesz vele, mint nyersz (foleg hogy ezerfele nyelven irsz egy platformra alkalmazast, ki birja mar kovetni hogy ki mikor engedheti at masik processznek a memoriat?). OS X egy nagyon jo rendszer, de indits el rajta 5-6 nagyobb programot (pl IDE-t), fussanak egy napig, hiznak ok nelkul a memoriaban a kernel taskkal egyutt, mig vegul azon kapod magad, hogy minden uj program tetulassan nyilik meg. Tenyleg olyan jo ez? A 8 giga ramos macbook airem erezhetoen lassabb ha sok program fut, mint a 4 giga ramos matricas laptopom linux-szal (ugyanazokat a nyilt forrasu programokat futtatom tobbnyire, kulonbseg az xcode kb egyedul)

Meg akkor szerinted az nginx is szar mert el van 2 mega rammal ha percenkent kap egy requestet (azon a gepen pont fejlesztesre hasznalom, azert ilyen ritka)? Hetek ota fut, azota is annyin all, es igy is meg tudtak oldani, hogy azonnal reagaljon mindenre. Ha egy program attol lesz gyorsabb hogy a vilag osszes memoriajat elfoglalja maximalisan fix nagysagu adatszerkezetekre, az tervezesi hiba. Pont.

Nem nevezném feltétlenül tervezési hibának. Csak gondolom, voltak fontosabb dolgok, mint a memóriakezelés automatizálása.
Lásd Oracle RDBMS! Már nem emlékszem, hogy a 9-es vagy 10-es verzióban jött elő egy már(-már) használható, automatikus memória kiosztás, korábban mindent neked (=DBA) kellett hangolgatni, ha emberi működésre vágytál és nem volt annyi memóriád, mint az ország többi számítógépében összesen. :D
Arról nem beszélve, hogy hatékonyan automatizálni a memóriakezelést egy adatbázis kezelőnél, nem kifejezetten triviális feladat.

Az RDBMS-ekkel kapcsolatban Saxusnak 99%-ban igaza van (picit kiveve abban hogy egeszseges az MSSQL fele 97% automatan, mit csinalsz ha hirtelen mellette az IIS vadul elkezd requesteket kapogatni, swappelsz? Na jo, az IIS-nel meg talan "hazon belul" meg van oldva az "aggya'ma'memoriat, de ha teszem azt egy apache-ot futtatsz a Windows serveren? Ott aztan mire atparse-oljak egymasnak a programok a rendszer kozt hogy "valakinek kene valahonnan memoria", az ugy nem eppen lesz optimalis, annyit nem ert az a db cache-eles). Az RDBMS hasznaljon annyi memoriat, amennyi a csovon kifer (amennyit megengednek neki, de szerintem ne annyit, amennyit "talal a rendszerben"). Desktop appoknal viszont tervezesi hiba amit mondok egyertelmuen (igen, tudom hogy pont az nginx-et hoztam peldanak ami nem az).

Ellenben ami rendszerszinten megy az utobbi idokben az OS X-nel (10.8 10.9), az is kiborito. Annyira memoriaehes rendszer lett vissazelve azzal hogy a legolcsobb Mac-ben is van 4 Giga, hogy az mar kezd szomoru lenni. Nemreg atmentem egy ismerosomhoz, meg mindig 10.5 van az iMac-jen, es a HDD-s iMac-je tobb napja ment, es eskuszom nektek, ranezesre erezhetoen ezerszer gyorsabb volt mint az ujabbak tobb rammal es SSD-vel. Ott jottem ra, hogy miert is szerettem meg anno az OS X-et. Kar hogy 10.-5on mar nincs naprakesz flash player se meg chrome se meg safari se tudtommal, meg a nemreg vett air-emet nem hiszem hogy tudnam ra downgrade-elni.

Az említettek többségével nem volt dolgom, DEC Rdb-t üzemeltettem, meg Oracle-t. Előbbinél nem nagyon kellett magában az RDBMS-ben matatnom, max. az op.rendszer paramétereket és user kvótákat kellett állítgatni, utóbbinál meg nagyon sokáig teljesen manuálisan ment minden, de általában elég volt egyszer belőni, oszt jónapot! :)

Erre panaszkodott Saxus is (ebben is pont igaza van), hogy ezer meg ezer dolgot kell atkonfigolni hogy milyen memoria mennyi lehet, holott o azt akarna, hogy automatan foglalja el az rdbms az arra szant szerver 97%-at, en meg ezzel majdnem teljesen egyetertek, en annyit varnek el egy rdbms-tol, hogy megadhassam neki hogy "use_total_memory_automatically = true; total_memory_for_everything = 30G" pl. 32 Giga ramos szerver eseten (es ezt kesobb lejjebb tudjam venni kezzel, ha hirtelen valaki kitalalja hogy meg ezt meg azt meg amazt is futtasson a szerver, es tenyleg csak a total_memory_for_everything-et kelljen ehhez atirnom).

Ezt én értettem. Csak azt próbálom magyarázni, hogy egyrészt nem feltétlenül ennek van a legnagyobb prioritása egy fejlesztés esetében, másrészt egy jól működő algoritmust kidolgozni nem egyszerű, ha kellőképp bonyolult az adatbáziskezelő.
Újabb oracle-kben van olyan, hogy százalékosan megadod, mennyi memóriát használhat és ha jól emlékszem, mindent automatikusan tud kezelni. (bocs, több, mint hat éve nem láttam ilyet, szóval tévedés joga fenntartva ;) )
Az említett MySQL/Postgresql még a közelében sincs technológiailag. Valószínűleg fontosabb mondjuk az optimalizáló, esetleg az SQL tárolt eljárások képességeinek, egyéb extra feature-öknek a fejlesztése, mint az, hogy a DBA-t megkíméljék egy kis fejszámolástól.

Nem mondom, hogy saxusnak nincs igaza, csak egy ingyenes szoftvertől nem várok feltétlenül annyit, amennyit egy drágább rendszertől.

A lényeg hogy ott is be lehet állítani csak bonyolultabban :) Na de remélhetőleg majd ott is megoldják.

De az Oracle tényleg teljesen más kategória, sokmilliárd rekord esetén megkerülhetetlen, ugyanakkor pont a sokmilliárd rekord miatt ott pont az volt az átlagos, hogy van valaki, aki ért hozzá annyira, hogy ezeket beállítja. Szóval inkább ott érzem kesvésbé szükségesnek az "automata x MB max" módot (persze ott is jó, hogy végre van).

> picit kiveve abban hogy egeszseges az MSSQL fele 97% automatan, mit csinalsz ha hirtelen mellette az IIS vadul elkezd requesteket kapogatni, swappelsz?

Hát egyrészt igazad van, másrészt azért ahol az IIS-hez tonnaszámra ömlik a request, ott nem biztos, hogy ugyanazon a gépen kéne, hogy legyen a MSSQL. ;)

"picit kiveve abban hogy egeszseges az MSSQL fele 97% automatan, mit csinalsz ha hirtelen mellette az IIS vadul elkezd requesteket kapogatni, swappelsz?"

Semmit, mivel a 97% nem az MSSQL-é, hanem a gép teljes memóriahasználatáé.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Oké, ezt az MSSQL időnként berfissíti, hogy "na van-e új szabad memória, vagy kell-e felaszabadítani, hogy pont 97% legyen", de két frissítés közt ha van egy nagyobb memóriafoglalás, akkor annak swapelés lesz a vége. Márpedig aki eljut oda, hogy olyan gépet üzemeltet, ahol jól kell perofmálnia egy MSSQL-nek, az tudni fogja, hogy mennyi ramot adhat az MSSQL-nek. Meg ha hirtelen az MSSQL elkezd felszabadítani majd újra lefoglalni majd újra felszabadítani meg újra lefoglalni hogy "pont 97% legyen a teljes RAM használat", akkor az biztos hogy hatékonyabb, mint ha adtunk volna neki konstans 30 G-t a 32G-ből? Biztos hogy jó futásidővel helyes döntést hoz hogy melyik cache-t kell eldobni? Maradnék inkább az általam említett "légyszi használj ennyi memóriát és próbáld meg ebből mindet kihasználni" nevű nemlétező(?) settingnél rdbms-eknél, szerintem ez üzemeltetési szempontból midnenképpen szebb megoldás mint az "automatán 97% a teljes memóriahasználat".

"akkor az biztos hogy hatékonyabb, mint ha adtunk volna neki konstans 30 G-t a 32G-ből?"

Úgy, hogy nem fut a swapba a rendszer, ha indul egy másik program, illetve, ha bezárod, az MSSQL ismét ki tudja használni a szabad memóriáját. De pont erről szól az adaptivitás: alkalmazkodik a lehetőségekhez.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

De nem jobb, ha megvan a konstans a 30 Gigaja a 32-bol es akkor nem kell veszeldobasokat csinalnia (ami elott ki kell szamolni, hogy mit is dobjon el valahogy, stb.). Raadasul ez alatt a "veszeldobas" alatt lehet hogy mas program leallokalt sokkal gyorsabban sokkal tobb memoriat, mig az MSSQL ki se talalta a cikulusaiban, hogy mit dobjon el a cache-bol. Es oke, hogy a swapbe nem az uj memoria megy hanema regi, de a swap-be atmasolodas is idobe telik, meg azt is el kell donteni, hogy az egesz memoriabol mi a feleslegesebb. Ezek a ciklusok szerintem egyertelmuen elviszik azt az elonyt osszeadva, amennyit a "picivel tobb cache mint konstans 30/32-ed resze a memorianak" nyujtana.

Nem. Már csak azért sem, mert hamarabb kapsz az OS-től low memory jelzést, mint ahol lenne a swap limit*, így van idő a felszabadításra.

Másrészt semmi nem garantálja, hogy te valóban fel is fogsz szabadítani (mert mondjuk neked tényleg kell a 30G a működéshez). Ilyenkor meg az új program kap egy out-of-memory hibát vagy swappelés lesz. (Aztán tényleg OOM). (vagy Linuxon beindul a gyökér OOM killer, ami továbbra is toplel kategória).

Plusz, az, hogy egy alkalmazás hirtelen kér 1G ramot, az nem jelenti azt, hogy az operációs rendszer egyből oda is adja neki, hanem csak amikor azt tényleg használatba veszi, de akkor is csak kis darabokban. Igen, plusz erőforrás ez, de "valamiért" mégis meglépték ezt még jó régen. Többek között ez is előnye a virtuális memóriacímzésnek (nem összekverendő a swappal).

*Arról nem is beszélve, hogy az OS ettől függetlenül dönthet úgy, hogy akkor is kirak swapba valamit, ha van ram: mert mondjuk csak az idő 1%-ában kell, cserébe az idő 90%-ában futó program több memóriából tud gazdálkodni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pont a csillagos rész miatt nincs swap a Linuxos gépemben. :D (tudom, swappiness 0, de biztosra mentem).

"Másrészt semmi nem garantálja, hogy te valóban fel is fogsz szabadítani" ez ugyanúgy probléma lehet az MSSQL 97%-ánál is, de tény, hogy azért állítom 30/32 GB-ra, hogy a maradék 2GB elég legyen mindennek, ne is kelljen felszabadítani abból ott semmit. Azon a pár %-on amit te nyersz az MSSQL-nél hiába performál jobban egy 2%-nyival több cache, többet vesztesz ha jön egy "új program nyitódott felszabadítunk" folyamat a performanszból.
És pontosan arról van szó, hogyha külön db szerverem van, pontosan tudom, hogy mennyit akarok a dbnek max lefoglalni, és mi más fog ott elindulni és azoknak mennyi kellhet max.

Az "odaadok neki 1G ramot" eset meg nyilvánvaló hogy így van, de ez se változtat semmin, a 30GB a 32-ből esetemben maximumkorlát, nem "kötelező akkorára meghíznia rögtön a db szervernek". Ami a lényeg hogy a 30GB egy max korlát legyen, afölé ne nyúljon a db szerver, és ne kelljen semmit eldobnia, mert tudta aki beállította, hogy a maradék 2 Giga elég lesz minden másnak ami fut a gépen.

Ezzel azt éred el, hogy amikor nem kell a 2G, akkor elpazarolsz 2G-t, cserébe, ha 4G kell, akkor ki fog lógni a swapba. Szerintem ez egy pazarló és nem rugalmas hozzáállás.

(Amúgy olyan érzésem van, hogy te nem vagy egészen tisztában azzal, hogy a felszín alatt mik történnek memóriakezelés címszó alatt).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Igen, tudom hogy ez a végeredmény, csak az én módszerem rugalmatlansága más szempontból ad egy performance pluszt, és egy db szervernél azért általában tudható, hogy sosem fog kelleni más process-re annál a 2G-nél több, és a db szervernek ritkábban kell eldobnia a cache-eit, azelőtt meg vizsgálódni, hogy mit dobjon el.

Már miért tudható? Messze nem csak dedikált adatbázisszerverek léteznek. Képzelj el egy Windows SBS-t, ahol egy gépen van egy Exchange, SQL server, random ügyviteli rendszer, akármi. Vagy akár a te általad említett eset, hogy mi van akkor, ha az IIS kap egy olyan kérést, amihez kell a RAM. Vagy akár egy terminal servert, ahol távolról használják az ügyviteli rendszert.

Egyébként nagyon túlértékeled azt, hogy meddig tart "vizsgálni", hogy mit dobjon el. Normális tervezés mellett gyakorlatilag ott van az, hogy mit kell eldobni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Őszintén szólva szerintem téged az zavar, hogy azt szoktad meg, hogy neked kell ezt állítgatni, ahelyett, hogy rábíznád magad valami automatikus megoldásra. Pedig ezer+1 helyen bebizonyosodott már, hogy hatékonyabb az automatikus megoldás.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerveren igazad lehet (oké, az MSSQL is szerveren fut többnyire), de desktopon azt kell hogy mondjam, eléggé megbukik ez a "használjunk ki minden memóriát" elmélet, ott sokszor "gyorsabban kell" a memória, mert ki tudja ki mikor hány alkalmazást fog valaki egyszerre megnyitni. Persze ott is volt olyan rész amivel egyetértettem (half life következő pálya prefetch ha van hely a memóriában), de azzal hogy a böngésző töltsön ki minden rendelkezésre álló teret, hogy aztán az utána megnyitott IDE kezdjen el swappelni, azzal már nem (sőt, abban is egyetértettünk, hogy az OS X újonnan kegyetlenül pazarolja a memóriát, sokszor performance rovására).

"de azzal hogy a böngésző töltsön ki minden rendelkezésre álló teret, hogy aztán az utána megnyitott IDE kezdjen el swappelni"

Lemérted? Tesztelted? Szerinted meddig tart kivenni egy listából a legutolsó elemet?

Meg mint mondtam: előbb fogsz kapni az OS-től egy low memory eventet, minthogy elkezdjen swapelni.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ezt gyakorlatilag minden nap lemérem, mikor használom a gépeimet, és brutális a különbség. Lehet én vagyok a hülye hogy túl sűrűn nyitok új alkalmazást.

De csak a kedvedért most megnyitottam egy netbeanst, még a Linuxos "nempazarló" gépen is 3 másodperc alatt +350MB allokálva (el is indult a 4. másodperc végére, Mac-en ha nem a gép indulása utáni percekben indítom, még most is várnék rá), biztos hogy ugyanilyen hatékonyan nyitná meg egy gép, amiben épp 100 mega ram van szabadon (ebben több mint 2 giga volt neki)?

Ami más alkalmazások éppen cache-eltek biztos hogy mindnek egyszerre kelljen ott elkezdenie számolnia hogy mit dobjanak el?

(Disclaimer: 100 mega ram ebben a gépben 2.5%, majdnem a 97%-od is stimmel)

Akkor nem értetted meg a lényegét a postnak. Nem arról van szó, hogy mindig mindent cacheljen be, hanem arról, hogy alkalmazkodjon ahhoz, hogy mennyi ram van a gépben. De ez két irányú folyamat: ha sok a RAM, akkor használja ki. De ha fogy és kell másnak is, akkor adjon vissza. Ld. MSSQL-es példa: ha bejelentkeznek 5-6-en RDP-n, indítgatnak programokat akkor ott helyből lesz 1-2G RAM igény: MSSQL visszavesz magából.

De ugyanezt el tudnám képzelni akár egy Firefoxtól is: tfh. hogy van 4 GB ram a gépben, alap kihasználtság mondjuk 2 Gb. Firefox elkezd hízni, látja, hogy van szabad ram, elmegy simán 3,5G Ramig. Utána elindítasz egy programot, Firefox látja, hogy kell a RAM és elkezdi kidobni a cacheját a memóriából.

A másik eset, amikor nagyon elgondolkoztam azon, hogy miért nem tölti előre az a játékok. Pl. Half-Life jellegű játék, ahol a pályák között kb. folyamatosan mész át. Ott - ha van RAM - simán el lehetne kezdeni tölteni a háttérben a következő pályát, assetjeit töltögetni és bennhagyni a RAM-ban. Persze, ha kell (mert pl. az user átvált desktopra, nyit egy böngészőt és ránéz a Facebookjára, közben megnéz még 1-2 YT videót), akkor vegyen vissza magából. Annyira nem túl nehéz egy ilyen takarító megoldást elkészíteni, viszont folyamatosabbá tudja tenni az életet.

Egyébként az OSX memóriakezelése szerintem kifejezetten borzasztó pazarló. Az MBP-mben 4 gb ram volt alapból, kb. W7 2GB rammal. (Azóta 16 van :).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Amit te szeretnél (ha jól értem) az inkább op.rendszer feladat.
Addig rendben van, hogy a számára kiosztott memóriával úgy gazdálkodik ahogy optimálisnak tartja, de amit itt írtál, abból már az következik, hogy a teljes memóriát neki kellene kezelni. Márpedig egy adatbázis- vagy egy webszerver ne akarjon tudni róla, hogy ki fut mellette és annak milyen erőforrás igénye van. Lehetőleg ne is tudjanak egymásról.

A Half-life-os résszel egyetértek, ott tényleg elkezdhetné lekérdezni a háttérben az új pályát, ha van szabad RAM, meg azért csak észleli a játék, hogy elvesztette a fókuszt, és akkor drop caches, anélkül meg nem nagyon nytisz másik desktop appot. De a firefoxos példáddal már kevésbé értek egyet, amellett már elindíthatok 3 másik desktop appot bármelyik pillanatban, és bármilyen wrapper API-t vagy "mennyi ram foglalt épp" ellenőrzési megoldást kezdünk csinálni, az lesz a végeredménye, hogy A programozási nyelv memóriastruktúrájából átparse-olunk valamit a kernel felé, hogy dobja el egy másik app a cache-eit, hogy B és C programozási nyelven írt program tudjon memóriát foglalni, azok meg ha elég okosak, akkor addig várnak, ha nem (ami gyakoribb), akkor még rosszabb: memóriánál minimum 100x lassabb swapre teszik a működésükhöz feltéltenül szükséges (tehát nem cache jellegű) memóriát. Ezért vagyok nyugodt, ha a memóriám több mint fele szabad, és furcsamód így sem szoktam várni soha a Linuxos gépemre hogy bármit is betöltsön (persze ehhez az SSD is kell). A Macemre meg szoktam várni ha már sokat használtam (pedig szintén SSD-s), de arról te is elismerted, hogy pazarolja a memóriát.

De azért még születhet egy arany középút talán kettőnk véleménye közt desktop appoknál:
ha látnak elegendő memóriát, akkor is csak azt cache-eljék be, amit amúgy HDD/SSD-n tárolnának (settings sqlite db, böngésző esetén gyakran megnyitott oldalak cache-elt stylesheetjei, js-ei), vagy amiről a fejlesztő nagyon úgy gondolta, hogy jobb ha becache-eljük mert pl. egy ezerszer lefutó ciklus számolja ki (ami már lassabb mint a kernel API felé és azon keresztül más appok felé történő parse-olgatás).

" azok meg ha elég okosak, akkor addig várnak"

Ezért kell mindig valamennyi memória szabadon. (Ld. a fenti MSSQL-es példát, ahol a RAM 3%-a mindig szabad). Egyébként a legjobb az, hogy ha az OS részéről van valamilyen támogatás. (Úgy nézem, Linuxon is van, nem csak Windowson: http://elinux.org/Memory_Management#LSM-based_low-memory_notification)

Másrészt swapre egyébként is az a memória fog kerülni, amit használsz, nem a most induló. (Most a Linuxos OOM killer féle gyopárságokat hagyjuk.)

"Ezért vagyok nyugodt, ha a memóriám több mint fele szabad"

Ez azt jelenti, hogy a rendelkezésre álló memóriád több, mint fele kidobott pénz volt, mert semmi nem használja ki.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Pontosan, ahogy mondod, teljesen igazad van, pont ezt is írtam:
"amit amúgy HDD/SSD-n tárolnának" ... "vagy amiről a fejlesztő nagyon úgy gondolta, hogy jobb ha becache-eljük mert pl. egy ezerszer lefutó ciklus számolja ki"

Annyi hogy tán megtévesztő lehetett az elméleti sík, nyilván ezek nagy része gyakorlatban is megoldott, pont azért, mert így helyes.