Memory management – Linux vs Windows

19.2.2020 16:52 | Přečteno: 4736× | Linux | | poslední úprava: 19.2.2020 17:41

V poslední době jsem se bavil s několika linuxáky i windowsáky o memory managementu a zjistil jsem, že obě strany se docela dobře vyznají, jak to funguje v „jejich“ systému, mají ale zkreslené představy o funkčnosti na opačné straně barikády. Vnitřnostmi obou systému se už nějakou dobu zabývám a pokusím se tedy popsat hlavní rozdíly, aniž bych přitom zabíhal do zbytečných detailů (např. všude, kde se řeší paměť procesu by bylo nutné zmínit, že může být sdílená s jinými procesy atd.). Předpokládám také určité základní znalosti o fungování virtuální paměti a mapování na fyzickou paměť.

Overcommit

Linux ani Windows nepřidělují fyzickou paměť ihned při alokaci. Jinými slovy – alokace vrátí virtuální adresu, která se nemapuje na žádnou fyzickou paměť (ve skutečnosti se mapuje na nulovou stránku a při zápisu se uplatní COW, ale to je implementační detail). Při prvním zápisu do některé ze stránek alokované paměti nastane fault, který odchytí jádro a namapuje na příslušnou stránku virtuální paměti stránku fyzické paměti. Důvodů pro takové chování je několik. Aplikace může alokovat paměť rozmařile, pokud ji celou nebude potřebovat, tak to moc nevadí, protože virtuálního prostoru je na 64bit procesorech dostatek. Některé algoritmy pracují dobře s datovými strukturami, které jsou plánovitě „děravé“. Rozmělňuje se časově náročná část alokace (fyzické mapování) v čase.

Bankéři už dávno přišli na fintu, že mohou rozpůjčovat více peněz, než kolik jich mají – dokud si příliš hodně lidí současně nepřijde pro své peníze nenastane problém. Princip overcommitu je stejný. Proč nedovolit aplikacím alokovat co jim hrdlo ráčí i nad limit velikosti fyzické paměti + stránkovacího souboru. Beztak z té alokované paměti použijí jen část, takže se nic nemůže stát.

Windows overcommit nedělá. Linux se řídí proměnnou vm.overcommit_memory. Defaultně je zapnutý heuristický overcommit, který v praxi znamená, že pokud si aplikace nevyžádá absurdně velikou alokaci, tak neselže a paměť dostane. Troufám si říct, že v takto to je v praxi na 99,99 % nasazených systémech jak na serverech, tak desktopech. Existuje možnost overcommit vypnout nebo naopak vždy povolit (právě pro případ aplikací pracujících na „řídkých“ datech).

Oba přístupy mají své výhody a nevýhody. Na Windows se může stát, že alokace selže i když je k dispozici hromada volné paměti ale je překročen „commit charge“, tady alokovaná anonymní paměť překročila množství, které je systém schopen pokrýt fyzickou paměti a stránkovacím souborem. Pokud se nějaká aplikace neutrhne z řetězu, tak se to ovšem moc často nestává. V praxi je totiž velká část fyzické paměti obsazená soubory mapovanými do paměti, načtenými částmi proveditelných souborů/knihoven, diskovou cache – jinými slovy neanonymní pamětí. Tu lze kdykoliv z paměti odstranit, neboť je pokryta souborem na disku. Neanonymní paměť se nepočítá do „commit charge“. Windows se takové situaci také snaží bránit tím, že pagefile se umí za chodu zvětšovat (a zmenšovat) a defaultně to je zapnuté. Je to také jeden z argumentů proč ve Windows pagefile nevypínat. Přístup k alokované paměti nemůže selhat. Systém garantuje, že pro ni má pokrytí fyzickou stránkou.

Nevýhodou overcommitu je, že zatímco alokace (tedy místo, které se dá dobře ohlídat z hlediska návratové hodnoty případně vyhozené výjimky v hipsterských programovacích jazycích) projde skoro vždy, tak věc, která se ohlídat prakticky nedá, tedy prosté přistoupení k paměti, selhat teoretický může. Linux se tomu snaží zabránit, jak to jen jde. V nouzi nejvyšší povolá OOM killera, který vybere nějakou aplikaci a zabije ji. OOM killer v Linuxu je jako typický nácek– brutální a hloupý. Když nadejde krize, tak má ze záhadného důvodu ve velké oblibě mordování židů, eee… co to plácám, mordování Xorg samozřejmě, jehož smrt vám sestřelí všechny aplikace. To nepotěší. Jinými slovy – neví nic o userspace a jeho heuristika nebere ani nejmenší ohledy na to, co je pro uživatele podstatné. Jsou nějaké snahy to zlepšit. Už 20 let+. A furt nic.

Historicko-lingvistická vložka

Swapování se používalo zejména na mainframech. Fungovalo to tak, že CELÁ paměť procesu se vyhodila z fyzické paměti, nahrála se tam celá paměť jiného procesu, proces dostal přidělený procesorový čas, pak se opět celý z paměti odsunul, a tak pořád dokola. Linux neumí swapovat a nikdy to neuměl. Umí „pouze“ stránkovat, což je mnohem pokročilejší metoda pracující s granularitou stránek nikoliv celých procesů. Název swap partition/file, swapping je tak zapečený v systému i hlavách, že de facto zastínil původní název a je zbytečné s tím bojovat. Asi tak, jak je zbytečné obhajovat původní význam slova hacker. V tomto blogu však budu důsledně používat pojem stránkování, aby bylo zřejmé, oč jde. Windows umí stránkovat, a swapovat paradoxně nedávno naučil. Umí „modern apps“ kompletně odstranit z fyzické paměti. Je to ale okrajová záležitost. Ve Windows je terminologie správná (paging, page file).

Globální vs lokální seznamy stránek

Tohle je asi největší principiální rozdíl. Linux má seznam stránek „active“. Je v ní guláš stránek ze všech procesů. Pak má seznam „inactive“ kam přehazuje stránky z „active“ LRU algoritmem, který nijak nezohledňuje přináležitost k procesu, tedy padni, komu padni.

Oproti tomu Widnows má pro každý proces separátní seznam aktivních stránek, kterému se říká „working set“. Taktéž „inactive“ seznam není jeden, ale je jich 8 dle priority. Nevýhodou je větší komplikovanost a větší režie spojená s obsluhou těch seznamů. Výhodou je větší flexibilita – aplikace si může nastavit prioritu jak důležité jsou její stránky, může si nastavit minimální working set, může si sama na sebe zavolat EmptyWorkingSet před dlouhotrvajícím spánkem.

