Vlákno názorů k článku
SLES je nejoblíbenější systém pro superpočítače od anonym - Jsem zvedavy, jak nam LO vysvetli, proc windows...

Kolik lidi asi tak zajima na cem bezi nejaky supervykony, jednostranne pouzitelny pocitac na vypocet pocasi, simulace a podobne veci?

No asi to zajímá poměrně hodně lidí z těch, co na takový supervýkonný počítač mají a zrovna se po nějakém poohlížejí. :o) Každý software potřebuje track record, aby se dostal do povědomí, ehm, "decision makerů". Z tohohle důvodu je snaha o nějakou tu prestiž docela pochopitelná.

Tu poslední větu nemyslíš vážně, že ne ? To je jako nám tvrdit, že Země je placatá.

Spis to bude nasazovanim dotnet aplikaci, IIS je jim blizsi. Jinak davat IIS misto Apache povazuju za masochismus.

Ještě musím dodat, že první verze Windows Compute Cluster vyšla před 2 lety. Předtím MS neměl žádný produkt pro trh HPC. Jestli a jak se Windows Compute Cluster prosadí, to uvidíme u třetí verze.

To je samozřejmě blbost, sám to musíte vědět. Problém je v ceně licence Windows. Pokud máte cluster s tisícem nodů, tak byste dal USD 100 000 jen za licence Windows. Zcela zbytečně byste platil za všechno to GUI, GDI, podporu čipových karet, šifrování FS, podporu multimédií a hromadu dalších věcí. Na konci potřebujete na node správu paměti, procesů, networking, a tím to končí. Tohle dostanete na každém CD s Linuxem, a nemusíte za to platit USD 100.

Nebo si opravdu myslíte, že důvod, proč se na výpočetních clusterech často jede Linux, je v nějaké extrémní kvalitě jeho správy paměti (viz příšernost jménem OOM Killer), nebo procesů? To asi těžko :)

Situaci na univerzitách neznám, tedy ji těžko budu hodnotit.

OOM Killer je špatný koncept. Linux má velkou spotřebu paměti. Například když provedete volání fork, tak forkovaný proces sdílí paměť s původním procesem v módu copy-on-write. Teoreticky změnit jakoukoliv část svého adresního prostoru, a tedy musíte mít dost paměti, abyste byl takový požadavek mohl utáhnout. No a fork se používá na unixech nechutně často, protože thready jsou horkou novinkou. Proto potřebujete paměti velikou spoustu. Linux to řeší tak, že když alokujete paměť, je alokace (skoro) vždy úspěšná, bez ohledu na reálnou dostupnost paměti. Když potom někdo chce alokovanou paměť použít, a paměť není, dojde na lámání chleba; OOM Killer vylosuje proces, a ten odstřelí. Fuj! Autoři aplikací pro Linux potom vůbec neřeší možné selhání alokace, protože alokace stejně vždy projde (podruhé fuj!).

Jak podobný problém řeší Windows? Nepoužívá se tolik CoW, fork neexistuje (vyjma Services for UNIX), worker procesy se nepoužívají (vyjma pár portů z unixů), zato odjakživa existují thready (které používá prakticky každý). Spotřeba paměti je nižší, a není nutné o paměti lhát. Pokud někdo chce paměť, systém jí alokuje. Když paměť není, tak se neprovede losování a odstřelení procesu, ale prostě se procesu řekne, že paměť není, a alokace tedy selhala (alternativně lze dynamicky zvětšit swap). A protože se SW píše v C++ nebo .NETu, nikoliv v ANSI C, tak se typicky jedná o nějaké vytvoření objektu, dojde k výjimce, a SW si s tím poradí. Prokazatelně si s tím poradí MS SQL Server, MS Exchange, MS Office, a Adobe Photoshop (tam jsem hlášky o selhání alokace viděl).

