RAM-ba swap-olás - újra

Kernel

2004-ben egyszer már kibeszéltük a RAM-ba swap-olást. Most újra felbukkant egy ilyen funkcionalitást megvalósító projekt. A compcache az ún. "in-memory compressed swapping"-ot valósítja meg. A használatával létrehozhatunk egy RAM-alapú blokk eszközt (ramzswap), amelyet azután swap lemezként használhatunk. Az erre a lemezre swap-olt lapok tömörítettek és magában a memóriában kerülnek tárolásra.

A compcache szerzője, Nitin Gupta beküldte a patchét az LKML-re a mainline kernelbe olvasztási céllal. Az LWN - egyelőre csak előfizetőknek elérhető - cikke a témában itt olvasható.

A projekt honlapján elérhető néhány benchmark itt. A projekt egészének célja nem csak a teljesítmény javítása, hanem swap nélküli rendszereken olyan alkalmazások futtatásának biztosítása, amelyek egyszerűen nem indulnának el a kevés memória miatt. Például - az LWN cikke szerint - az Edubuntu tartalmazza a compcache-t annak érdekében, hogy csökkentse a telepítője RAM igényét.

A szerző szintén megemlíti a flash eszközökre való swap-olásból adódó kifáradás problémakörét, amelyet ezzel a megoldással szerinte eliminálni lehet.

Az egész projekt annyira perverz, hogy kénytelen voltam kipróbálni. A "telepítése" végtelenül egyszerű. A forráskód letöltése és lefordítása után a use_ramzswap.sh szkript segítségével betölthetjük a két szükséges kernelmodult és beállíthatjuk a [disksize(KB)|memlimit(KB)] paramétereket (alapértelmezetten, paraméterek megadása nélkül beállítja automatikusan).

Ezután a /proc/ramzswap alatt ellenőrizhetjük a működést: 


DiskSize:	  513376 kB
NumReads:	     137
NumWrites:	    2585
FailedReads:	       0
FailedWrites:	       0
InvalidIO:	       0
PagesDiscard:	       0
ZeroPages:	      67
GoodCompress:	      86 %
NoCompress:	       1 %
PagesStored:	    2518
PagesUsed:	     677
OrigDataSize:	   10072 kB
ComprDataSize:	    2668 kB
MemUsedTotal:	    2708 kB

Útmutató a telepítéshez és a használathoz itt. A projekt honlapja itt.

( saabi v | 2009. 05. 27., sze – 10:12 )

Ennek 2004 óta lett valami értelme?

Ave, Saabi.

"Milyen alkalmazások nem indulnak el nélküle?"

Azt mondtam, hogy "Ha ott valóban segít". Fogalmam sincs, hogy segít-e valamin egyáltal. Ha segít, akkor van értelme. Ezt állítottam.

"Desktopon én mén nem találkoztam ilyennel."

Desktop? Hogy jön ide? De ha már desktop. Mondjuk egy Quake 3-at indíts el swap nélkül. Nem vagyok benne biztos, hogy menni fog. Próbálkozhatsz más játékkal is. De a VMware is esélyesen szarul fog nélküle futni.

--
trey @ gépház

Lehet valamit félreértettem. A swappra írtad, hogy néhány alkalmazás nem indul nélküle?

A desktop dolog (is) onnan jön, hogy azt használok és azon tudom kipróbálni ezt a dolgot. Meg, hogy ha nincs swapom, az okozhat -e valami gondot. Ezért kérdeztem, hogy milyen alkalmazás lehet példa. A q3-at meg megnézem majd, hogy muzsikál.

>>: sys-admin.hu :<<

