Dotaz: Potrebujem swap/swap to file pri 128GB RAM?

[ja osobne]

Zdravím, mám pracovný desktop s 128GB RAM, Manjaro Linux s BTRFS filesystémom na Samsung 980 NVME SSD a moja otázka je: Potrebujem swap alebo swap to file? Pri inštalácii som swap partíciu nevytvoril (kôli SSD) a teraz rozmýšľam či som to spravil dobre. BTRFS mám zašifrované LUKSom takže už asi ani SWAP partíciu nespravím. Je potrebné to riešiť nejakým SWAP to file ? Vďaka.

Odpovědi

[čavo]

Budete tam spúšťať aplikácie, ktoré naraz využíjú viac ako 128 GB RAM? Tak potrebujete. Budete stroj hibernovať. Tak potrebujete a mal by mať aspoň 128 GB. Inak je zbytočný.

[Zum]

Tak potrebujete a mal by mať aspoň 128 GB. Inak je zbytočný.

To by platilo kdyby se RAM cela zaplnila a to pravdepodobne nenastane jen tak. Navic se snad uz dnes provadi komprimace ale to si nejsem jisty. Chtelo by to zjistit kolik je celkem dat v RAM a dle toho s nejakou rezervou treba 1/2 navic vytvorit soubor pro hibrnaci. Pripadne pak zvetsit. Je dost nepravdepodobne ze budes hibernovat kdyz budes mit zaplnenou celou RAM, pravdepodobne ty nejvetsi zrouty nejdriv ukoncis.

[Andrej]

Swap nemá smysl. Hibernace nemá smysl.

Proč by někdo hibernoval desktop? Uspání „do RAM“ je nesrovnatelně rychlejší. (Pokud tedy vůbec chci desktop někdy vypínat nebo uspávat, což většinou nechci, protože pak se do něj nedostanu přes SSH a wake-on-LAN zpravidla buď vůbec nefunguje, nebo drží systém 100% času v provozu.) Když chci delší uspání, které má přečkat i případný výpadek napájení (tj. nemám tam UPS atd.), proč raději neuložit práci a počítač nevypnout? Boot je dnes mnohem rychlejší než probuzení z hibernace.

Navic se snad uz dnes provadi komprimace ale to si nejsem jisty.

Příliš mnoho nejistoty. (Hint: Neprovádí. To by se uživatel musel hodně ohánět, než by si takový zpomalovací výdobytek nastavil.)

Úvahy o kompresi RAM a velikosti (zbytečného) swapu navíc vůbec nedávají smysl: Proč by se stránky z RAM s komprimovanými daty nemohly zapsat do swapovacího souboru komprimované? Pak je úplně jedno, „kolik je celkem dat v RAM“. Pokud by snad nějaký (hypotetický) mechanismus komprese RAM neumožňoval swapovat přímo komprimovaná data, byl by to asi tak 1001. důvod, proč něco takového nepoužívat.

[k3dAR]

Swap nemá smysl. Hibernace nemá smysl.

Proč by někdo hibernoval desktop? Uspání „do RAM“ je nesrovnatelně rychlejší. [...] wake-on-LAN zpravidla buď vůbec nefunguje, nebo drží systém 100% času v provozu.) Když chci delší uspání, které má přečkat i případný výpadek napájení (tj. nemám tam UPS atd.), proč raději neuložit práci a počítač nevypnout? Boot je dnes mnohem rychlejší než probuzení z hibernace.

to je jak (uplne) u blbejch... ty nesmysly tu opakujes uz po nekolikate:
1. WoL z hibernace bezne pouzivam, funguje a system je pri hibernaci 0% casu v provozu, jen LAN ceka
2. hibernaci pouzivam nekolikrat za den
3. hibernace narozdil od suspendu nenechava odemcenej LUKS
4. boot + spusteni hromady app s dostanim do puvodniho stavu je nekolikanasobne pomalejsi nez kdybych probouzel z hibernace na rotacaku

[Andrej]

1. WoL z hibernace bezne pouzivam, funguje a system je pri hibernaci 0% casu v provozu, jen LAN ceka

Záleží na použití toho systému. Pokud je přijatelné, že se musí napřed nějak (netriviálně) „aktivovat“ (WoL + SSH do initramdisku pro vzdálené odemčení LUKS), aby se dal použít, může to třeba i fungovat.

Pokud se ovšem LUKS otevírá sám takovým tím klasickým způsobem pomocí klíče uloženého v TPM2, který TPM2 zpřístupní, pokud je v pořádku SecureBoot a pokud nebyl přeflashovaný firmware … inu, potom hibernace nemá žádnou výhodu vůči uspání — zatímco uspání nechá v RAM master key, probuzení z hibernace (stylem LUKS+TPM2) automaticky odemkne LUKS (a dostane master key do RAM), klidně bez autentifikace toho, kdo probuzení způsobil…