Windows má také heuristiku, která nedovolí narůst WS procesu nad mez, kdy příliš omezuje ostatní procesy. Jinými slovy od určité hranice proces dostane do WS stránku pouze na úkor vyhození odtamtud jiné stránky. Nemělo by tedy dojít k trashování a hladovění ostatních procesů, kterého lze v Linuxu dosáhnout snadno. Historku typu „přihlášení přes SSH mi trvalo půl hodiny“ prožil každý správný linuxák Přes cgroups se to dá omezit, ale vyžaduje to ruční fidlání a zkušeného sysopa.

Jaký je tedy koloběh stránek ve Windows? Aplikace se rodí s minimálním worksetem (není to jako v linuxu, že po forku je proces COW klonem rodiče). WS se postupně zvětšuje, jak aplikace bere stránky ze „zero page list“ a načítá exec, knihovy a další soubory, alokuje, memmapuje, … V určité chvíli windows určí, že proces má dost a začne mu stránky z WS vyhazovat. Ty se můžou vrátit zpět do WS, když k nim proces přistoupí. A to softfaultem pokud je stránka ještě v paměti nebo hardfaultem pokud není. Stránka vyhozená z WS může skončit buďto v „modified page list“ nebo ve standby. Modifid je paměť, kterou nelze ihned z paměti zahodit a musí se předtím zapsat na disk. Zejména je to anonymní paměť ale i modifikované stránky neanonymní paměti (dokud se neprovede sync). Jednou za čas se probudí thread „modified page writer“ zhodnotí situaci (množství volné paměti, zatížení IO a CPU) a případně začne stránky zapisovat na disk (anonymní do pagefile, neanonymní do příslušných souborů) a tím se dostanou z „modified“ do „standby“. Ve standby jsou stránky paměti, které je možné okamžitě uvolit – neanonymní paměť (protože ji lze vždy načíst zpět z příslušného souboru) i anonymní (protože musela být předtím zapsána do pagefile a lze je tedy získat zpět odtamtud). Standby je tedy taková cache stránek. Paměť odtamtud lze v případě potřeby kdykoliv uvolnit a současně je pravděpodobnost, že si některý proces přes softfault přitáhne zpět do svého WS. Když je paměť vyhozená ze standby nebo proces vrátí paměť systému, dostane se do seznamu free. Tam ale douho nepobude, vyzvedne si ji ihned thread, který ji vynuluje a přehodí ji do „zeroed page list“. Tím se koloběh uzavírá.

Komprese paměti

Když s kompresí paměti přišel Apple v roce 2013, byl jsem k tomu dost skeptický. Na vlastní kůži jsem se ale přesvědčil, že jsem se pletl. Pomohlo to, a to i na počítačích s SSD. A viděl jsem to i na modelech s nvme takže snad to mají vyzkoušené, že se to vyplatí i tam. Nebo tím jen šetří disky s ohledem na objem zapsaných dat, kdo ví. Funguje to (v MacOS) tak, že systém při nedostatku paměti začne procházet inactive frontu stránek a komprimovat je místo toho, aby je hned vyhazoval do stránkovacího souboru. Pokud ani to nestačí, tak začne i tak stránky odkládat ale už v komprimované podobě, což dále snižuje IO jak při zápisu, tak při čtení. V Linuxu je několik různých soupeřících řešení, zejména zram a zswap. Mají jedno společné – nikdo to nepoužívá. No možná až na Android (zram).

Ve Windows komprese paměti implementována je a využívá se vždy, i na počítačích s nvme a hromadou paměti. Vypnout se dá ( Disable-MMAgent -mc ) ale nikdo to nedělá. Implementace je taková… řekl bych lajdácká. Existuje userspace proces (s dost mimořádnými právy, až v tom někdo najde díru…) „memory compression“, který prochází standby seznamy, nasává z nich stránky, komprimuje je a ty pak žijí v jeho working setu. Nebo z něho vypadnou zase do standby seznamu a odstamtud se dostanou do page file.

Hyperaktivita

Memory management v Linuxu je líný. Pokud není nedostatek, tak skoro nic nedělá. K troše akce se dá vyprovokovat experimentováním se swapiness nebo jinými parametry. Oproti tomu Windows je _akční_. Dovolím si zde přiložit obrázek, který myslím tu akčnost dobře ilustruje. Mám 240 GiB „dostupné paměti“, z toho je 224 GiB ve frontě „zeroed“ takže tam není disková cache ani nic. Systém od bootu neměl využito nikdy více než 40 GiB. Ale Windows si i tak mírnix týrnix zkomprimoval něco přes 14 MiB… Asi aby nevyšel ze cviku. Můžete hádat, kolik místa je obsazeno ve stránkovacím souboru, když je systém v takto komfortním stavu z hlediska paměti. Nula to opravdu není…

Každé pravidlo musí mít výjimku, takže i tady je. Windows provádí stárnutí stránek (Dělá se to tak, že se shodí accessed bit všem stránkám a za nějaký čas se je opět projdou a ty, které ho nemají nastaveny „zestárnou“) až v případě, že začne paměť docházet. Linux to dělá pořád. Má tak lepší vstupy pro LRU algoritmus za cenu mírně větší režie.

Stránkování paměti jádra

Linux má paměť jádra a ovladačů zamknutou, nikdy se neodstránkuje pryč. Ve Windows je část zamknutá (nonpaged) ale část odstránkovat lze. Je to výhoda, protože v případě potřeby bude nějaká fyzická paměť navíc (ovšem kernel ani ovladače by příliš paměti spotřebovat neměly…). Je to také potenciální bezpečnostní riziko. Pagefile není chráněn před zvídavým útočníkem tak dobře jako stránky jádra. Zejména pokud natvrdo vypnete počítač a analyzujete pagefile v jiném počítači. Klade to větší nároky na vývojáře jádra a ovladačů aby touto cestou neleakovaly citlivá data.

Další drobnosti

Windows zarovnává virtuální adresy na 64 kB Linux na stránky. Linux má slab alokátor a windows má asi něco jako buddy alokátor (to muže být důvod, proč je latence vytváření některých objektu ve windows o dost větší a s rostoucím počtem jader v CPU se to zhoršuje). Je to ale asi přísně tajné, jak to uvnitř funguje, protože se k tomu nedá nic dohledat.

Ztraceno v propadlišti dějin