Van olyan /verz cucc, ami megnézi, hogy van-e x MB RAM és mellette y MB swap, ez az egyik oldala a dolognak.
A "hol érdemes..."-re a választ már leírták: az SSD-k jelenleg még nem tartanak ott az írhatóság szempontjából, mint a mágneses elven működő megoldások, ergo olyan gépekben, ahol SSD-n van a háttértár, ot mindenképp el lehet ilyesmin gondolkodni -- ha rendelkezésre áll a szükséges memória. Olyan esetben persze értelmetlen, amikor intenzíven használja a rendszer a swapterületet, de még akkor is kerülendő, ha a fizikai memória (buffer cache nélküli) foglaltsága normál üzemben is jelentős.
Ami még előnyös, hogy ezzel a módszerrel kritikus, egyébként titkosított partícióra/diszkre rakott rendszernél a swap használatánál megspórolható az oda/vissza titkosítás is.

Hat

$ free
total used free shared buffers cached
Mem: 8171984 7755984 416000 0 146052 4685108
-/+ buffers/cache: 2924824 5247160
Swap: 8795548 82252 8713296
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/sda5 partition 8795548 82252 -1

Gyanusan van.

Hordozhato eszkozokben megeri vele foglalkozni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kérdés: a ki/be tömörítés külön kernel threadben fut? (még nem próbáltam, majd talán ma este...) Mert ha igen, akkor a ma már általánosan mindenhol található többszálú/többmagos processzorok éppen üresjáratban futó magján elég nyugisan elfutkoshat.
---
Linux is bad juju.

viszont kérdés, hogy ez beállítható úgy, hogy mikor aksiról megy a gép, ne csináljon ilyet, mert akkor a minél kisebb terhelés (minél többet pihenjen a cpu) az ideális. bár, az is kérdés, hogy mennyit jelent ez gyakorlatban aksiról üzemelve. valaki csinalhatna mérést.

_________________________
Hogyan?

Válasz saját magamnak: kipróbáltam és valóban szépen külön szálon végzi a dolgát. Viszont, amikor elfogyasztottam minden memóriát és compressed swapot is, akkor sikerült olyan helyzetet előállítanom, hogy keményre fagyott a gép! Sysrq sem működött. Az OOM killer ilyet önmagában nem szokott előidézni nálam, szóval csak csínján a compcache-sel, mert gyanítom, hogy valami bug lehet benne.

A másik baj az volt, hogy amire én szerettem volna használni (nagy gráfok manipulálása), arra nem hatékony a tömörítés, feltehetően a sok, látszólag random helyre mutató pointertől. Az original size kb 2/3-ára tudta csak összenyomni, ami kevés ahhoz, hogy értelme legyen szívni vele.
---
Linux is bad juju.

Persze, csak azért egy memory dumpot ugyanebből az alkalmazásból lényegesen jobban lehetett tömöríteni. Persze nyilván az nem csak page-enként tömörít és lzo-nál lényegesen hatékonyabb (és lassabb) algoritmussal. Mindegy, ettől függetlenül a compcache erre az alkalmazási területre nem annyira alkalmas. Még egyszer talán valami modelcheckerrel is kipróbálom, azok is zabálják a memóriát rendesen, de gyanítom, hogy ott is hasonló eredményre fogok jutni.
---
Linux is bad juju.

( NagyZ v | 2009. 05. 27., sze – 10:33 )

ennek mi ertelme van? X ramom van ugyanugy, hogy a rendszer most azt X memoriakent, vagy Y memoriakent es X-Y swapkent latja, szerintem tok8.

Merevlemez nélküli rendszernél ez biztos, hogy igaz?

Első eset:

Van 2GB fizikai RAM-od.

Második eset:

Van 2GB RAM-od, amiből mondjuk 512MB virtuális. Azaz van 1.5 GB RAM-od, plusz 512 MB virtuális memóriád, de az utóbbi tömörített. Magyarul az alkalmazások számára több az elérhető memória. Nem?

--
trey @ gépház

ennyi erovel tomoritsuk be a normal memoriat is... nem sok ertlemet latom, gyakorlatilag adunk a szarnak egy pofont, szerintem.

abbol az 512 tomoritettbol lesz mondjuk 600 hasznalhato (mert nem hinnem hogy a binaris szemetet amit az appok kihanynak lehetne jol tomoriteni. persze ha sok benne a szoveg...)

