Správa paměti v Mac OS X

15.9.2009 20:30 | Přečteno: 4768× | Apple | | poslední úprava: 15.9.2009 20:40

Správa paměti v Mac OS se dost liší od Windows, Linuxu nebo dokonce BSD a současně se dost obtížně shánějí relevantní informace na toto téma. Myslím, že tedy bude užitečné shrnout ve zkratce známá fakta a současně tím třeba i vyvrátit několik mýtů, kterými je celá záležitost opletena.

Nejdříve krátká odbočka k získávání detailních informací o jádře Mac OS. Jediným spolehlivým zdrojem je kniha Mac OS X Internals - A Systems Approach a i ta bohužel už trochu zastarala. Dále se dá občas něco pochytit od vývojářů, kteří metodou pokus-omyl nějaké informace zjistili. Doporučuji např. video přednášky jednoho z vývojářů VMWare Fusion (prvních 14 minut marketingových keců můžete směle přeskočit). Dokumentace od Applu je velmi povrchní, zavádějící, nepřesná a občas se vyloženě "míjí s pravdou". Situace je opravdu katastrofální, nesrovnatelně horší než v případě Linuxu nebo dokonce Windows.

Podívejme se na výstup vm_stat

Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free:                          79657.
Pages active:                      2440855.
Pages inactive:                     633605.
Pages speculative:                  650414.
Pages wired down:                   389994.

Čísla jsou v 4 kiB stránkách, ta potvornost nemá žádný přepínač, kterým by se dala přinutit ukazovat v jiných jednotkách. Free je prostě volná paměť, kterou je možno ihned použít bez jakýchkoliv dalších operací. Seznam volných stránek je uložen ve FIFO kontejneru, tedy ve frontě.

Speculative je volná paměť, která je naplněná přednačenými daty (v tomto případě téměř 2,5 GiB, nepodařilo se mi zjistit jaký mechanismus se používá ale nepředpokládám, že by se tolik místa zaplnilo prostým read-ahead přístupem. Navíc tato paměť hned po bootu prudce roste). Táto data byla přednačtená ale nikdy k nim nebylo přistoupeno, v takovém přsípadě by spadly do active/inactive kolotoče, o kterém za chvíli. GUI aplikace reportují volnou paměť jako součet free + speculative.

Wired paměť je zamknutá ve fyzické paměti- nelze ji odstránkovat. Je zde zejména paměť jádra ale běžný proces si o zamčení oblasti paměti voláním mlock může zažádat také (Linux má obdobné volání také, ve Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace, kde by případne odstrankování mohlo být bezpečnostním problémem. Ve windows je vlastně i podstatná část paměti jádra stránkovatelná... ale to je zase na jiný článek ). Některé aplikace mlock používají, zejména Parallels a VMWare takto zamykají obrovské bloky paměti. Z výpisu výše je vidět takřka 1.5 GiB zamčené paměti protože tam běží ve VMWare stroj s přidělenou pamětí 1 GiB. Wired paměť má v Mac OS jednu specialitu - nevrací se po uvolnění ihned do free poolu ale stane se tak až když volná paměť dojde nebo množství wired paměti přesáhne nějakou hranici. Plyne to z maximálně líného přístupu ke správě paměti řídicího se heslem- pokud je volná paměť tak na nic nesahej. To je v ostrém kontrastu k „hyperaktivní“ správě paměti ve Windows. Linux je z tohoto hlediska někde uprostřed. Wired paměť nemá svoji frontu stránek a tyto stránky jsou pochopitelně vyřazeny ze všech jiných zde zmiňovaných front. Srovnejte teď co uvádí oficiální vývojářská dokumentace od Apple ( Applications, frameworks, and other user-level software cannot allocate wired memory. ) a jaká je realita např. pomocí tohoto triviálního prográmku

#include < stdlib.h>
#include < stdio.h>
#include < sys/mman.h>


int main(void) {
	int *i = (int*)calloc(1024,1024*1024);
	printf("%d\r\n",mlock(i,1024*1024*1024));
	getchar();
	return 0;
}

