Na serveru LinuxAndUbuntu vyšel návod pro začínající uživatele jak zrychlit Ubuntu. Nejprve se seznámíte s vm.swappiness, poté zrušíte indexování souborů.
Pak omezíte aplikace, které se spouští po startu a můžete vyzkoušet preload. Dále můžete používat „lehčí“ aplikace a desktopová prostředí a na závěr můžete systém „vyčistit“.
sice chapu ze Unity ma svoji urcitou jednoduchosti urcitejm lidem(nesouvisejici s jednoduchosti) co nabidnout, ale ja pouzivam vyhradne Xfce na jakemkoliv zeleze uz nekolik let, ten desktop je proste Desktop, klasickej old school DESKTOP... a vsechno ostatni jsou jen slabe nahrazky ;)
![~[,,_,,]:3](https://i.iinfo.cz/r/avatar-default.gif){kind=avatar}
To mě se tolik osvědčil Openbox (se základem LXDE), že už mě používání něčeho jiného (DE) dokáže rozhodit - naprosto jsem zanevřel na řešení "udělám to za tebe".
Pokud máte čas, pár hodin, tak přechod z DE na WM můžu jenom doporučit - menší zátěž CPU, víc volné RAM, děje se vám jen to, co chcete, aby se dělo.
Mám 32GB RAM a stejně swap používám. Když začne OS swapovat, tak to poznám a beru to jako upozornění, že mám něco zavřít. Přiznávám, že nebudu úplně standardní příklad člověka s PC (Unity3D, GIMP, Blender apod. spuštěné najednou). Ale princip si myslím, že je univerzální: swap mít. Protože je lepší, když se najednou všechno zpomalí, ale dá mi to možnost něco vypnout, než když hodiny běžící aplikace najednou zbuchne s tím, že nemůže alokovat paměť.
Důvodem je fakt, že většina programů nedokáže na nedostatek paměti rozumně reagovat a prostě spadnou. Schválně se někdy koukněte, co je v běžných programech jako reakce na selhání new. A to ještě nejdeme do detailu, že na některých OS vám malloc neselže nikdy (optimistická alokace) a spadne vám to až při pokusu do té paměti zapsat. Důsledkem je situace, že drtivá většina programů při nedostatku RAM jednoduše spadne. Pokud provozujete jakýkoliv program, kde nechcete, aby vám nečekaně spadl, tak se swap vyplatí.
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
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.
to oddaleni se projevi zpomalenim pocitace (swapovanim na hdd). tedy BFU trkne, ze uz toho ma otevreneho moc a nejake taby nebo programy zavre sam. ale kdyz neco spadne natvrdo, tak je to vycitano jako vadny program nebo nedejboze vycteno primo mne jakozto spravce pocitace.
jde o BFU. sam si taky umim pohlidat hranice a vim co se deje kdyz vidim ze jsem na hrane s ramkou. ale BFU to nezvladne. a pote co je nejaky program ukoncen z nedostatku ramky uz je pozde na nejakou upozornujici hlasku, kterou BFU by stejne jen odklikl bez cteni
V souvislosti se swapem a pamětí se mi osvědčil zswap. Pro ty, kteří neznají, jde v zásadě o mechanismus, že když má dojít k přesunu dat z RAM na disk, provede se napřed pokus data zkomprimovat (a komprimovaná je pak podržet v RAM). Teprve když komprimace nezmenší jejich velikost nebo je překročen limit pro komprimovanou paměť, se ukládá běžným způsobem na disk.
Ten rozdíl je znát. Můžu vřele doporučit. V konfigurační souboru zavaděče stačí k jádru přidat zswap.enabled=1.