"ennyi erovel tomoritsuk be a normal memoriat is..."

Nem hinném, mert a swap-ban a pillanatnyilag nem használt dolgok találhatók. Ennek a tömörítése nem ugyanaz, mint az egész memória tömörítése. Vagy?

"mert nem hinnem hogy a binaris szemetet amit az appok kihanynak lehetne jol tomoriteni."

Nem tudom. Ez a mostani gépemen.

OrigDataSize: 10072 kB
ComprDataSize: 2668 kB

--
trey @ gépház

Persze lehetne minden memóriát tömöríteni, de (gondolom) itt pont az lenne a lényeg, hogy ezt minimális módosítással el lehessen érni. Némiképp egyszerűbbnek tűnik egy jól bevált, működő és széles körben használt rendszerszolgáltatás megtrükközése, mint a világ összes programját módosítani, hogy igény esetén tömörítse az általa használ memóriaterületet vagy írni valami virtuális memória layert a kernelbe.

A "bináris szemetet" amúgy szerintem kiválóan lehet tömöríteni. A sok program még a képeket is kitömörítve tárolja a memóriában, irgalmatlan méretű üres helyek repkednek jobbra-balra, a szöveg még a kisebb része a dolognak. Ha láttál már coredumpot tudod miről beszélek. :)

Így nézve nem tűnik a dolog akkora marhaságnak.

kernel coredumpom mar evek ota nem volt (de most hogy leirtam, tuti lesz ;), de alkalmazasok neha elszalnak egy hatrahagynak egy szep kis core dumpot. Nem neztem belejuk, de meretuk alapjan csak az adott alkalmazas memoriateruletet tartalmazza.
---
/* No comment */
Ketchup elementál megidézése a sajt síkra

Jelentése: kikapcsoljuk az alkalmazások szétszállásakor keletkező "core" fájl létrehozását. Valószínűleg ezért nem láttál ilyet mostanában. Csinálni amúgy elég könnyű: 


ulimit -c unlimited
cat
< Ctrl-\ >

Esetleg ha biztos akarsz lenni a dolgodban, "stty -a" paranccsal megnézed, hogy milyen billentyűkombináció generálja a QUIT -ot, és a cat indítása után azt nyomod le.

( Arbiter | 2009. 05. 27., sze – 11:15 )

Elmondaná nekem valaki, hogy a valóságban hol érdemes használni ezt a technológiát?
A folyamatos tömörítés, gondolom, nem elhanyagolható CPU overhead-del jár majd.
Hol lehet az ilyesmi kifizetődő?

Olyan helyen, ahol annyira lassú a diszk, hogy nem éri meg swappelni?
Olyan gépben, amibe nem lehet fizikailag több RAM-ot pakolni?
Beágyazott eszközökben?
Olyan gépben, ahol annyira fontos az I/O teljesítmény, hogy még a nagyon ritkán használt swap területet is inkább RAM-ba teszik?

Vmware-es virtuális gépeken mindenképp. Külön öröm hogy miután nem használod a gépet, a hoszton futó VM szerver szépen kipakolja a virtuális gép RAM-ját lemezre. A virtuális gép miután iszonyat lassan felébred és tud futni, nekiállja beolvasni a kiswappolt blokkokat a memóriába. Mindkét művelet a hoszt gép vinyóját eszi, hatványozottan lassú, ráadásul nyilván több virtuális gép fut a szerveren.
Ha csak a virtuális gépek használnák már jobb lenne a helyzet. Kifejezetten zavaró egy kávészünet után, vagy reggeli, hétfő reggeli login után kivárni, míg minden feléled.

( balintdavid | 2009. 05. 27., sze – 11:35 )

Sam&Max-et idézve: "This is a completely unusable thingamabob"
---------------------------------------------
"Az aptitude-nak nincs Szuper Tehén Ereje" :D

( Coornail | 2009. 05. 27., sze – 11:39 )

Egy dolgot mindenki elfelejt: ha ezt hasznaljuk akkor tobb memoria jut a file-cache-nek, ami mar szerveren is oriasi elony.