Vynechávám rozdíly, které už nejsou aktuální, tedy zejména řešení omezení 32bit systémů, kuriozity jako AWE. Také věci jako SuperFetch, které MS vyvinul… ovšem těsně před tím, než nastoupily SSD, takže se staly brzy obsoletní. Nebo ReadyBoost, který nefungoval nikdy.

Který je tedy lepší?

Politici mají zvláštní cit, jak odhalit kdy se mají otázce vyhnout, protože nezávisle na odpovědi někoho naštvou. Tohle zcela jistě do této kategorie patří. Já nejsem politik, tak si můžu dovolit naštvat dokonce obě strany „sporu“ :-p Windows má v defaultním nastavení memory management, který se v krizových situacích chová lépe. Poskytuje také detailnější informace uživateli (když, jaký nástroj použít). Linux má mnohem přizpůsobivější memory management a dá se ohnout pro potřeby aplikace.

Zmiňoval jsem v úvodníku nějaké rozhovory. Je zajímavé, že windowsáci mají tendenci linuxovou stranu trochu idealizovat a linuxáci naopak Windows trochu démonizovat (zajímavé, že ve věcech, které se neliší a nejsou tedy v tomto článku zmíněné, třeba podpora huge tables nebo podpora NUMA, ASLR/KASLR). Jsou oblasti, kde to je oprávněné ale MM k nim nepatří.

       

Obrázky

Komentáře

[j]

Ad strankovani, to je ale neco uplne jinyho. Strankovani pameti resi maly adresni prostor, prepinanim stranek pameti. Umely to uz 8mi bity. Jinak receno, i pocitac, kterej umel adresovat jen 64kB ram, moh klidne pracoval s MB ramky, prave promoci jejiho strankovani. Pouzivalo se to samo jak na tuxovi tak na widlich na 32bit systemech, aby bylo mozny pouzit vic nez ty 4GB. Pripadne se daj prepinat stranky graficky pameti, coz se zas vyuziva k tomu, ze se neprekresluje obraz uzivateli pred ocima, ale prepne se cela zobrazovana pamet v okamziku, kdy je vyrenderovano.

K tomu zbytku asi toliko, tux vyuzije (a je to znat) temer veskerou dostupnou ram jakozto cache. Widle nikolivek (da se to ruznejma silenostma v registrech ponekud vylepsit, ale widle pak zacnou byt bonusem slusne nestabilni). Navic v pripade widli tu jeste (a je to cim dal horsi) mame naprosto tupe a imbecilni vyvojare, coz vede k tomu, ze SSDcko nestina nacitat data, zatimco jsou k dispozici desitky GB volny ram. Pripadne, ze se aplikace odmita nechat vubec spustit, protoze swap je vypnuty (presto, ze ma k dispozici klidne stovky GB ram). Asi je neresitelnej problem zjisti si, kolik ramky je k dispozici. Typickou ukazkou jsou pochopitelne gamesy*.

Na druhou stranu existujou aplikace, trebas M$ SQL, ktery sezerou klidne takovy mnoztvi ramky, ze vlastni system prestane prakticky fungovat. Tudiz je treba je umravnovat rucni konfiguraci.

BTW: Na tuxovi beru pouzivani swapu jako indikaci toho, ze je zahodno pridat ramku, a swap konfiguruju jen proto, aby to "rovnou nechciplo", na widlich se swapuje (a tudiz zcela zbytecne osoupava disk) i kdyz je ramka prazdna, takze swap vypinam pokud je to jen trochu mozny.

*Jestli chcete konretni priklad, tak sem v dobe nedavne zkousel "Wolcen Lords of Mayhem" (tradicne zabugovano jak svin). Hodil sem si to na klasickodiskovy mirror, a kazda zmena lokace znamenala nekolikasekundovy nacitani z disku, postupny donacitani textur ... Tak sem se sel podivat jak to vypada s ramkou, a zjistil, ze gamesa se zuby nehty drzi na 4GB, a o dalsich 50G k dispozici se tvari ze nevi. Cela by se vesla do ramky 2x ...

Jo, jasne muzu si to hodit na ssd, pripadne do ramdisku, ja vim, ale to nic nemeni na tom, ze tvurci jsou dementi a dementni jsou i widle, protoze se to deje i pri opakovanym nacitani stejny lokace = ctou se stejna data z disku, ktera kua muzou byt v cache.

[miho]

Osmibity měly paměťové banky. Třeba můj první vlastní počítač - Didaktik Gamma, skvělý to výrobek bratrů Slováků, měl 80kB RAM a horníh 16kB se dalo přepnout zápisem na port. Stránkování viz https://cs.wikipedia.org/wiki/Str%C3%A1nkov%C3%A1n%C3%AD_pam%C4%9Bti

U her je skoro vždy limitujícím faktorem něco jiného, než načítání z disku. Nejčastěji rozbalování načtených assetů lajdácky jednovláknově napsaným algoritmem. Stačí se podívat po netu na srovnání 150 MB/s HDD a 4500 GB/s PCIe4 nvme. Rozdíl není 30000 % ani 3000 % ani 300 % ale 30 %. Osobní zkušenost mám s WoW, který umístěný do RAMdisku startoval skoro stejně rychle, brzdou v jeho případě je síťová komunikace.

Ale ověřit si to můžeš sám, stačí nechat na pozadí otevřené monitorování aktivity disku.

[Pavel Křivánek]

Bylo to 32kB, ne 16kB

[miho]

Pravda, skleróza už asi začíná. Resp. já si pamatoval, že měl 80 kB RAM a nesedělo mi to číselně (32kB "dole" + 2*32kB nahoře by bylo 96, zapomněl jsem, že tam byl 16kB ROM).

[j]

A myslis, ze rozbalovani se vyrazne zrychli SSDckem nebo ramdiskem? Myslim ze slepej (a v pripade HDD i hluchej) jeste nejsem.

Mas tam ostatne zminej konkretni priklad, tak si to klidne vyzkousej.

U nekterych games to udela rozdil v radech, klidne 10 minut vs 10 sekund. I takovouhle hruzu uz sem videl na vlastni oci. Vyvojari zjevne vubec nepocitali s tim, ze drtiva vetsina lidi porad SSD nema a jeste dlouho mit nebude, takze se vubec neobtezovali resenim problemu random cteni (miliony pidi souburku).

A samo, to o dementnich tvurcich plati napriklad i pro save. I debil totiz muze ocekavat, ze posledni save se bude s vysokou pravdepodobnosti nacitat, tak si ho podrzi v ramce, specilene kdyz ji ma hromady. Ovsem to by nesmel byt vyvojarem hry, protoze to ty jeste ustavy to spravny pojmenovani nevymyslely.

