8GB RAM, 8GB partícia pre SWAP... screenshot s task monitoru:
https://i.imgur.com/iShVUYc.png
skúšal som všemožné nastavenia z:
https://askubuntu.com/questions/768136/how-can-i-hibernate-on-ubuntu-16-04
a mnoho ďalších stránok... Mám Ubuntu 18.04.
To je malo:
https://itsfoss.com/swap-size/
Pre istotu davam 2nasobok. Par GB na disku nemoze vadit.
to by asi stacit melo, teda pokud se nepletu pri hibernaci se do swapu nahrava jen pouzita ram a jeste k tomu komprimovane, nicmene sem to nikdy nezkousel s min a ze zvyku stejne vsude nastavuju swap velikost "ram + 5%"...
kazdopadne:
1. moznost hibernace v shutdown menu vidis? co se stane po aktivaci?
2. co se stane pri: sudo systemctl hibernate
3. co se stane pri: sudo pm-suspend (pokud neni, tak po doinstalovani baliku pm-utils)
4. co se stane pri: echo disk | sudo tee /sys/power/state
4b. co zobrazi: cat /sys/power/state
pokud to neoznami rovnou error, ale nezhibernuje, co mas v: dmesg | tail
pokud se hibernuje, ale pak neprobere, co mas v: dmesg
pripadne mas v /etc/initramfs-tools/conf.d/resume radek obsahujici:
RESUME=UUID=uuid-tveho-swap-oddilu
Pokud vím, tak před hibernací OS mj. virtuální paměť "uklízí", není to o tom, že je 20% swapu zabraná, tak je už jí k dispozici jen 80%.
Viz. např. tady: https://wiki.archlinux.org/index.php/Power_management/Suspend_and_hibernate#About_swap_partition/file_size
13. 8. 2019, 11:35 editováno autorem komentáře
Ale tak to potom potrebuješ nekonečnú SWAP,... čo ak mám 8GB RAM, 32GB SWAP, a mám 7.8GB RAM obsadené, 29GB SWAP obsadené (áno i to je možné pri určitých situáciách), čo potom? Malo by to stačiť, podľa mňa je rozumné když to funguje na základe používaného RAM, nie ceľkovej kapacity. To by pak pri 128GB RAM bolo koľko SWAPu potrebného?
Je mi to blbý se připomínat, že jsem vám to říkal, ale já jsem vám to říkal
Asi řešením by bylo kdyby šlo nakonfigurovat OOM killer aby začal fungovat, když počet anonymních stránek překročí určitou mez. Teď je to tak, že než se OOM killer spustí, zpravidla mezitím zkouknu jeden díl seriálu červeného trpaslíka (ne na tom samém zařízení, pochopitelně)
pamet mi dojde vyjimecne a v tech pripadech pritomnost swapu proste neco odswapuje a na OOM tedy ani nastesti nemusi dojit, ale nemuze ovlivnit chovani OOM i nastaveni chovani swapu, tedy swappiness?
Se swappinenes je docela potiz, vlastne s celym swapem. Existuje spousta scenaru, pro ktere ruzne nastaveni neni vhodne.
Situace:
1) Mam 64bit program a ten vyzere vsechnu dostupnou RAM - je uplne jedno, jestli pouzivam nebo nepouzivam swap a jak mam nastaveno swappiness, protoze system se stane nepouzitelnym.
2) Pouzivam vysokou hodnotu swappiness - asi nejlepsi reseni pro desktop - OS ma predswapovano a v momente, kdy spustim dalsi program, ma k dispozici spoustu stranek, problem je, ze znovunacteni je pomala zalezitost. Vsichni to zname - prepneme na dlouho nebezici program a muzeme jit na kaficko. Vyhodou je taky teoreticky vice mista pro cache.
3) Pouzivam nizkou hodnotu swappiness - dobre pro beh jednoho hlavniho programu, ktery si roste. Neco se preswapne, ale zase ne tak, aby to omezovalo vykon. Je to asi lepsi, nez zadny swap nemit, protoze k problemu dojde o trochu pozdeji, nekdy je ale lepsi, kdyz v takovem pripade nastoupi OOM killer drive. Jakmile ale spusite nejaky dalsi program, tak opet kaficko.
Kdysi jsem si s tim docela hral a dosel k reseni c 2) s polovicnim az celym swapem k pomeru RAM, swappiness okolo 90ti. Na desktopu samozrejme.
Nejlepsi reseni je ale pridat RAM, protoze ta je proste nesrovnatelne lepsi, nez resit swap, je to az tak dobre a rychle reseni, ze se dnes pouziva i ZRAM - tohle samo o sobe vypovida o tom, ze je lepsi komprimovat a dekomprimovat obsah RAM misto swapovani. Je pravda, ze se swapem a preswapovanim je system v lepsim stavu a lepe pripraveny, ale jsou situace, kdy to proste nestaci.
Pokud máte malý/žádný swap, tak každý proces může využít overcommit paměti jen do necelé velikosti RAM. Webový prohlížeč má sice procesů více, ale je to další důvod, proč swap mít a nevypínat ho. Máte-li výrazně více RAM než swapu, je potřeba upravit /proc/sys/vm/overcommit_ratio [Memory Allocation Limit = Swap Space + RAM * (Overcommit Ratio / 100))]
Jo. Proto jsem na pracovní stanici začal používat časného OOM zabijáka, což mi dost pomohlo od většiny problémů spojených s pomalým swapováním.
Četl jsem, že se dá používat jeden swap pro windows i pro linux, kdžy je multiuboot. Byl to nějaký fakt starý článek.
Nevíte o tom něco? :)
A jak se v lubuntu zjistí a změní aktuální nastavení swapu? Dá se to někde naklikat v GUI nebo se musí do příkazové rádky?
Dřív jsem dělal oddíl na swap a nastavoval to třeba v gparted nebo v instalátoru tak aby byl na začáítku disku (u středu plotny, kde je disk rychlejší) :) Ale má to ten problém že to ukousne místo na disku na pevno.. :D
Ale když se jendá o soubor tak nevím jak se s tím pracuje ani co dělá instálátor. Dělá si swap soubor velký jako RAM? Velikost soubporu se mění a nebo je daná kvůli fragemntaci? Asi ten instalátor prdí na to aby to dával na začáítek oddílu kvůli tomu že se přepdokládá SSD? Proč se na SSD nepoužívají nějaké speciální souborové systému jako je F2FS nebo další které existují. Nemají tak velké výhody nebo mizernou podporu? :)
Použít c:\pagefile.sys? Musel byste připojit NTFS oddíl přes FUSE (ntfs-3g, je to v userspace) a pak připojit jako swap ten soubor na NTFS. Budete tam mít dvojitou brzdu (filesystem, userspace), takže se to nevyplatí (při dnešních cenách SSD).
Souborový systém (FS) je velmi citlivá záležitost. Jeho ovladač běží v jádru, kde se chyby neodpouští. A když je v tom chybička (typicky souběh, který se projeví jen při určité konstelaci a zátěži), bude se to špatně hledat, bude to náhodně poškozovat data, což bude katastrofa na pověst systému/distribuce.[1] Co je větší problém, než stabilita FS, jsou doprovodné nástroje (fsck), což je typicky katastrofa, případně i menší problém vede ke ztrátě dat, což je opět velmi nepříjemné. Proto se dlouhodobě pokládá za důvěryhodný ext4 a ostatní systémy... no leda byste měl sysadmina, který to vyřeší/opraví jakýkoliv problém obratem ručně.
Co se týká F2FS, tlačil ho Samsung, Google z toho vycouval (viz výše) a vzal ho na milost až loni. Zřejmě v Androidu převládne, protože můžete vynechat FTL (Flash Translation Layer) a zařídit wear leveling softwarově (což je levnější). Vzpomínám si na "slavnou" keynote Microsoftu, který prohlásil že NTFS je nejlepší a potíže se SSD (resp. neschopnost využít jejich potenciál) jdou zcela na vrub výrobců HW, tudíž oni se svým FS nic dělat nebudou :-(
[1] práce na odstraňování regresí FS a jejich vypiplání pokládám za jeden z největších (a nejskrytějších, nejnedocenějších) darů firmy Red Hat komunitě
To asi nemusí chcípnout úplně, kernel tu trošku RAM dost možná někde najde. Ale čekám určítý zásek. Myslím, že do podobných situací jsem se dostával na starém mobilu se ZRAM (či jak se to tehdy zrovna jmenovalo).
Řéšením v obou případech (FUSE swap i ZRAM) by mohl být malý druhý swap s malou prioritou, který by se použil v podobné nouzi.
NFS – asi jste chtěl napsat „NTFS“.
jestli si dobre pamatuju, mel to tak resenej webOS na PalmPre (akorat uz nevim zda to bylo oficialni nebo komunitni vylepseni) mel jednak swap na ulozisti a pak swap v ram, kazde s jinou prioritou... btw: krome prupopnictvi na poli UI/UX bylo zajimave ze pouzival na deleni uloziste LVM, a protoze mel oficialni/nativni "root" tak slo ty lv zmensit, udelat klon, upravit init skripty aby startoval system z jineho LV atd, skoda ze to HP zabilo, kdo vi kde by ten system byl dnes kdyz po nem (od roku 2009) kopirujou UI/vlasnosit jak Android tak iOS...
Ne, nechtěl, ale teď koukám, že swap přes NFS už snad funguje, viz https://lwn.net/Articles/506527/
Co takhle vm.min_free_kbytes ?
https://www.noqcks.io/notes/2016/11/21/save-yourself-from-the-oom-killer/