( budee | 2009. 05. 27., sze – 12:27 )

hmm, ezt meg kellene buheralni egy kis 

/proc/sys/vm/swappiness

bizgetessel, es egesz erdekes dolgok jothenek ki belole.

Szerk.: Hmm, a swap particiot miert nem lehet tomoriteni? Ezek alapjan azzal is sokat lehetne nyerni.

Az lehet. Mérni kéne. 

DiskSize:	  513376 kB
NumReads:	     208
NumWrites:	    6908
FailedReads:	       0
FailedWrites:	       0
InvalidIO:	       0
PagesDiscard:	       0
ZeroPages:	     131
GoodCompress:	      90 %
NoCompress:	       2 %
PagesStored:	    6777
PagesUsed:	    1398
OrigDataSize:	   27108 kB
ComprDataSize:	    5527 kB
MemUsedTotal:	    5592 kB

Most ha jól értelmezem, akkor 27MB-nyi adat kb. 5 MB-ra van tömörítve. Minderre 5 MB fizikai memóriát használ.

--
trey @ gépház

Én tapasztalok. Eddig Virtualbox(ami a RAM 40%-át megkapja)+Netbeans mellett már elég lassúcska volt, meg ha sokáig magára hagytam a netbeans-t, akkor egy 2 percig éledezett. Most ezeket nem tapasztalom. 2GB RAM van a gépben.
Ahogy nézem elég szépen összetömöríti a dolgokat, kb. a 20%-ára az eredeti méretnek:


$ cat /proc/ramzswap
DiskSize: 1951866 kB
MemLimit: 131072 kB
NumReads: 4654
NumWrites: 94867
FailedReads: 0
FailedWrites: 0
InvalidIO: 0
PagesDiscard: 0
ZeroPages: 9704
GoodCompress: 100 %
NoCompress: 0 %
PagesStored: 72834
PagesUsed: 18324
OrigDataSize: 291336 kB
ComprDataSize: 72172 kB
MemUsedTotal: 73296 kB
BDevNumReads: 572
BDevNumWrites: 12329

Nekem volt egy ismerősöm, aki az Amigás időkben azzal vakította az r=1 usereket, hogy éppen egy olyan tömörítési algoritmuson dolgozik, amivel bármekkora adatot be tud csomagolni veszteségmentesen 3kb-ba, majd ki is. :)
Azt is mondta, hogy csak azért nem beszél velünk technikai részletekről, mert az le akarja védetni és irdatlan sok pénzt keresni vele. Mindezt úgy 1992 környékén. Azóta sem hallottam róla, úgyhogy biztosan még vadul kódol valahol egy sötét szobában. :D

wow, még jó hogy nem volt internet amikor én ezt a c64-en találtam ki :)
igaz én 5 bájtba akartam tömöríteni X byte-ot, lévén hogy -n -től +m-ig tárolja a számokat, lebegőpontosan. a gyakorlati teszten elvérzett :D aztán utánaolvastam mi is az a lebegőpontos szám ;)

szerk.: még jó hogy nem volt internet = mármint nekem. lehet akkoriban az egyetemeken már volt...

miért? bármikor tudok írni olyan tömörítőt, aminek van olyan bemenő adata, amit 0byte-ra tömörít és ki is tudja csomagolni.
más kérdés persze, hogy csupán egy ilyen bemenő adat létezik és a tömörítőprogram akkora, mint amekkora ez a specifikus bemenő adat :]

( Caro | 2009. 05. 27., sze – 14:03 )