, který naalokuje 1 GiB paměti a zamkne ji a wired krásně povyskočí právě o 1 GiB nahoru.

Active je paměť která je mapovaná nějakým procesem. Je zde paměť anonymní (tedy paměť, která není svázaná s žádným souborem na disku, tedy vzniklá zejména voláním malloc nebo mmap s MAP_ANON flagem) i neanonymní. Seznam aktivních stránek je udržován ve frontě.

Inactive jsou stránky, které nejsou mapovány žádným procesem (většinou následkem toho, že správce paměti toto mapování odebral, o tom ale později). Existují dvě fronty „neaktivních“ stránek- pro anonymní a neanonymní stránky. Inactive stránky mohou být „špinavé“ (dirty stránky jsou takové, které je nutno zapsat na disk předtím, než mohou být odstraněny z paměti, pro anonymní paměť to znamená, že obsah stránky v paměti a ve swapu se liší případně stránka svůj obraz ve swapu doposud vůbec nemá).

Součet free, active, inactive, speculative a wired dá dohromady celou dostupnou paměť počítače (± pár stovek kiB, které popravdě nevím odkud se berou, že by čtení těch statistik nebylo atomické?), tedy v případě výše uvedeného příkladu 16 GiB. Jak vidíte ve výpisu vm_stat není žádná položka typu cache, buffers ani nic podobného. Mac OS si žádný přehled stránek tohoto typu nevede. Věci, které na Linuxu obstarává SLAB jsou rozpuštěny někde ve wired paměti a cache je zase rozeseta po active a inactive paměti.

Myšlenka je taková, že v active má být pracovní sada všech spuštěných procesu od jejich kódu přes knihovny až po data, nad kterými pracují (z každé z těchto oblastí samozřejmě jen stránky, které se využívají), inactive je oblast, použité paměti, která ale nepatří do současné pracovní sady ale existuje určitá pravděpodobnost, že bude znovu potřebná. Uměním je (někteří suchaři tomu říkaji heuristika ) zvolit poměr mezi active a inactive a algoritmus přehazování stránek mezi nimi tak, aby se minimalizoval počet zápisu a čtení stránek z/na disk. Jak je to tedy řešeno v MacOS?

Jak už jsem naznačil výše- správce paměti je v MacOS líný jak to jen jde. Když je volná paměť tak se stará jen o to, aby přiděloval volnou paměť (bere z free fronty a dává do inactive) procesům a po jejich ukončení vrátí anonymní paměť do free a neanonymní přesune do inactive pokud tam už není. Když proces sáhne na svojí stránku, která je v inactive paměti tak vyvolá soft page fault, stránka se přidá na konec active fronty. A to je vše.

Když volná paměť dojde (resp. klesne pod určitou úroveň, která se odvodí od celkové velikosti paměti) tak se teprve začne projevovat. Zjistí, zda není volná wired paměť a případně ji vrátí do free fronty. Následně začne přesouvat paměť z active do inactive fronty a to tak, že bere stránky ze začátku active fronty, odstraní její mapování v procesech a přidá je na konec inactive fronty. Nevyužívá se tedy žádný mechanismus stárnutí stránek resp. LRU, žádný zvýhodnění pro interaktivní/aktivní procesy ani nic podobného. Každá nezamčená stránka každého procesu se dříve nebo později dostane do jedné z inactive front.

Dále provádí čištění stránek v inactive frontě a bere stránky ze začátku inactive fronty a vyhazuje je z paměti. Opět se postupuje výlučněs principem FIFO. O samotné stránkování se pak stará několik specializovaných rutin (samostatně pro výměnu stránek mezi swapem a pamětí, mezi blokovým zařízením a pamětí, …). O vytváření souborů, do kterých se swapuje se stará samostatný proces (dynamic_pager), který se stará, aby se zaplnění swapovacích souborů pohybovalo v rozmezí nastaveném parametry high a low watermark.