Jinak, asi jsem neměl štěstí na motherboardy, UEFI a jejich WoL. Vždycky se mi to probouzelo, kdy nemělo, a neprobouzelo, kdy mělo. Že bych se na to mohl spolehnout, až budu 1000 km daleko, k takovému dojmu jsem bohužel nikdy nedospěl.

2. hibernaci pouzivam nekolikrat za den

Zajímavá záliba. No, já zase několikrát za den chlastám whisky. Každý má něco takového … svého.

3. hibernace narozdil od suspendu nenechava odemcenej LUKS

První hesla, která mě napadají: AMD SME, Intel TME… Takže ne, u moderního hardwaru není LUKS v žádném smyslu „ponechaný odemčený“. Hodně štěstí při cold boot útocích a získávání klíče z RAM pod SME nebo TME. Nic z toho sice nebude neprůstřelné, je to proprietární a bude to mít bezpečnostní díry, nicméně … ten cold boot útok na SME a TME zatím (na rozdíl od Yetiho) nebyl viděn.

Každopádně, pokud to máš opravdu dobře zabezpečené, bude to bezesporu zajímavá konfigurace: Musíš tam tedy mít napřed dost obsáhlý initramdisk, do kterého to nabootuje po WoL a který umí spustit svůj vlastní SSH server, do kterého se pak můžeš přihlásit a odemknout LUKS pro pokračování „probuzení“ z hibernace (nebo bootu)…

Jinak, pokud se LUKS odemyká automaticky za asistence TPM2, může být hibernace zranitelnější než uspání: K získání master key z počítače uspaného do RAM potřebuješ provést cold boot útok včas a v místě, kde počítač zrovna je, zatímco pro získání master key z automaticky odemykaného hibernovaného počítače je cold boot nesrovnatelně snazší; můžeš hibernovaný počítač napřed odpojit a odnést, kam potřebuješ.

Každopádně záleží na požadavcích na ten systém. Pokud příslušný systém má za úkol existovat trochu samostatně a musí se umět aktivovat bez zásahu uživatele, obvykle v tom bude hrát roli jistý kompromis (který SME / TME částečně řeší, ale nic není dokonalé).

4. boot + spusteni hromady app s dostanim do puvodniho stavu je nekolikanasobne pomalejsi nez kdybych probouzel z hibernace na rotacaku

S dobrým desktopovým prostředím mi to nepřipadá problematické.

Pokud je momentální konfigurace desktopového prostředí jaksi důležitá a obtížně / pracně dosažitelná, dá se říct, že patří k uživatelovým „datům“ a měla by tedy být náležitě zálohova(tel)ná, obnovitelná atd.

[k3dAR]

samozrejme ze pri probuzeni z hibernace neodemykam LUKS automaticky, ale v initramdisku je dropbear (v Archu asi) , pripojim se pres ssh(klicem), zepta se me na luks heslo, zadam a bootne

ad pri resume z ram, odemcenej luks krome nevim jak moc teoretickeho vytazeni klicu z ram sem hlavne myslel to ze pak zalezi na pripadnem bugu v screensaver/lockscreen/dm(login) zda se nekdo dostane k obsahu disku...
jinak vim ze pred casem sem narazil na nejake DIY reseni kdy se pred suspendem udela v ram "initramdisk" udela do nej chroot, zamkne luks, a po resume je luks potreba odemknout, nemuzu to ted najit, ale podobnej(stejnej?) concept ma si tohle, nicmene hibernaci povazuju proste za jistotu, mozna i tim ze s tim proste na svem HW's problemy nemam ohledne opotrebeni SSD vubec neresim, i po letech kazdodeniho uspavani ma SSD zbyvajici zivotnost mnohem delsi nez moralni zastarani jeho velikosti :)

[alfa]

hibernaci povazuju proste za jistotu, mozna i tim ze s tim proste na svem HW's problemy nemam

Nekdy to muze byt jen problem s Fedorou.

[Teddy_cz]

My jsme museli udělat alespoň 8G swap, protože virtualizace dost "lajdala". Teď už nevím, zda to byl wmware nebo virtualbox. Stejně jsme je nakonec opustili a přešli qemu , ale swap nám zůstal.

[Max]

Nepoužívám swap, ani na stroji, kde mám jen 32GB ram.
SWAP použiješ jen při hibernaci, jinak ne. Já osobně jen uspávám, nepoužívám hibernaci. Pokud děláš práci, která vyžaduje více ram, než máš v PC, tak je rozumnější tu paměť dokoupit, než řešit swap, obzvláště v době, kdy je cena pamětí na minimu.
Zdar Max

[Andrej]

Swap nepotřebuješ nikdy; je krajně nežádoucí.

Pokud dojde RAM, má nastoupit OOM killer a (především!) si toho má uživatel co nejdřív všimnout.

Swap způsobí, že si leckdy uživatel ničeho nevšimne a za pár dnů má zničená SSD, na která se celou tu dobu „nenápadně“ psalo 500 MB/s. Ask me how I know.