Szerintem jó ötlet. Nemrég szenvedtem meg egy géppel, amiben a 128M RAM-ból elhalt az egyik 64-es modulon egy bit, onnan kezdve gyk. használhatatlan (badram patch-el nem akartam szenvedni).
Mondjuk én más megközelítést használtam, betettem a gépbe egy 128 RAM-os videókarit, voltak oldalak, hogy hogyan kell megoldani a videokari RAM-jába a swapolást.
Azt ezzel kombinálva már lehetett volna effektív ~250-300 mega, azon már elég sok minden elfutna. Hátránya, hogy utána max vesa-va lehet az X-et használni.
Egyébként nekem az jutott eszembe, hogy ehhez nem kell szerintem kernel patch, elég ha az ember csinál a /dev/shm-en egy file-t, compressed loopal csatolja és csinál rá egy swapot.
Bár ez gondolom gyorsabb/valami előnye biztos van.

Swap file-ra ugy nez ki ez nem lenne nagyon alkalmas:

"The design of the cloop driver requires that compressed blocks be read whole from disk. This makes cloop access very slow when there are many small scattered reads, which can happen if the system is low on memory or when a large program with many shared libraries is starting up."

http://en.wikipedia.org/wiki/Cloop

( simca | 2009. 05. 27., sze – 14:04 )

Kiváncsi lennék hogyan ejti a "swap" szót aki "swapolás, swapot" formában toldalékolja :)

--
"Dude, you can't take something off the Internet.. that's like trying to take pee out of a swimming pool."

( xobor | 2009. 05. 27., sze – 14:53 )

Ööö Jauntynál ezt vettem észre kb egy hónapja:

xobor@freyr:/$ cat /proc/swaps
Filename Type Size Used Priority
/dev/ramzswap0 partition 62468 43508 100
/dev/sda3 partition 530136 0 -1

Egész pontosan Crunchbang Linux. Eddig azt hittem, h a compcache megoldás alapfelszereltség. Nekem ez a /proc/ramzswap nem létezik

Nem pontosan értem, h most akkor van-e vagy nincs :)

Nekem egész tetszik az ötlet, és utánagoogliztam. Elvileg intrepid óta van alapban, csak nincs bekapcsolva. Bekapcsolni pedig ilyesmi:

sudo vi /etc/initramfs-tools/initramfs.conf
itt rákeresel arra, h "COMPCACHE_SIZE", és beállítod, pl ha azt akarod, h a ram 25%-át használja rá, akkor:
COMPCACHE_SIZE="25 %"
Ezután:
sudo update-initramfs -u
és reboot.

( budee | 2009. 05. 27., sze – 15:34 )

Hmm, es gondolom igy a mogotte levo swap particio is tomoritett, tehat ha ezt csinalom: 


use_ramzswap.sh 0 /dev/mapper/crypt-swap

Akkor kapok egy tomoritett swap particiot?

( dii | 2009. 05. 27., sze – 17:03 )

Jó, nem pontosan kapcsolódik a témához, de azon agyaltam, hogy van 4-8Gb memóriám a gépben amit most már két zacskó tej áráért be lehet szerezni, akkor a felébe, egy ramdiskre, be is zúzhatnám az operációs rendszert úgy ahogy van. Vagy ez hülyeség?

jó drága felétek a zacskós tej :D

hát, hogy pont ram, azt nem tudom, de olyan megoldások voltak korábban (és régebben a magas memória árak miatt vérzett el), amik hdd-t emuláltak. Tehát beleraktál sok-sok-sok giga ramot, aztán rákötötted a gépre ide kábellel.

_________________________
Hogyan?

( samuf v | 2009. 05. 27., sze – 19:32 )

Jó ötletnek tűnik.

Valaki említette, hogy miért nincs a teljes ram tömörítve. Azért nem minden esetben hatékony ez a tömörített megoldás, pl. ha csak egy byte-ot kell átírni a ram-ban, akkor eléggé belassulhat, hiszen nem 1 byte-t kell átírni, hanem ki kell csomagolni egy block-ot, átírni az adatot, aztán becsomagolni, majd visszaírni. A swap viszont pont arról szól, hogy nagyobb mennyiségű adatot kell egyszerre mozgatni. És akkor még nem beszéltünk a fregmentálódásról, hiszen egy 1k-os block lehet, hogy egyszer 512B foglal, máskor meg 700B-ot.

