Vlákno názorů k článku
Nový kód pro swap uspoří operační paměť a je rychlejší od a6b - a ma smysl pouzivat swap treba pri 64...

a ma smysl pouzivat swap treba pri 64 gb ram?

Napadá mi use-case, že napríklad chceš zaplniť celú ram povedzme in memory databázou, ale zároveň chceš mať poistku, že ak sa nejaký proces utrhne z reťaze a zaplní viac ram, tak ešte pridáš swap. Systém sa o niečo spomalí, ale nespadne.

U serverů s Garbage Collector jazyky ne - odswapování by GC asi zabilo a hlavně se runtime paměť ladí podle celkové velikosti RAM.

U desktopu obvykle taky ne. Já jsem swap vypnul od prvního 16 GB počítače, dneska pro mě výš, ale běžný uživatel si možná s 16 GB stále vystačí. Pokud počítač používá modelování, simulace obtékání, velké numerické výpočty apod, může to být jinak.

PS: Kdysi na pracovním Mac s 16 GB RAM na začátku běžel celkem ok, ale s přibývajícím časem začal příšerně zpomalovat. Jestli to bylo rostoucím software nebo si swapováním odrovnal SSD, těžko říct.

@a6b 26.01.2026 20:52
Některé programy počítají s tím, že swap soubor nebo oddíl existují. Prostá neexistence swapu může způsobit, že se tyto programy začnou chovat nedefinovaně, divně až nepředvídatelně. A nemusí swap vůbec používat. Stačí jeho neexistence.

Celkem by mě zajímalo, jaký to je software – zatím mě tahle situace potkala jen na stroji s FreeDOSem, kde si programy používající JEMM386 po spuštění uštěknou, že nemůžou na disku C: (který není přítomný) vytvořit swap. = )

Na Linuxu se mi tohle ještě nestalo, a to mám hodně velkou tendenci swap nemít.

Nebuďte slušnej. Řekněte pravdu. Jméno!

SWAP sa dá používať na viac než len ako "odkladanie stránok". Či už hibernáciu, zdielaný SWAP medzi VMs a hostom (kedy vieš presunúť stav otvorenej aplikácie) a podobne.

IMHO se komprimovaný in-memory swap používá třeba na Androidu ke snížení paměťové náročnosti (tuším že se tomu žíká zRAM). Možná má swap i jiné využití. Byl bych opatrný s tím ho považovat za neužitečnou technologii.

Pry bejvavalo za starych casu, ze swap byl potreba pro defragmentaci pameti a bez nej selhavali alokace vetsich souvislych bloku. Ale taky si pamatuji, ze moc sanci vynutit souvisle alokovane bloky nebylo, takze to muze byt jen nejaky hoax, nebo soubeh, ktery si uz nevybavuji.

Jako nejaky swap jsem aktivoval nedavno u instalace na novej disk.. jinak jsem fungoval celkem dlouho bez swapu myslim v pohode. Ale tohle nechapu... proc to zaswapuje 16M kdyz tam je 6.7G volneho :D Asi to pujde zas pryc..

$ free
               total        used        free      shared  buff/cache   available
Mem:        65261068     6280392     6709808     1437768    54437092    58980676
Swap:        6227964       16356     6211608

Souvisle alokované bloky (ve fyzické paměti) jsou potřeba na DMA – už kvůli němu se řeší alokace v několika zónách, protože periferie mohou mít omezení například na 24 (ISA) nebo 32 (±PCI) bitů adresy. Tak nějak bych doufala, že drivery si naalokují buffery dostatečně brzy na to, aby souvislé bloky volné paměti existovaly, ale jistota to není.

Je normální, že si systém odswapuje paměť „napřed“. Pokud toto chování způsobuje problémy, můžete přenastavit vm.swappiness.

zram není specifikum Androidu, je součástí Linuxového jádra. Na současném stroji ho používám, ale občas se mi stává, že se „uswapuje“ a OOM killer nefunguje tak, jak by měl, takže to způsobí zamrznutí.

Možná má swap i jiné využití.

Pokud myslíte zram, tak ten se chová jako blokové zařízení a swap je jen jedním (ikdyž asi nejčastějším) ze způsobů použití.

Od 2.6 (tedy prehistorie) mám vypozorováno, že bez ohledu na velikost RAM, pokud se Linux dostane do OOM situace, tak pokud nemá alespoň malý (16MB stačí swap), tak to často skončí nutností resetu čudlemkdy ani sysrq nepomůže.
Nevím proč tomu je, nezkoumal jsem, prostě těch pár mega to chce, klidně jako loopback fajl.
(hraní se swappines nepomůže)

Naposledy 6.18.1 se 128GB RAM, které zabrala jedna gamesa.

Zhruba od jadra 2.6.32 spolupracuji na projektu s vice nez milionem systemu na ruznych platformach, kde se swap nepouziva, a za to dobu doslo k nekolika set OOM situacich, ale nikdy se system nedostal do situace, kdy by z duvodu nedostatku pameti vytuhnul. Jadro samotne odswapovat nejde a je vzdy cele v pameti, takze zde problem byt nemuze. Realisticka moznost by byl bug v OOM notifieru, kam si kazdy ovladac muze zaregistrovat, co chce, ale ten, pokud si dobre pamatuji, v dobe 2.6 kernelu jeste neexistoval. Kazdopadne pokud to jste schopen reprodukovat, doporucuji zapnout NMI watchdog, zreprodukovat a poslat stacktrace, kde system vytuhnul.