[Gréta]

že ty jako budeš mit dualboot?? ;D

[miho]

V jistém slova smyslu Na domácím serveru mám Linux, na NASce mám linux, v routeru mám linux, v asi 20 virtuálech je linux, na produkčních serverech až na jednu výjimku linux. I na desktopu jsem měl linux od cca 1998. Ale posledních 10 let pokud správně počítám mám na desktopu windows. Periodicky to zkouším, snažím se, vydržím to tak týden. Nejde to, dře to, sorry jako

[Heron]

V poslední době jsem se bavil s několika linuxáky i windowsáky o memory managementu a zjistil jsem, že obě strany se docela dobře vyznají, jak to funguje v „jejich“ systému

Na něco podobného jsem narazil taky. Známej, co tvoří programy snad ve Visual Basicu (jsem ani nevěděl, že to dneska ještě existuje), takže dalo by se říct takovej power user, a pokecali jsme a téma padlo i na memory management a celkem mě překvapil. Diskuse kolem overcommit a ballooning ve vm (v jeho podání hyper-v) apod. Chytal se.

Jinak je nějaký důvod, proč je to ve widlích navrženo takto složitě? Tohle je poněkolikáté, co se setkávám s tím, že ve widlích je něco takto komplexního (příkladem budiž třeba NTFS, které už v době NT 4.0 umělo hardlinky i linky na adresář, ale začalo se používat snad až ve W7). Nevím, jestli Windows pořád návrhově míří na nějaké ultrasuperpočítače, ale pořád jsou zaseklí na desktopech, kde je to vlastně kontraproduktivní.

LRU

Jsem to jen já, nebo i ostatním tyhle simple přístupy vyhovují nejvíc? Ve widlích io cache (pro můj workflow) nefunguje. Nebo nefunguje vůbec. I před chvílí čtený soubor se čte opět. Všímám si toho i ve hrách, kdy i přes dostatek volné ram, kam by se vešly všechny datové soubory hry, se neustále čte z disku. V linuxu, i přes jednoduchost lru, se na disk po určitém čase chodí jen pro zápisy. (Tentýž problém v bledě modrém i ARC na ZFS na FreeBSD. Je to tak adaptive, že to vyhodí stránky zrovna těsně před tím, než je opět potřebuju.)

[Michal Kubeček]

Je to tak adaptive, že to vyhodí stránky zrovna těsně před tím, než je opět potřebuju.

Tomu říkám "problém screensaveru". Ideální screensaver by neměl o zhasínání obrazovky rozhodovat podle doby od posledního stisku klávesy nebo pohybu myši, ale podle doby do příštího. :-)

[Miloslav Ponkrác]

Mě spíše fascinuje, že už jsou tu 2 příspěvky, které hodnotí algoritmy Windows podle her. Co jsem se kdy setkal, tak každá počítačová hra je napsaná jako největší prasárna. Přičemž na prvním místě je ohnout, hacknout a změnit to co řídí Windows.

Velice často hra je psaná na průměrný počítač té doby. Například se hra rozhodne, že bude držet v RAM jen třeba 8GM a cokoli nad to bude ignorovat a namísto toho pracovat s diskem. Často naprosto stejně pracují hry s počtem jader procesoru a dalším.

Pokud ovšem vývojáři her obvykle ohýbají věci a leccos jedou po svém, nemyslím, že je to etalon chování čehokoli. Spíše takové srovnání ukazuje, že na počítačích neděláte nic praktického, pouze zábavu.

***

Screesaver vzhledem k obvyklým reakčním dobám člověka plně vyhovuje tomu, že o zhasínání rozhoduje od doby posledního stisku klávesy. Šetří tak lépe, protože "přepnutí obrazovky" nikoho a nic nezdržuje. Pokud máte zdroj, jehož uvedení do aktivního stavu nikoho a nic nezdržuje, pak je zbytečné, ba dokonce kontraproduktivní a méně funkční, mít křišťálovou kouli a odhadovat pro jeho řízení co bude v budoucím vesmíru.

[Heron]

Mě spíše fascinuje, že už jsou tu 2 příspěvky, které hodnotí algoritmy Windows podle her.

To má poměrně jednoduché vysvětlení, dual boot mám už jen pro hry. Posledního pracovního programu na win jsem se zbavil před několika měsíci. Navíc je jedno, jaký typ appky si daný soubor otevře. IO cache by měla zafungoval stejně.

Co jsem se kdy setkal, tak každá počítačová hra je napsaná jako největší prasárna.

I kdyby to snad byla pravda, tak to nic nemění na stavu io cache. Pokud si 32b hra vezme svých max 3GB, její datové soubory mají 16GB a stroj má volné paměti několikrát tolik, tak je podivné, že se datové soubory pokaždé čtou z disku a nikoliv už z OS io cache. (A ano, existují flagy, aby se daný soubor necachoval, ale nevěřím tomu, že se toto používá tak často. U těch, podle vás "prasáren", bych spíše očekával, že vývojáři takové detaily nebudou řešit vůbec.)

[miho]

Na to je snadné vysvětlení. Assety jsou vlastně objekty různých velikostí namačkané ve velkých souborech. Ty se nečtou přes fread ale mapují se do paměti protože to je mnohem efektivnější a je s tím menší opruz. Mmapovaný soubor nemá diskovou cache protože samotné to mapování je vlastně cache. Omezení virt. prostoru 32bit aplikace jistě není třeba vysvětlovat, nedá se tam namapovat celá hra. Takže se některá mapování ruší a pak znovu otvírají. Při zrušení mapování zanikne i "cache".

[Heron]

Na Windows se mmap necachuje v io cache? To by lecos vysvětlovalo. Na linuxu (zrovna jsem to zkoušel na FreeBSD, ale na linuxu to bude stejné) se i mmapovaný soubor nacachuje.

[j]

Ehm, je uplne jedno co jak volas, FS obsluhujou widle. Gamesu ktera by primo cetla sektory na disku sem jeste nevidel. FS === soubory (jo, exitujou i nesouborovy FS, ale widle zadnej takovej neznaj). A ty widle proste nedrzej v cache to co prave nacetly. A ne, netyka se to ani zdaleka jen games. Sak si to otestuj. Vem PC s aspon 32GB ramky (aby to bylo znat) a dej proste kopirovat 2x zasebou rekneme 10GB dat. Oboji to bude trvat stejne dlouho a oboji to bude cist tech 10G z disku.