Ami meg a többlet cpu terhelést illeti, mostanában úgyis azon lovagol mindenki, hogy nincsenek kihasználva a magok a cpu-ban. Lassan amúgy is több mag van a gépben, mint ahány Giga Ram :)

Csak, hogy hozzátegyem a magam hülyeségét a témához szerintem a buli az lenne, ha a compcache képes lenne hagyományos swapparticiót/file-t használni (ha van) tömörítve és az oda kiírt lapokat egy dedikált memóriarészbe cache-elni, akár titkosítva is.

Lehet, hogy ezt most is meg lehet barkácsolni, de szerintem nem ugyanaz, hogy játszok mondjuk a swap eszközök prioritásával. Nem tudom igazából, mert nem ismerem a linux kernel swappelési "szokásait", de biztos jobb lenne egy okosan tuningolható, integrált swap alrendszer.

( Yorirou | 2009. 05. 27., sze – 20:46 )

Valahol a PPA környékén várható csomag belőle?

Nem hiszem, teljesen felesleges, hiszen, ahogy fentebb is olvasható része az ubuntu kernelnek. A különbség talán csak a modulok elnevezésében van. Nálam itt vannak a kérdéses modulok: /lib/modules/2.6.28-12-generic/kernel/ubuntu/compcache/tlsf.ko és compcache.ko néven.

Ha szeretnél vele kísérletezni, akkor használd az eredeti compcache szkriptek általam megpiszkált változatát a ki- bekapcsolgatáshoz:
use_ramzswap.sh
unuse_ramzswap.sh

szerk:
Sajna a paraméterezés része felejtős. :) Kétségtelen, hogy a letölthető forráskód újabb és okosabb verzió. Az ubuntus változatban nincs backing swap.

root@freyr:/home/xobor/desktop/compcache-0.5.3# modinfo compcache
filename: /lib/modules/2.6.28-12-generic/kernel/ubuntu/compcache/compcache.ko
description: Compressed RAM Based Swap Device
author: Nitin Gupta
license: GPL
srcversion: EA8EA5496ED1E0C3A19D7B8
depends: lzo_decompress,tlsf,lzo_compress
vermagic: 2.6.28-12-generic SMP mod_unload modversions 586
parm: compcache_size_kbytes:compcache device size (in KB) (ulong)


root@freyr:/home/xobor/desktop/compcache-0.5.3# modinfo ./ramzswap.ko
filename: ./ramzswap.ko
description: Compressed RAM Based Swap Device
author: Nitin Gupta
license: GPL
srcversion: 11D02164495BE62FD9F4189
depends: lzo_decompress,xvmalloc,lzo_compress
vermagic: 2.6.28-12-generic SMP mod_unload modversions 586
parm: disksize_kb:ramzswap device size (kB) (ulong)
parm: memlimit_kb:ramzswap memory limit (kB) (ulong)
parm: backing_swap:Backing swap partition (charp)

szerk2:
Oksa. Sikerült paraméterezhetőre butítani. :) ./use_ramzswap.sh 4096 pl beállít egy 4 MByte-os csereterületet.

( turul16 v | 2009. 05. 27., sze – 23:36 )

Igeretes dolognak tunik.
A "valodi" swapet is lehetne tomoriteni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( uid_1526 | 2009. 05. 28., cs – 09:09 )

Ennek már legalább van valami értelme, de nem sok. Swap ott kell, ahol kevés a RAM. Ezzel a módszerrel a kevés RAM felét meg tudjuk tömörítéssel növelni, de cserébe agyonvágjuk a filerendszer cache-t, mert ahol eredetileg is kevés volt a RAM, ott így még azt a keveset is megfelezzük. Azaz továbbra is a lassabb háttértárra fogunk várni.
SSD-nél tényleg lehet értelme, az írási műveleteket olvasásira cseréljük.

( turul16 v | 2009. 05. 29., p – 07:59 )

Lehetne dinamikus a merete.
Amig nem swapel a dolog. addig is lefoglalja memoriat ami helyett lehetne cache is ott.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.