Windows mají swap file s pevnou počáteční velikostí. Ten je typicky nefragmentovaný (s výjimkou případu, kdy jste ho zakládal na těžce fragmentované jednotce). Pokud dojde paměť, jednou z možností je i zvětšení swapu. Pochopitelně to časte vede k fragmentaci swapu. Ale později dojde k jeho oříznutí na původní velikost, a bude opět nefragmentovaný. Samozřejmě není možné, aby se vám nefragmentovaný swap pevné velikosti nějak rozfragmentoval.
Pokud už máte swap fragmentovaný, můžete použít utilitu pagedefrag: http://technet.microsoft.com/en-us/sysinternals/bb897426.aspx

Ano, OOM Killer můžete konfigurovat. Můžete například "imunizovat" procesy před odstřelením, nebo overcommit paměti dokonce zakázat. Problém je, že když overcommit úplně zakážete, tak systému paměť dojde velmi záhy :(. Na nedostatek paměti sice můžete a předstihem reagovat, ale na tom, že OOM Killer je v rozporu se specifikací jazyka C to nic nemění. Mimochodem jak byste s předstihem reagoval na ten nedostatek paměti, nejlépe tak, aby výsledek fungoval stejně na všech unixech (resp. abyste zůstal na POSIXu)?

Pokud jsem si všiml, tak Linux měl až do jádra 2.6 příšernost zvanou LinuxThreads. Teprve od jádra 2.6 je threading v použitelném stavu. Samozřejmě Solaris má funkční threading již delší dobu. U AIXu měl threading dost tragický výkon. Nutno podotknout, že NT měly threading už v návrhu, a implementace (zvláště mutexů) je zjevně rychlejší, než například na Solarisu; a Solaris je zase podle všeho nejlepší ve světě unixů. Dnes už Oracle, Apache a řada dalších běžně používají threading, ale zbývá spousta dalších aplikací.

Ehm... CoW zvyšuje výkon? Já vždy myslel, že se podílí jen na spotřebě paměti. Ve Windows samozřejmě shodné spuštěné procesy sdílí shodné stránky kódu.

Služba implementovaná do samostatných procesů má velikou spotřebu paměti, a veliký overhead při předávání dat a synchronizaci. Naopak služba používající thready má menší spotřebu paměti, data předává v rámci procesu (tedy bez režie), a synchronizace je výrazně rychlejší. Proto dnes i "klasické" unixové aplikace typu Oracle, Apache a další používají threading. V případě použití worker procesů může chyba v kódu způsobit podobnou škodu, jako v případě použití threadů, protože workery typicky používají shared memory, nebo IPC. Navíc musíte mít nějaký dispatcher process, který je pak single point of failure. Worker procesy jsou prostě starší model, oproti threadům vyžadující více paměti, mají pomalejší kontext switche (protože thready v rámci procesu mají společnou memory map), pomalejší synchronizací a pomalé předávání dat.

Ve Windows typicky na každý příchozí požadavek vytvoříte objekt, který popisuje request, a zařadíte ho do fronty. Z fronty volných worker threadů pak vyberete první, a ten request obslouží. Po ukončení obsluhy requestu se objekt uvolní, a thread se vrátí do fronty volných worker threadů. Pokud dojde k pádu aplikace, service manager celý servis znovu nahodí (nebo udělá cokoliv jiného, co je nakonfigurované). Samozřejmě pokud chcete vyšší spolehlivost, můžete použít mikrorebooty, tedy jednou za X dní spustit nový proces servisu, ten starý nechat dokončit současné požadavky, a pak ho ukončit. Oproti worker procesům je to výrazně pokročilá technika.

Na to, abyste zapsal do logu, že není paměť, jí typicky moc nepotřebujete. Handle máte otevřený, a k vlastnímu vysypání hlášky paměť nepotřebujete. Mimo jiné máte možnost zmenšit či zahodit nějaký buffer nebo cache. Dále systém umí dynamicky zvětšit velikost swap file... Možností je řada. *Cokoliv* je lepší, než prostě odstřelit proces, pokud se pokusí přistoupit k paměti, kterou před tím úspěšně alokoval.

Samozřejmě chápu, že zanícený linuxák vždy ví, že situace na Linuxu je nejlepší. Když Linux lže o paměti, a pak OOM Killer losuje a odstřeluje procesy, je to samozřejmě nejlepší možné řešení :). Jde o obdobu slepé skvrny. Tahle typicky zabraňuje vidět jakékoliv nedostatky či nevýhody návrhu Linuxu, kterých je pohříchu značná spousta. To potom nezbývá, než ukamenovat toho, kdo na podobné nedostatky upozorňuje, a jít zase spokojeně hýčkat Tuxe. To vše samozřejmě bez ohledu na technická fakta. Hlavní je víra, fakta jsou poddružná.