A pak si v tech widlich pust trebas TC, a rucne mu nastav cojavim 16GB cache. Druhy kopirovani na zdrojovej disk prakticky vubec nesahne.

Copa delaj soudruzi v M$ asi tak blbe? Nj, uplne vsechno. Pokracovani? Stahni si everything a dej mu zaindexovat disk. A pak udelej totez s tim M$ indexatorem. Zaracene, jak je mozny, ze nekdo zindexuje disk za 10s, a nekdo jinej totez nezvladne ani za par dnu?

[Heron]

Je teda fakt, že bych si rád přečetl pokračování dnešního blogu, protože se mi příliš nechce věřit, že to widle dělají tak špatně. Kdyby neměly žádnou iocache, tak by nemohly běžet tak jak běží (za mě říkám, že vůbec ne špatně).

Je klidně možné, že o io cache si musí program speciálně požádat. Nebo naopak, že některé operace ji budou mít schválně vypnutou (třeba to kopírování souboru). Proto mám rád jednoduché lru. Na linuxu mám, na systému s dostatkem volné paměti, jistotu, že po cat soubor > /dev/null ten soubor bude v io cache. Občas toho využívám jako "prefetch". Bohužel tuhle jistotu už vůbec nemám třeba na FreeBSD s ZFS ARC, kde ani opakované (klidně i 15x) čtení nepřinutí ARC si to zapamatovat. A na widlích si už ani netipuju (ale tam nemám potřebu dělat systémové prográmky nebo skripty, takže mě to až tak netankuje).

[Josef Kufner]

Na druhou stranu, pokud zkopíruju velký soubor, tak nechci zahodit cache všech ostatních programů, neboť by se tím zpomalil všechen zbytek systému. Na Linuxu je to celkem běžný jev například při zálohování.

[Heron]

Ano, lze použít fadvise + POSIX_FADV_DONTNEED. Specializované programy tedy mají prostředky (v posixu), jak toto OS sdělit. Ale asi by to nemělo být výchozí chování.

[Michal Kubeček]

Na linuxu mám, na systému s dostatkem volné paměti, jistotu, že po cat soubor > /dev/null ten soubor bude v io cache.

To není s dostatečně novými jádry tak úplně pravda. Před časem jsem to tu psal; pokud už je page cache "plná", typicky až třetí čtení souboru jde z cache, druhé je ještě pomalé.

[miho]

Netvrdím, že mmap nemá cache, když se přistoupí podruhé ke stejné části souboru tak tam pořád bude pokud příslušnou stránku mezi tím z nedostatku paměti OS nezahodil. Z mé zkušenosti ale když zanikne mapování, tak se ta cache dropne. Možní se to dá ovlivnit nějakými hinty. Ve volné chvíli udělám test. Každopádně to plaí jen pro mmap, fread se chová jinak.

[Heron]

Ok. Jen pro pořádek, já jsem to testoval na ukázkovém příkladu z man stránky. Přeloženo clang 8.0.1 na FreeBSD 12.1 a testováno tamtéž (ZFS).

V zásadě jde o tento program (zkráceno):

fd = open(argv[1], O_RDONLY);
addr = mmap(NULL, length + offset - pa_offset, PROT_READ, MAP_PRIVATE, fd, pa_offset);
s = write(STDOUT_FILENO, addr + offset - pa_offset, length);
munmap(addr, length + offset - pa_offset);
close(fd);

Při použití mmtest soubor 0 | pv > /dev/null to nacachovalo soubor. Důvod, proč jsem tam zařadil pv je ten, že při obyčejném přesměrování mmtest ... > /dev/null to nic neudělalo (hádám, že to poznalo, že výstup je null; což se mi opět nelíbí). Následné čtení souboru i jinými metodami potvrdilo, že soubor je skutečně v cache. (zpool iostat, rychlost překračující možnou rychlosti disku)

[Michal Kubeček]

při obyčejném přesměrování mmtest ... > /dev/null to nic neudělalo (hádám, že to poznalo, že výstup je null; což se mi opět nelíbí)

Nechce se mi to dohledávat, abych se ujistil, ale IMHO by bylo docela logické, že se v takovém případě ze souboru nebude vůbec číst. Nammapovaný soubor je pro systém prostě jen kus (virtuální) paměti a teprve když se z příslušných stránek něco zkusí přečíst, vyvolá se pagefault, handler zjistí, že je to mmap a potřebná data načte z filesystému. V tomhle případě ale write() v důsledku povede na odpovídající metodu blokového zařízení /dev/null, která velmi pravděpodobně ten blok, který dostane, vůbec číst nebude (proč taky) a jenom vrátí příslušnou délku, čímž oznámí, že se data úspěšně zapsala. Takže se žádný pagefault nekoná a vůbec se nepozná, že to byl kus mmapovaného souboru a ne obyčejný kus paměti.

[miho]

Ehm, jaké sektory na disku? Než se pustíš do diskuze, tak si prosím alespoň zběžně prohlédni o čem je řeč... https://cs.wikipedia.org/wiki/Mapov%C3%A1n%C3%AD_soubor%C5%AF_do_pam%C4%9Bti

[j]

Ale ne, widle ani v nejnovejsich verzich linky neumej ... mas jich sice na vyber nekolik druhu, ale blbe fungujou uplne vsechny. A jako bonus pro tricata leda 21 stoleti ... porad plati omezeni na 250 znaku dylky cesty. Vytvorit teda delsi muzes, ale tim si skoncil, uz to nesmazes, nepresunes, ...

(a jo, da se to, jako vse, vochcat, musis cestu zkratit nikoli odzadu, ale odpredu. Takze misto c:\bordel\ z toho udelas c:\b\)

BTW: Kdyz sme u (specielnich) linku, co myslis, ze asi tak udela GPO, ktery tvrdi, ze "Folder redirection" ... cekal bys, ze z toho folderu o kerym je rec, udela link? Nasrat! Veme to tu picovinu, kterou vidis v exploderu (a pouze tam) a tenhle palink odkaze jinam. Ale folder na disku zustane presne tak, jak je.

Takze pokud nekdo nema zrovna v oblibe ty vnucovany "dokumenty" a "obrazky" a "hudbu" (ktery sou v \users\USER\Documents\...) a pouziva primo ten uvedenej folder, tak si vesele laduje data presne tam, kde je mit nechces.

