Vlákno názorů k článku
Jak zrychlit Ubuntu od klokan - Nastavení vm.swappiness je zpravidla jedna z prvních věcí,...

Souhlas. Podotýkám že "optimistická alokace" se týká primárně Linuxu. Je to výrazně horší řešení než u Solarisu, HP-UX i Windows.

Na Linuxu byl problém s typicky unixovou sekvencí volání fork/exec. Když chce řekněme DB server, který má alokované 2GB RAM, spustit utilitu, tak provede fork/exec. Fork zduplikuje paměťový prostor aplikace, na dnešních implementacích pomocí CoW. To ovšem znamená, že na to volání potřebujete další 2GB RAM. Na PC s malou RAM to byl problém, takže se implementovala "optimistická alokace". To vedlo přesně k tomu co popisujete: alokace prakticky vždy projde, a když se pak aplikace pokusí alokovanou paměť použít, tak systém něco odstřelí pomocí OOM Killeru. Mimo jiné to programátory odnaučilo obsluhovat situaci kdy alokace selže. Velmi špatné.

Solaris zavedl funkce system() a popen(), které nevyžadují dvojnásobek RAM pro spuštění procesu. Solaris nepoužívá "optimistickou alokaci".

HP-UX sice používá "optimistickou alokaci", ale když začne paměť docházet, tak posílá aplikacím SIGDANGER. Aplikace se následně mohou nějaké paměti zbavit (třeba zmenšit nějaké buffery). Linux nic takového nemá. OOM Killer prostě vylosuje nějaký proces a odstřelí ho.

Windows podobně jako Solaris neprovádí "optimistickou alokaci". Navíc profesionální aplikace (MS SQL Server, Exchange, Oracle, Lotus Domino, MS Office) na Windows s nedostatkem paměti počítají, a když alokace selže, tak to vede typicky jen k selhání aktuální operace.
https://www.msoutlook.info/pictures/pst-outofmemory.png
https://i.stack.imgur.com/DnWKY.png

Dodnes používám vfork i přesto se to považuje za obsolete funkci. Náhrada moc neexistuje.

Bohužel vfork si moc nerozumí s multithreadingem.

... pagefile, ktery na windows navic umi automagicky rust).

Coz je na Widlich perfektni recept na fragmentovany swap, takze rozumny clovek po instalaci napevno nastavi nejakou rozumnou velikost.

Neni. Po nejake dobe na disku bude uz nejspis jen fragmentovane misto. Jestlize Widle budou potrebovat nafouknout swap, budou ho moci nafouknout jen do toho fragmentovaneho mista. A jestli soudruzi neco neudelali s alokaci mista na disku ve Widlich, tak by to take mohli placnout do prvniho volneho kusu mista, ktery najdou a ten muze byt rozsrotovany na 5000 kousku nejmensi mozne velikosti.

Samozřejmě pokud je k dispozici pouze fragmentované místo, tak se swap nafoukne tam. Ale jak tu už padlo, stává se to jen pokud swap dojde, což je dost extrémní situace. Navíc když se spotřeba paměti sníží, zmenší se i swap file, takže vám z něj zůstane jen nefragmentovaná část.

Ad jestli soudruzi neco neudelali s alokaci mista na disku ve Widlich, tak by to take mohli placnout do prvniho volneho kusu mista - takhle někdy nějaký alokátor na Windows opravdu fungoval? Nebylo to na FAT ve Windows 2.0? :)

Ad jestli soudruzi neco neudelali s alokaci mista na disku ve Widlich, tak by to take mohli placnout do prvniho volneho kusu mista - takhle někdy nějaký alokátor na Windows opravdu fungoval? Nebylo to na FAT ve Windows 2.0? :)

Ano, kdysi jsem cetl nejakou analyzu toho, jak blbe alokuji Widle NT, nejake 2.x. Pak to snad nejak zlepsili, otazka je, jak moc. Vsimnete si, ze ve Widlich je defrag disku, v Linuxu ne a presto mam po mnoha letech na dosti zaplnenem disku malou miru fragmentace.

root@esus:~# e4defrag -c /dev/sda3
......
Total/best extents 460928/386957
Average size per extent 202 KB
Fragmentation score 3
[0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
This device (/dev/sda3) does not need defragmentation.
Done.

To že OS nepoužívá memory overcommitment ještě neznamená že musí nutně přidělit fyzickou paměť před prvním přístupem k ní. Obecně jde ale o internals daného OS.

Pokud aplikace ve Windows paměť nepoužije, tak je "nejhorším" scénářem to že budou ty stránky po čase odswappovány. Stránka ale po alokaci není dirty, takže mám za to že ke swappování vůbec nedojde. A pokud by k němu došlo, tak ve Windows 10 se při swappování stránky zkomprimují a odswappují do RAM (a na disk jen pokud i tak dojde RAM).

Tak např. Bryan Cantrill (vývojář Illumosu/ dříve Solarisu, spoluautor DTrace) má určité výhrady k alokování paměti/ správě paměti v jádře Linuxu.
Na druhou stranu, i když se nám to nemusí líbit, tak Linux a v o hodně menší míře FreeBSD jsou na koni. HP-UX pod HPE i Solaris pod Oracle dožívají. Illumos jako jádro jistě má své opodstatnění, zajímavou práci dělají i kolegové z ostatních BSD a cítím tam docela hodnotnou výměnu znalostí z toho mála, co se mi dostane k uším. Linux to občas trochu moc vaří a potom se musí složitě opravovat to co je dlouho rozbité. Bylo by fajn, kdyby si někteří vývojáři Linuxu viděli více do úst, občas se podívali kolem, co je rozšířené řešení a přestali některé věci realizovat stylem "hurá do toho". Ono mít nějaký model, diagram a obecně používat metody softwarového inženýrství není úplně od věci. "Show me the code" by se mělo rošířit na "Show me the material, the code, the documentation with technical specification and model". Na druhou stranu, v dnešní době už je vývoj i Linuxu přeci jen dost na úrovni a přílišné excesy se podle mě nestávají (pocitově) častěji než v jiných vybrannějších společnostech.

tedy BFU trkne, ze uz toho ma otevreneho moc a nejake taby nebo programy zavre sam.

Tedy u browseru zavreni tabu bez restartu browseru moc nepomuze. Pamet, kterou browser schvati, uz nikdy nenavrati.

To nesmíš používat Palemoon nebo Firefox Jardo, kde je prohlížeč jeden proces a pokud leakuje paměť, tak se uvolní až po zavření programu. Jsou ale i jiné prohlížeče, kde je panel samostatný proces.