Ano, "lhaní o paměti" lze vypnout (tuším dvěma parametry). Bohužel pak systému poměrně lehko dojde paměť.

Ano, aktivace OOM Killeru je dost výjimečná, stejně jako jakákoliv jiná forma nedostatku paměti. To nic nemění na tom, že jde o špatný koncept. Srandovní je i "imunizace", která dělí procesy na ty, které opravdu chcete běžet, a na ostatní, které může kdykoliv sejmout OOM Killer.

Pokud jsem si správně všiml, tak Linux používá "late binding". Když proces alokuje paměť, požadavek je prohlášen za splněný, a to prakticky bez ohledu na to, jestli je paměť dostupná. A teprve když aplikace poprvé přistoupí ke dříve alokované paměti, proběhne ten "late binding". Obdobně použití CoW nevede k rezervaci paměti (která bude třeba v případě, že proběhne zápis do stránky), a paměť se "hledá", až když ke změně stránky opravdu došlo. Obojí vede k tomu, že (nějaký) proces umře ve chvíli, kdy někdo potřebuje paměť, kterou již dříve (ze svého hlediska úspěšně) alokoval, a "late binding" nyní volnou paměť nenajde.

No vida, umíte si udělat thread pool. Umí to i řada autorů SW pro unixy (včetně Linuxu), a kupodivu se to zdá být preferovaný model.

Vytvoření procesu je vždy dražší, než vytvoření threadu. Switch mezi procesy je vždy dražší, než switch mezi thready jednoho procesu. Synchronizace mezi procesy je vždy dražší, než mezi thready. Spotřeba paměti je vždy vyšší v případě procesů, než v případě threadů. Ano, procesy jsou náročnější (výjimou může být nevhodná implementace threadů, viz LinuxThreads). A jak jsem psal, ani worker procesy vám nezajistí, že chyba v jednom procesu nesloží zbytek služby (viz chyba jediného dispatchera, viz corrupted shared resources typu shared memory nebo file, viz locknutý resource a deadlock). Rozdíl je v tom, že ve Windows umí Service Manager každou službu znovu nahodit, pokud spadne; na unixech je daemon jen proces jako každý jiný, a jeho startování (včetně security kontextu), ukončování a akci při případném pádu procesu musíte řešit ve vlastní režii.

Jinak příklad, který uvádíte, je nereálný. V praxi workery pracují se sdílenými daty, a hromadu času sežere synchronizace. Bohužel když jsem naposledy hledal použitelné benchmarky, našel jsem jen takové, které srovnávaly Solaris (který je technicky daleko lepší, než Linux) s Windows, a vyšly ve prospěch Windows.

Kdyz uz tu tak zasvecene hovorite o sprave pameti, mohl byste mi vysvetlit, proc na Windowsich strojich neustale vidim tak pulku instalovane RAM nevyuzitou, zatimco system swapuje, az disk drnci? A, BTW, proc ten disk na Windows drnci a na Linuxu ani moc ne?

Linux, po urcite dobe provozu zaplacne veskerou pamet, az na par kilobytu. Pokud si tu pamet nevynuti aplikace, narve se tam buffer a cache. Windows ma furt pulku volnou, cache je vetsinou dost mala a i kdyz nekdy naroste, po case se zase zmensi. Proc? K cemu je dobre mit tolik pameti jen pro ozdobu? At date RAM kolik chcete, situace je vzdy vicemene takovato.