Pokud (prozmenu) pozijes (de to vubec z GUI? IMO ne) mklink ... rekneme /D (folder), tak aplikace z nejakyho me zcela nepochopitelnyho duvodu vidi fyzickou, nikoli logickou cestu => opet nefunkcni (pro ty co nechapou, chci aby si appka myslela ze je vse na C: protoze tvurce je tupec a ja nehodlam vyzobabat jednotlivy soubory kvuli zalohovani, tak to nalinkuju z D:, kde se zalohuje vse, a apka mi nadava, ze to neni na C: ... ).

Jinak viz vejs, zcela nepouzitelna cache ve widlich je standard uz desitky let.

[Miloslav Ponkrác]

Windows má omezení v délce cesty na 32K znaků. Pro Windows jsou názvy souborů unicode víceméně textové řetězce, což je příjemné.

Unix považuje názvy souborů za binární řetězce, což považuji za zastaralé.

Čím to, že já nemám na Windows problém smazat, přesunout, atd. i soubory / cesty dlouhé přes 10K znaků? I tam jsem se jednou dostal.

[panika]

j je sice rekneme kontroverzni ale tady se ho musim zastat.. afaik existuje nekolik zpusobu jak programy muzou k ceste pristupovat, ale to co pises ty umi presne jeden, spatne to dela vetsina a moc neovlivnis jak to pouziva appka co potrebujes.. mam presne s timhle obri potize kazdy den, jestli me osvitis jak tohle koncepcne vyresit jinak nez unasenim deti tvurcu programu a naslednemu vydirani, tak mas u me basu sveho oblibeneho napoje :)

[j]

Pokrac, nezvan kraviny o vecech, o kterych vis lautr hovno. 32k je limit NTFS, nikoli widli, widle s necim takovym neumej fungovat.

[miho]

Limitace na 260 znaků není omezením NTFS ale Windows API. Je to tam zapečené na věky věků z důvodu zpětné kompatibility nelze vyhodit. Úděl Microsoftu - jedno debilní rozhodnutí se táhne desítky let, protože existuje několik softů, které na tom nesmyslu bazírují. Není to prostě Apple, který v posledním MacOS zcela odstranil podporu pro 32bit. A že lidi měli nakoupené pluginy pro své profi softy, které buďto už neexistují nebo budou muset za stovky tisíc nakoupit? Who cares

Ty linky (je jich několik typů) fungují docela obstojně pokud se použijí správně. Mimochodem NTFS svazek nemusí mít písmeno, dá se připojit jako adresář.

[j]

To neni o kompatibilite, to je ciste o debilite. Kazdou cestu muzes namapovat na jinou cestu, trivialne primitivne s funkcnim FS. Aplikace to vubec nemuze poznat. Na problem s dylkou cesty muzes hypoteticky narazit i u linuxovych appek, ale ses to schopen trivialne vyresit. Na widlich ne.

A mimochodem, kdyz nema to pismeno, tak to taky nefunguje. Jednoduse proto, ze to prece neni c: ...

Podivej, dalsi krasne typicka widlodebilita jup? A taky ukazka jak "fungujou" ty linky. To mas takhle na c:program files\... steam. Mas to tam proto, ze kdyz nainstalujes appku kamkoli jinam, uz to samo o sobe je problem. Ale protoze nehodlas mit 10TB velky Ccko, tak si tam pridas pekne link steamapps -> d:\games\steam. Mno a protoze ty linky jak rikas fungujou, tak ti steam bude pravidelne nadavat, ze na tom Ccku nemas 100GB mista na tu gamesu, kterou davas na Dcko, kde je 10TB mista.

Protoze na widlich se vubec nepredpoklada, ze by folder moh mit jinou kapacitu nez disk na kterym je ... (a ne, neda se tomu rict, ser na to a stahuj)

BTW: Snad jeste debilnejs se chovaj instalatory GOGu. Neprisel sem na to, jak je dokopat, aby se nerozbalovaly na Ccko (a podle mnoztvi dotazu na to tema nejsem zdaleka sam). Protoze ti dementi nejdriv vse rozbalej do user tempu a teprve pak to presunou do zadany cesty.

[Heron]

Ty ve mě otevíráš ty nejhrůznější vzpomínky.

V dobách malých ssd jsem měl datový disk připojen jako iscsi ze serveru ve vedlejším pokoji (aby byl klid). To samo funguje celkem OK a překvapivě s tím nebyl roky žádném problém. Potom mě napadlo, že si udělám další iscsi disk pro hry a připojím jej ne jako písmenko, ale jako složku do steamapps. (Před tím jsem měl steam nainstalovanej na velkým iscsi D:, takže viděl místa dost.) A to byla tragédie. Disk C: jsem měl jen 60GB, volného já nevím třeba 15GB (v době WinXP) a iscsi několik TB. A přesně jak popisuješ, každej druhej instalátor měl problém s nedostatkem místa na disku. Takže jsem se pokorně vrátil zpět k písmenkům. Dneska už má steam přímo podporu pro více úložišť na více disků, takže to není takový problém.

[panika]

chapu to dobre jako historicky okynko? kdyby furt nekoho trapil steam, tak se da v nastaveni prehodit knihovna kam chces...

[Heron]

Ano, to píšu v poslední větě komentáře, na který reagujete.

(Jinak jo, je to doba WinXP, Win7, s dnešními velikostmi ssd už to nemá smysl řešit takto.)

[j]

To chapes blbe, chova se to tak porad.

Ty sice (uz) muzes ve steamu nastavit, ze se to bude davat jinam, nez default, ale prestane ti kvuli tomu fungovat hromada jinych veci. Typicky addony (nebo jejich instalace). Coz je vylozene bfulike. Stejne tak muzes uplne jinam nainstalovat i celej steam. A opet budes resit, ze ti neco nebude fungovat.

Nehlede na to, ze pokud sis nevsim, tohle neni diskuse o steamu, ale o tom, jak debilne se chovaji linky ve widlich a widloaplikace. Steam (a kazda appka) by si kdyz uz, mela zjistovat kolik volnyho mista je v cilovym folderu, a ne na cilovym disku. A system by mal prozmenu zajistit, ze pokud pustim appku z na disk C: nalikovanyho folderu, tak si appka mysli, ze bezi na tom Ccku a naprosto netusi, ze jde o nejakej dalsi disk.

Dalsi typicka ukazka je trebas widlofirewall, kterej kdyz appku presunes, byt prave kvuli zachovani cest puvodni folder nalinkujes, tak vyskakuje hlaska, ze jde o novou appku a je treba ji povolit.

[Miloslav Ponkrác]