Inactive a active fronty realizují jako celek algoritmus, kterému se přezdívá FIFO with second chance. Jinými slovy každá stránka někdy spadne do inactive ale než probublá inactive frontou až do stavu, že bude odstraněná má šanci, že když se znova použije tak se zařadí na konec fronty active.

Algoritmus je tedy relativně jednoduchý, důležité ale je jak se to v praxi chová. Když se dostane systém do úzkých tak začne nezadržitelně trashovat. Všechny procesy mají šanci se trochu projevit než probublají celým kolotočem front a žádný vyloženě nehladoví nicméně většina úsilí je stále vynakládaná na neustále odkládání a načítání stránek. Linux se svým swap tokenem je na tom podstatně lépe. V situaci, kdy se working set pohodlně vejde do paměti se projeví další vlastnost- velká ochota nahradit stránky chvíli nečinného procesu stránkami diskové cache. Jinými slovy- chová se to podobně jako Linux s velmi vysoko nastaveným parametrem SWAPINESS. Tento jev je opravdu velmi silný a dá se mu zabránít jen čtením souboru např. přes mmap s flagem MAP_NOCACHE (ten by se dost hodil i v linuxu ale to zase odbíhám) ale nikde se o tom pořádně nedozvíte a přečtením velkého souboru přes fopen a fread si vyhodíte z paměti běžící aplikace na úkor diskové cache.

Mac OS zkrátka zbožňuje paměť a z výše napsaného je myslím zřejmé proč tomu tak je :) K tomu navíc přispívá i to, že samotné jádro a základní aplikace pamětí příliš nešetří. Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.

       

Komentáře

[Jardík]

Windows lze správci paměti pouze doporučit aby nějakou oblast ponechal v paměti, není to však závazné a nelze s tím tedy počítat což má určité implikace pro realtime aplikace a aplikace

Nesouhlasím, ve Windows můžete naalokovat fyzickou paměť a nic vám ji neveme.

[miho]

Oops, to jsem neznal, clovek se uc cely zivot :) Na druhou stranu tohle se asi neda v normalnim softu urcenem pro bezneho smrtelnika pouzit kvuli nutnosti nastavit prava.

 

[Miloslav Ponkrác]

To je ale správné. Běžný programátor ani program by neměl tyhle akci vůbec umět. Na tu by měl sahat jenom ten, kdo ví co a proč to dělá.

Upřímně, čím méně hacků dovolí běžný desktopový systém, tím jenom lépe.

[Tom K]

Chcete říct, že "normální" SW by neměl se snažit, aby použité klíče nebyly k nalezení odswapované na disku ? (že je celkem normální, aby i desktopový SW šifroval je předpokládám bez diskuse).

[podlesh]

Ovšem ta feature je určena k něčemu jinému a použít ji pro bezpečné ukládání hesel je jen hack.

[Jardík]

základní aplikace pamětí příliš nešetří

Tohle by mohlo být přítomností GC v objective-c, v němž je psána většina GUI programů.

[alblaho]

ObjC IMHO nemá pořádný GC, pokud vím, tak je v knihovně jenom zabudovaný reference counting. (A dost by mě zajímalo, jak se to chová na víceprocesorovém systému.)

No a taky si matně vybavuju, že Apple inicioval nějakou novou verzi ObjC, možná, že tam je to jinak.

[Milan Lajtoš]

Skvelé čítanie!

Mám dve otázky. Líši sa nejako nejako správa pamäte v Mac OS X a v Darwine? Porovnať kód je nemožné, takže asi len čo sa týka testov a správania. A ešte druhá - existuje v Darwine/OS X niečo ako OOM-killer na Linuxe?

[Jardík]

Já myslel, že darwin je jádro MacOS??

[miho]

 Ono je to takove trosku komplikovane, Darvin je operacni system postaveny nad hybridnim jadrem, kteremu se prezdiva XNU, ktere je slozene z Mach, na ktery jsou nalepene kusy BSD ak tomu je jeste priplacnuty I/O Kit. 

[Milan Lajtoš]

Jadro nie, skôr základ.

No, ale k veci - Darwin je základ pre Mac OS X, ale neverím, že by si Apple v ňom neporobilo zmeny. Veď to by bolo ako distribuovať vanilla linux. ;)