Mimochodem, swapuje se i bez swapu. (Další důvod, proč se swapem nic navíc nezískáš.) Každý přístup k souborům je pod kapotou implementovaný jako (obdoba) mmap(). Tudíž všechny binárky, všechny otevřené soubory atd. atp. se podle potřeby načítají do RAM a pokud bude RAM nedostatek, stránky, které nejsou anonymní, tj. mají „za sebou“ ekvivalent na disku, se využijí k jiným účelům.

Což může, mimochodem, při hojném použití zapisovatelných souborů a nedostatku RAM mít podobný zničující efekt na SSD jako swap. Jen je takový scénář krajně nepravděpodobný … pokud ten stroj neprovozuje něco jako Ethereum nebo Solana validátory a podobné chuťovky, které si mapují extrémní spousty zapisovatelných souborů a způsobují ještě extrémnější spousty špinavých stránek.

Je potrebné to riešiť nejakým SWAP to file ?

Existuje nějaký problém, který bys potřeboval řešit? Pokud ne, doporučuji nic neřešit. Rozhodnutí vyhnout se swapu bylo naprosto správné; swap nemá na dnešním systému co dělat.

[Want]

Nemáš pravdu. Swap umožňuje "ošálit" virtualizované systémy, vyklouznout ze situace kdy pracuješ s velkými grafickými soubory, aj.

Pochopitelně je to závislé na množství dostupné RAM. Jako hranici bych viděl 32GB RAM a samozřejmě také způsob použití.

[Vtipnéř]

Swap nepotřebuješ nikdy;

Dovolím si nesouhlasit. Na manželčině starém počítači, který se nedávno rozloučil navždy, bylo maximum RAM (4 GB). Ze začátku vše fungovalo k naprosté spokojenosti, ale jak se webové prohlížeče stávaly rozmařilejší a rozmařilejší, stále častěji se počítač dostával do stavu, kdy prakticky nereagoval. Použití swap vše vyřešilo.

Jirka

[Max]

Vážně si myslíš, že zde uplatníš argument o 17 let (protože cokoli novějšího dávalo v klidu 8GB i více) starém PC, který už nežije? :D
Zdar Max

[Vtipnéř]

Je to argument proti tvrzení Swap nepotřebuješ nikdy. Kdyby u toho PC neodešla základní deska, sloužil by dosud, ale bez swapu by to nešlo. Snažím se chápat Andrejovy argumenty, např. že lepší než používat swap je přikoupit paměť, ale jeho kategorická prohlášení mě vadí.

Jirka

[Andrej]

Tvrzení je vhodné interpretovat v kontextu otázky, která hovoří o 128 GB RAM.

[Andrej]

Měl jsem počítač se 768 MB RAM, do roku 2009 v každodenním použití, do roku 2016 jako (sadomasochistickou) zálibu s arch32 atd. atp. (Pak začaly problémy s Chrome, na PCMCIA se sice dalo sehnat WiFi 802.11ac Wave 1, ale Wave 2 už žádné nebylo atd. atp.)

Na tom↑ počítači jsem měl (na obou USB 2.0 portech) nejrychlejší (podle testů) flashdisky, jaké se daly sehnat, a každé cca 3 měsíce jeden z nich putoval do koše. Byl na nich samozřejmě swap, jak jinak, což fungovalo hezky paralelně.

Takže ano, děsivé historky kolem malé RAM chápu. Reagoval jsem ovšem na dotaz tazatele se 128 GB RAM. Já osobně nemám swap ani na desktopu (128 GB), ani na noteboocích (32 GB) a dokonce ani s 16 GB RAM kdysi dávno jsem swap neměl. (Zajímavé je, jak dlouho bylo 16 GB RAM použitelných; pro mě mezi lety 2010 a 2022. Moorův zákon skutečně cca od roku 2005 nefunguje.)

Stále bych trval na tom, že tazatel swap nepotřebuje.

[Vtipnéř]

Stále bych trval na tom, že tazatel swap nepotřebuje.

S tím souhlasím, ale tvrzení "Swap nepotřebuješ nikdy" jsem nebral jako radu tazateli v kontextu dotazu, ale jako obecné tvrzení. Nepochopení patrně bylo na mé straně.

Díky za vysvětlení

Jirka

[Heretik 《小魔神》]

Ne.

To je krátká odpověď. Dlouhá odpověď je:

Největším žroutem na desktopu bude jistě Firefox, který ale ani při 150+ otevřených tabech nedokáže využít více než 32G RAM. Sláva Rustu, swap v něm nehrozí, neboť při vytečení limitu 32G jednotlivé taby raději crashnou než by se pokusily nějak swapovat.

Pro uživatelské virtuály (což je první nejpraktičtější využití takové paměti) je swapping v hostiteli vyloženě škodlivý.

Uvedenou instalaci považuji za korektní pro pracovní stroj.