Já mám raději funkční přístupy do operačních systémů i aplikací - což znamená, že většinou (v problémech reálného času) nemám rád simple přístupy. Každopádně funkčnost je pro mě větší hodnota než jednoduchost / složitost.

[Vinicius]

Windows mají i serverové varianty a tam se ten "složitý návrh" může hodit.

[Heron]

Windows mají i serverové varianty

To samozřejmě vím.

a tam se ten "složitý návrh" může hodit

Očekával bych nějaký příklad. Neříkám, že se hodit nemůže, ale co potkávám windowsáky vývojáře, tak u nich mnohem víc platí (i když už to přestává být tak silné jako dřív) "umlátíme to větším železem". A navíc jim hw za pár mega nepřijde nic přehnaného, protože za licence zaplatí mnohem víc. A když k nim přijdu s tím, že to celé by mohlo běžet na hw o čtvrtinovém výkonu a licence 0Kč, tak se na mě dívají, jak kdybych spadl z Marsu. Standard je MSSQL, pokud ne rovnou Oracle, k tomu superrychlé pole a pár mega za licence. Nějak mi nepřijde, že by se někde používal ten sofistikovanější návrh Windows.

[Michal Kubeček]

Pokusů udělat OOM killer (nebo page reclaim) chytřejším byla spousta a soudě podle občasného nadávání kolegy sedícího ob dva stoly se stále objevují další, které v lepším případě sice zlepší chování v tom specifickém use case, kterým jsou motivovány, ale obvykle za cenu zhoršení jinde.

Pokud se někomu overcommit nelíbí, může ho vypnout. Otázkou ale je, nakolik je to rozumné po tolika letech, kdy se userspace aplikace píší s vědomím, že overcommit tu prostě je, takže není důvod si hned po startu nenamapovat hromadu paměti, co kdyby se někdy hodila. Zkusil jsem se trochu porozhlédnout po systému, u kterého zrovna sedím (destktop, uptime 2.5 dne):

• firefox: VSZ 3.7GB, RSS 1.4GB
• kwin: VSZ 3.6GB, RSS 272MB
• plasmashell: VSZ 3.45GB, RSS 182MB
• polkitd: 2.9GB, RSS: 36MB
• nscd: VSZ 1GB, RSS 3.7MB
• systemd: VSZ 220MB, RSS 9MB

Všechny ty procesy běží celou dobu a kromě firefoxu není pravděpodobné, že by jejich skutečné nároky na fyzickou paměť nějak zásadně narostly.