[eoj]

Ach jo...

[miho]

Teoreticky by se to lisit nemelo ale osobni zkusenosti s darvinem nemam. Zminku o ekvivalentu OOM killera jsem nenasel. Vzhledem k tomu, ze se implicitne swapuje do souboru, ktere se dynamicky vytvareji za behu na korenove partition tak by pri zaplneni disku mohlo dojit k zajimavym jevum. Urcite vyzkousim

 

[default]

To ti řeknu docela přesně, co se stane, když dojde místo na disku pro swap. Běží to zoufale pomalu, nejde nic spustit a aplikace buď na akce nereaguje, nebo jde do beach-ballu. Žádnej crash se nekoná. Je na uživateli, aby paměť uvolnil. Ale stalo se mi to jen na Tigeru. Jak reagují Leopard se Snow Leopardem — to netuším.

[Tomáš Srnka]

vyskusam, dam vediet zatial mam 10.5.X, buduci tyzden pojdem na 10.6

[..]

je to tak aj u Leoparda, u Snow Leoparda sa mi to este nepodarilo :)

[9002]

Tesim sa na kombinaciu Étoilé a PureDarwin. Niečo ako OpenMacOS

[lukve]

ahoj. ja tiež sa tesim na nieco take ale otazka je pouzitelnost takeho niecoho.. maju vobec vyvojary PureDarwina snahu o integraciu etoile? pise sa to niekde? inac zatial je moj favorit Linux a po nom Haiku.

 

[rADOn]

Pokud sečtu RSS procesů kernel_task, mds, WindowServer, coreServicesd,... tedy takových, které jen zajišťují chod systému a grafického prostředí, na svém počítači tak se dostanu k úctyhodné hodnotě 1,7 GiB.

Pokud RSS je totez jako v linuxu tak je cislo na houby. Pokud ne, porad je cislo na houby.

Napoveda: pamet mapovana z hw. Pust si v X nejakou hezkou hru a vmsize xserveru vyskoci o stovky mega. Dokonce se mi kdysi kasal jeden kamarad jak je UT2004 skvele napsany ze bere jen 36M fyzicky Bodejt by taky ne, kdyz vsechny textury sly na ucet Xserveru… Bezne se to samozrejme nepozna, ale hry a systemovy procesy nejsou tak uplne bezny.

[miho]

 O RSS a obecne o problematice obsazeni pameti procesem jsem psal zde: http://www.abclinuxu.cz/blog/Mihovy_sochory/2007/9/jak-vam-kyne-linux takze sebestredne a nafoukane predpokladam, ze to kazdy zna a vi, co si pod tim ma predstavit!

 

[stativ]

A co je nejhorší, že dochází k nechutné fragmentaci paměti.

[M. Lox]

To jo, TLSF ruluje.

[Snilard]

 Jelikož se moc ve správě paměti a alokování v céčku nevyznám, ptám se. Co to pro mne jako uživatele, java, python a snad cocoa programátora znamená?

Znamená to, že si z naprosto zaplněné paměti nemám nic dělat a dokud to nezačne divoce swapovat, není důvod kupovat víc paměti? Můžu nějak systému s pamětí pomoci?

[stativ]

To, že se v OS X můžeš setkat s prapodivnými chybami (zejména nepodařené větší alokace) které jinde neuvidíš

[Algi]

 Nikdy jsem si nevšiml, že by se logovalo něco o prapodivných chybách v alokaci. Naopak si všímám v logu prasáren, které někteří programátoři dělají když neumí používat NSAutoreleasePool či leakujou paměť. O tom, že existuje Leaks a Instruments asi nevědí...

Jinak jako programátora v Javě ani v Cocoa tě při dodržování správných zásad nemusí nic trápit. Nevím, jak je tomu u "velkých" aplikací, co potřebují hodně paměti. Do zdrojáků Lightroomu nevidím a zbytek je nenáročný, takže pohoda. Ale třebas jsem jenom naivka, co nevidí pod kapotu