P.S.: Nevim, jestli jsou rozdily v chovani mezi serverem a workstejsnem. Windows server jsem uz delsi dobu nevidel.

Já myslím, že zrovna my dva jsme o tom spolu už mluvili. A pokud si vzpomínám, tak závěr diskuze byl, že nevíte, co je dirty page, a o memory managementu nevíte vůbec nic, takže nemělo smysl v diskuzi pokračovat.

Ale když to zkusím jednoduše... Na prvním místě je třeba se zeptat, kde vidíte půlku RAM "nevyužitou". Každá stránka paměti může být v různých stavech, může mít různé užití, a vyjádřit jedním číslem "využití" paměti je dost ošemetné. Je tou "využitou" pamětí paměť, která obsahuje program zavedný v RAM, který je i na disku? Je využitou pamětí soubor (třeba video), který je do paměti namapovaný? Je využitou pamětí cache? Pokud vám jeden systém "využití" paměti počítá jiným způsobem, než druhý, je srovnání čísel o ničem.

Teď teorie; podotýkám, že drasticky zjednodušená. RAM se dělí na stránky velikosti 4kB. Některé stránky jsou jen obsahem souborů, zavedeným do paměti. Příkladem je třeba spustitelný program, který máte jak v RAM, i na disku. Podobně i stránka s rozepsaným dokumentem může být v RAM, a zároveň ve swap file. V obou případech tomu říkejme clean page. Když někdo potřebuje kus paměti, můžete vybranému procesu sebrat nějakou clean page (třeba takovou, která se dlouho nepoužívala), a přidělit tomu, kdo paměť potřebuje. Protože ta sebraná stránka má kopii jinde (na disku), můžete pro ní prostě sáhnout na disk, když jí daná aplikace bude zase potřebovat.

Jiným typem stránek jsou dirty pages. To jsou stránky paměti, které existují jen v RAM. Pokud byste takovou stránku uvolnil, nějaká aplikace přijde o data (to samozřejmě OS nedělá). S dirty pages se dělá to, že se jejich obsah zapíše do swap file, a tím se z nich udělají clean pages.

Obecně je dobré mít co nejméně dirty pages. Clean pages totiž můžete kdykoliv uvolnit, a přidělit někomu, kdo je zrovna potřebuje.

Windows XP a starší byly psány s tím, že paměti je málo. V době uvedení Windows XP bylo požadavkem jen 64MB RAM. Strategie memory manageru byla taková, že pokud je nějaká stránka dirty, je třeba jí co nejdříve uložit do swap file (udělat z ní clean). To je s malým množstvím paměti velmi dobrá strategie, protože vám dává možnost okamžitě reagovat, když někdo potřebuje více paměti, než kolik máte zrovna volné RAM (pokud totiž máte hromadu dirty pages, tak bude aplikace na alokaci paměti čekat, dokud nevyswapujete dost dirty pages, což může *velmi* dlouho trvat). Zároveň to vysvětluje, proč Windows hrabou po disku, i když je ještě dost volné RAM. Dělají to proto, aby bylo minimum dirty pages, a aby tedy kdokoliv bylo možné přidělit RAM tomu, kdo jí potřebuje. Ovšem pokud máte paměti daleko více, než potřebujete (to v roce 2002 nebylo aktuální), hrabete po disku zbytečně.

Protože dnes má PC běžně 2GB RAM a více, je ve Windows Vista použit jiný algoritmus. Ten zápisy do swapu odkládá (pokud to to lze), a provádí je s nízkou prioritou I/O operací. Pokud má stroj více paměti, než kolik je jí běžně třeba, je tahle strategie výhodnější. Obecně nelze stanovit nějakou zaručeně nejvýhodnější strategii, podobně jako třeba u alokátoru místa na disku; jde vždy o odhad, heuristiku.

Teď mi řekněte upřímně: pochopil jste, co jsem napsal?