Pokud je nějaký proces pro systém důležitý (podle okolností to může být třeba sshd nebo X server), lze ho před OOM celkem spolehlivě ochránit nastavením /proc/*/oom_{,score_}adj

[Jendа]

No hlavně přestane fungovat Address Sanitizer (alokuje ~20 TB a používá to jako sparse bitmapu pro ukládání metadat ohledně paměti alokované céčkovým alokátorem) a občas Wine (alokuje asi 3 GB).

[j]

Pokud mi skleroza slouzi, tak tyhle hokuspokusy vetsinou skoncej na tom, ze vlastne zabit neni co, protoze nedulezity veci prece nebezej. A jinak bych rek, ze nejspravnejsi je zabit prave tu vec, ktera zfailovala = uz pro ni ramka neni. Kdo pozde chodi ...

Apropos, s timhle pristupem je pak taky docela sranda ve virtualnich clusterech, cim vetsi, tim vic legrace. Protoze, jak jinak, se to chova uplne stejne = klidne muze na 30G ramky bezet 10 stroju, kde kazdej jeden ma pridelenych 30G ramky. Tady se pak jeste hraje takova hezka loterie na tema, ze se muze zkusit vylosovat nejakej jinej stroj, na kterej se to presune, a kterej mozna realne tu ramku mit bude ... a nebo taky ne.

Vubec uz jen zjistit, jaka je realita spotreby pameti, muze byt komedie, parodie i tragedie dohromady. Naprosto bezne virtualni stroj vykazuje trebas 100% vyuziti prideleny ram, ale uvnitr bezici system vesele tvrdi, ze 80% je volnych. Ovsem totez klidne i naopak.

[Miloslav Ponkrác]

A to je hlavní důvod, proč těžko někdo naprogramuje lepšího OOM killera, stejně jako úskalí řízení správy paměti v tomto prostředí = nedostatek pravdivých a reálných informací potřebných pro toto řízení.

[kvr]

Pokud mě neklame paměť, tak VSZ obsahuje i mapované soubory, tedy kromě executable a knihoven například taky paměť (či část) grafické karty. To budou nejspíš ty 2-2.5GB, nějaká část toho zbytku knihovny.

Libc či modernější malloc knihovny se chovají při alokaci docela rozumně, alokují relativně malé skoky, které pak třídí do poolů podobných velikostí. Na větší objekty můžou používat mmap (typicky si alokuje stránku třeba fopen). Ale obecně to není nic drastického nad aktuální využití paměti. Jiná věc je pochopitelně fragmentace, ale to s overcommit nesouvisí.

IMHO v zásadě dneska není k overcommit nějaký extra dobrý důvod, za předpokladu, že se aplikace chovají rozumně. A pokud se rozumně nechovají, tak stejně chcípnou, takže se dostáváme zpátky k premise.

Je to spíš pozůstatek (i když tedy stále validní), kdy se nedalo předpokládat, zda paměť bude sdílená nebo kopírovaná - v případě fork() a následných modifikací, případně podobně u knihoven, kdy se data a část kódu mapuje, ale poté se v runtime modifikují. Jenže to mělo výraznější význam v době, kdy knihovny a riziko privátních kopií byly poměrem k RAM velké, což už dávno neplatí (včetně zmiňovaného fork() - to je koncept z minulého století, který dnes prakticky nikdo nepoužívá (zdravím Apache Http z jeho workery)0.

[kvr]

Pro úplnost, vypnutí nebo zapnutí overcommit neřeší ten zásadní problém - pokud dojde paměť, tak se ty aplikace stejně nemůžou chovat rozumně. Třeba Xorg (nebo Windows ekvivalent) by stejně nebyly schopny přijímat a posílat zprávy od klientů či cokoliv dělat. Takže ono, i když se overcommit vypne, tak sestřelit zlobivou aplikaci může být stále nejlepší varianta. Co je zlobivá aplikace, je samozřejmě jiná otázka. Mimochodem, mi na Ctrl-Alt-SysRq-F obvykle chcípne Chromium (obvykle zcela správně). Myslím, že OOM už nějakou dobu ignoruje mapovaná data (takže Xorg s vysokým VSZ není zdaleka největším kandidátem).

[jiwopene]

Nestačí Alt-SysRq-F (resp. Alt-SysRq, pak F)?

[kvr]

Asi jo, už si to tak nepamatuju - dělám to jenom na ženině počítači, který má "jen" 8GB a ona s oblibou otvírá tunu oken se spoustou javascriptů. Místo Ctrl má být na tom notebooku Fn, bo SysRq je přes Fn. Ctrl je zbytečné.

[disorder]

u mna ziadne fn nie je potrebne, kernel sa pozera na hw layout, nie na interpretaciu (preto rovnake klavesy funguju pri roznych sw layoutoch)

[Miloslav Ponkrác]

Ohlídat selhání přístupu k paměti jde - pomocí výjimek. V řadě programů se to dokonce i využívá.

Výjimky jsou schopny fungovat, ošetřovat chyby a pracovat i v situacích, kdy se jiný druh ošetření chyb nedá reálně použít.

Jediný problém je, že v mainstreamových jazycích na výjimky nasadili obrovský overhead ve formě plnohodnotných objektů - a tím samozřejmě obrovskou penalizaci výkonu. Aby to nebylo málo tento konkrétní OOP způsob výjimek může selhat sám o sobě - třeba nedostatkem paměti.

Když vznikala Ada, tak první verze byla bez výjimek. Pokusy nasadit Ady do kritických situací poměrně rychle dokopal autory k přidání výjimek. Ada nemá overhead OOP výjimek. Její výjimky jsou efektivní, a rychlostně odpovídají plus mínus obyčejné instrukci skoku.

Stejně tak řada jiných jazyků má efektivní výjimky. Mimo jiné i Windows v jádře má své výjimky SEH bez OOP smetí. Kernel i user kód může vyhazovat výjimky. A dokonce user program může chytat výjimky jádra.

[miho]

Jasně ale zatímco každou alokaci se do try-catch obalit dá a pak podle toho reagovat, třeba nedovolit otevření dalšího dokumentu, tak každý přístup do paměti tak ošetřit nejde. Jedinou reakcí pak může být pozavírat dekriptory, vypsat "Sorry vole, error!" a chcípnout.

[Max]

Zajímavé počtení. Díky.
Zdar Max

[..... Izak .....]

Porad plati ze windows neumi defragmentovat RAM ? Linux to dela az je potreba, windows to neumeli a podle me porad neumi.

No s windows a RAM je to slozite, nebot on umi adresovat i v real modu ... a jine chutovky, rezervuje RAM pro drivery, co vyuzivaji sluzeb BIOSu a neumi bezet na nejakou mez, vetsinou nad 1GB, jine nad 4GB ... linux na to ma IOMMU

[Michal]

256GB RAM? Hezke. Tak to uz si muzes dovolit pouzivat aplikace psane v electronu!

[Max]

Nebo jeden menší Exchange server:

• Mailbox: 128 GB minimum recommended
• Edge Transport: 64 GB minimum recommended

:D
Zdar Max

[Pan_Filuta]

To mají jen v požadavcích aby si lidi raději kupovali cloud :) prakticky si paměti vezme stejně jako dřívější verze, viz třeba ( https://www.frankysweb.de/exchange-2019-128-gb-ram-flash-wirklich/#comment-64171 )

128GB je potřeba jen aby se zaktivoval nějaký nový garbage collector, což je celkem sranda :)) viz ( https://www.youtube.com/watch?v=eOhTTcooM1M&feature=youtu.be)

[Max]

Tak samozřejmě jsem to myslel jako lehčí nadsázku, ale i tak díky za link s garbage colletorem.
Zdar Max

[Martin Tůma]

Hezké srovnání.

V článku i diskuzi mě zaujaly narážky na "debilní programátory", který nedokážou využít volnou paměť. A celkem by mě zajímalo, jak si tedy představujete, že by aplikace měla postupovat, když běžná metoda vyhradit pro cache nějakou "rozumnou", fixně omezenou velikost je zcela špatně? Má se zjistit velikost fyzické paměti a podle ní nastavit ten limit? Nebo velikost aktuálně volné paměti? Stroj sice může mít 32GB, ale co když uživatel bude chtít mít s mojí aplikací spuštěné zároveň dvě další aplikace v elektronu? Nebo obráceně, co když měl tyto dvě elektronové aplikace spuštěné v době mé alokace, ale poté je zavře? Nemluvě o tom, že první "expert", co uvidí, že mu ta aplikace "žere" 30GB paměti jí udělá takovou "reklamu", že i Horst Fuchs (Ví Gréta, kdo je (byl - žije ještě vůbec?) Horst Fuchs?) bude blednout závistí?!

[Martin Tůma]

Tak Horst, zdá se, žije, ale "Die WS Teleshop International Handels-GmbH aus Wiener Neudorf ist pleite." (2007). Prej za to může internet.

[miho]

Tak to máte nějaké zajímavé vidiny, v článku není o debilních programátorech ani slovo. Pokud jde o načítané soubory - ty by měl cachovat OS a aplikace by to řešit neměla. Pokud jde o rozbalené assety aby se dalo třeba přejít na předchozí mapu bez načítání/dekomprese - no... mohlo by tam být šoupátko v nastavení a byli by spokojení všichni :)

[Martin Tůma]

Byl bych se ochotný hádat, že to v článku bylo (vlevo dole), ale teď to tam nemůžu najít. Takže je to asi jenom v diskuzi. Ale pointa zůstává.

[Pan_Filuta]

Dovolím si doplnění ke kompresi paměti ve Windows: Poprvé se objevila ve Windows 10 verzi 1511 a od té doby je v Deskopových Windows ve výchozím stavu zapnutá

Naopak v serverových Windows (2016,2019) je ve výchozím stavu vypnutá a dá se případně ručně zapnout.

Díky za článek!

[pushkin]

Tak to vysvětluje bezdůvodné hrabání Windows na disk.

Postavte vedle sebe dva identické stroje bez připojení k internetu, jeden s Windows, druhý s Linuxem. Nic na nich nedělejte a nechte spuštěnou libovolnou shodnou aplikaci nevyužívající disk. Zatímco kontrolka disku na linuxu ani neblikne, na Windows si memory manager trénuje zápisy a kompresi do stránkovacího souboru.

Fajn článek, díky!

[Peter Golis]

Pekný článok. Až na jednu drobnosť, ja osobne ten zram používam ako virtuálny swap tak cca 10 rokov k plnej spokojnosti.