Zram #2

 ( log69 | 2017. december 10., vasárnap - 23:01 )

Előzmény itt.

Nézegetem jó ideje Zram tömörítésének arányát, és továbbra is úgy van amit írtam egyik előző blogomban, hog 3x és 5x között van a ráta. Mindegy milyen fajta a felhasználás (VM, játék, egyéb). Sőt, mivel custom Live ISO-ba is beletettem alap csomagként, így teszteltem kisebb memória kiosztással (2G és 1G) és a VM-ben futó guest OS memóriájánál is ezt a rátát látom.

Ugye zram-config csomag telepítésével (kell egy reboot) létrejön pár új blokk eszköz zram0, zram1 stb néven (lásd lsblk parancs), melyek összesen a fizikai RAM felét fogják megkapni. Alapból nem foglal memóriát a megoldás és a fizikai memória és a lapozó fájl közé illeszkedik be logikailag, vagyis:

Ha fogy ki a RAM, akkor Zram-ba dolgozik a kernel, ha az is fogy ki, akkor jön a lapozó fájl.

Ha a legkisebb tömörítési rátával számolunk, akkor:

n/2 + n/2 * 3 = n * 4/2 = n * 2 (duplázza a fizikai memóriánkat)

Ha a legnagyobbal, akkor:

n/2 + n/2 * 5 = n * 6/2 = n * 3 (triplázza)

Tehát mondhatjuk hogy átlagban 2,5-szeresre növeli gépünk memória kapacitását.

2G -> 5G
4G -> 10G
8G -> 20G
16G -> 40G

(Ubuntu 16 x64 alatt tesztelve - olyan terhelésnél is ment tovább, ahol Zram nélkül már jóval túlléptem volna a fizikai memória határát).

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Akkor is írtam, most is írom:

Az ilyen blog bejegyzéseket jó olvasni :)

Én meg annak örülök hogy születnek még jó innovációk a szabad szoftveres világban és nagyon érdekesnek tartom az egész Linux ökoszisztémát, hogy kell is az iparnak hogy nyílt legyen, de közben mindenki akar venni a közös eredményből is és így végül közös szekeret "kell" tolniuk (valamennyire persze, mert van más technológia is, de akkor is).

Minél inkább saját egy termék, annál inkább értékesebb a cég számára és túl nagy lesz ahhoz hogy ingyen odaadja, és ezért nem is kap annyi támogatást. Nagy cég, van pénze, van terméke, csinálja, ember max megveszi.

Ha viszont a fejlesztők nagy részének nincs pénze az egész történetre (Linux kernellel kapcsolatban olvastam 4000 emberévnyi fejlesztési időt), akkor csinálják amit tudnak - és az van, hogy a közös kalapba tudnak beledobni és a közös eredményt tudják használni - ami viszont folyamatosan fejlődik, ráadásul sokkal nagyobb léptékben az egyéni fejlesztéshez képest. Tehát az látszik fejlesztői szempontból, hogy dobjak 1-et a kalapba és 99-el többet kivehetek. Ráadásul ismétlődően.

Tehát a túl kicsi se jó meg a másik véglet sem, így érdekes módon a közép mértékű szinten keletkezik nagyobb szinergia. Persze millió dolog van, de a végeredmény mégis ez:

Zram eredetileg compcache:
https://wiki.ubuntu.com/Compcache

Szerző (freelancer dev, open source aktivista :)
https://wiki.ubuntu.com/OliverGrawert

Egyébként meg EL vonalon is van lehetőség, még 6-os ágon is:
https://access.redhat.com/solutions/443893

Zeller, te nem akarod feldobni a CentOS-edre?

Szep es jo, evek ota hasznalom, de sajnalatos, h a POC szintjen megallt a projekt.
Legalabbis a velemenyem szerint amig swap-kent teszik bele, addig egy remek atbaszas, amivel frankon osszekavarnak mindent (monitorozas, human readable output stb.).

Miért átverés? Meg miért kavarja össze a monitorozást?

Mert osszemossa a valodi swap-ot es tomoritett memoriaval. A valodi swap rohadt lassu a zram-hoz kepest. Eleve a swappiness is vonatkozik igy mindkettore.
Valamint azert is, mert zram device-okat letre kell hozni, alapbol ha jol emlekszem, core-onkent egyet hoz letre, de sok magos cpu-n kifut a limitbol es akkor fail-el az init script.
Soroljam meg?

Azt szeretnem latni, h a swap az swapkent latszik, a tomoritett ram pedig tomoritett ramkent. Raadasul ne statikusan, hanem mondjuk megadom, hogy tomoritse a 60%-at a meglevo ramnak.

Szoval ez egy szep ganyolas.

Kapcsold ki a diszk swap-ot, maris rendben lesznek a szamok, illetve az initszkript javitasa nem nagy szam - raadasul ha jol remlik van olyan disztro amiben JOBB initszkript van hozza, mint a masik disztroban.

Az elso compcahce patch-tol kezdve hasznalom (0.2, 2.6.28tol, mivel custom kerneleken futnak a cuccaim nem volt nagy kuzdes betenni), sosem volt vele problemam. A notebookjaimon csak azert van swap az ssd-n, hogy legyen hova hibernalnia...

Nekem pl. tetszik amit csinal, OK, ertelmes ember nem overbookolja a RAM-ot meg igy sem irrrgalmatlanul, de +10% bele kell hogy ferjen, kulonben amugy is OOMK aratas veszelyes a rendszer. :) VM-ek mellett (host/guest) nagy josag.

Ami nem tetszik, hogy a tmpfs-en es a swap-on kivul nem igazan kezelik az egyeb filerendszerek a gumiszeruen nyulo/csokkeno helyet. :DDD

> Kapcsold ki a diszk swap-ot, maris rendben lesznek a szamok, illetve az initszkript javitasa nem nagy szam

Ha nem hasznalom, akkor is. Kosz szepen. Ezert kar volt.

> - raadasul ha jol remlik van olyan disztro amiben JOBB initszkript van hozza, mint a masik disztroban.

Ha az az ajanlas, h legyen core-onkent 1 device, de nem lehet annyit letrehozni, akkor nem lehet jol megcsinalni. Max. jobban. Szoval igen, lehet ganyolni.

> ertelmes ember nem overbookolja a RAM-ot meg igy sem irrrgalmatlanul

De, ez a lenyege. Ertelmes ember addig nyujtozkodik, amig tudja. Ha erre lehet hasznalni, akkor erre hasznalja.

(De, lehet annyit letrehozni. ??? Nem ertem a felvetest. Most lecsekkoltam neked egy viszonylag friss telepitesu initkonfigot: zramstream_size = ramsize/4/cpucount... ??? Es megy ez epp 16CPUn.)

$ cat /proc/cpuinfo |grep -c ^processor
64

Ha jol emlekszem, ezen mar nem ment, de talan gyengebbeken sem.
A core-ok szama idovel novekszik, ahogy jonnek ki az uj cpu-k.

OK, a Tied nagyobb. :D Mondjuk a ramsize az byte-ban van... ;) Szoval mennie kene szvsz.

Tehát mondhatjuk hogy átlagban 2,5-szeresre növeli gépünk memória kapacitását.
Ne, azért ilyeneket ne írjunk, ez így nagyon félrevezető.

A zram nem csodaszer. Nem fogja mágikusan többszörösére növelni a szobádat. Ez inkább egy puha matrac, ami a falhoz csapódásnál (hirtelen kiesik pár GB swapre) tompítja az ütést, de közben elvesz a szoba méretéből.

Korábbanmár írtam én is róla.

Pontosan az a lényeg, hogy ne tekints rá úgy, mint ami sokszorozza a memóriádat - kellemetlen meglepetés ér, ha mohó módon túlkonfigolod. A tömöríŧett memóratartalom valójában nagyon is fogyasztja a fizikai memóriádat, lényegében egy holt teherként foglalja a helyet, amit az alkalmazások nem tudnak használni. A fennmaradó tömöríŧetlen területen kell mindennek elfutnia. Ha pl 2GB-ból 5GB-ot akarsz csinálni, akkor gyakorlatilag sikerült a 2GB-osból egy 1GB-os gépet csinálnod. Ha az a bizonyos 4GB csak áll és a CPU szinte soha nem nyúl hozzá, akkor ez ok. Ez, ilyen arányban azért nem gyakori. A Live ISO mondjuk pont jó alkalmazási példa, mert (overlay/tmpfs/squashfs megoldástól függően) a filerendszer jelentős része is a memóriában punnyad, anélkül hogy bárki hozzányúlna, ráadásul filerendszernél a ki/betömörítés miatti lassulás sokkal elfogadhatóbb kompromisszum, mint egy futó alkalmazás aktívan használt memóriaterületénél.

A default konfig - tömörítetlen méret max a fizikai memória fele - általános célú használatra szerintem megfelel, az előnyeivel találkozol a hátrányaival szinte sosem. A jó tömörítési arány miatt elhanyagolható a fizikai memória veszteséged. Pl 8GB-ból lesz 7GB-od, cserébe kaptál egy 4GB-os gyors swapet.
Ennél följebb viszont csak nagyon átgondoltan szabad menni, ha az adott alkalmazási területen ez éppen jól adja ki, vagy tényleg nagyon kényszerhelyzetben vagy. Jártam már így, 8GB-os gépen ~12GB-os java heap size-os gráfadatbázison kellett szimulációt futtatni, ne tudd meg mennyire volt lassú, és a zram méret növelésével innen már csak romlott a helyzet. De tény, hogy végül lefutott. És ez csak 1.5x-es szorzó, 1.85x-nél (8GB-ra 7GB zram swap) már teljesen használhatatlanná vált a gép.
---
Régóta vágyok én, az androidok mezonkincsére már!

Látom hogy mondani szeretnél valamit :)

A gráf db mennyire tömöríthető? Ez elég speciális helyzet nem? Gondolom ott egyben kell elérni és minden x-edik hívásnál lapozás történhetett, nyilván semennyire nem látok bele, de logikusnak tűnik hogy lassú lesz ha lapoznia kell folyamatosan.

Szerintem nem úgy van hogy leveszi felét a fizikai RAM-nak, hanem inkább nem vesz le semennyit és ahogy nő zram foglaltsága, úgy veszeget le szépen - lásd free kimenete.

Részemről 5-6 GB-ot foglaló játék mellett virtuális gépeket futtatok 8 G fizikai rammal + zram úgy, hogy előtte zram nélkül a egyedül játék el sem indult (ha nincs swap). Nem látom megérvelve részedről hogy miért ne úgy tekintsek rá mint 2,5x RAM. Ha kell még mem, akkor lapoz - és mivel azt tömöríti, így többet tud lapozni - mindezt memóriában, tehát gyors lesz.

Azt akarom mondani, hogy praktikusan nagyon máshol vannak a határai, mint ahova gondolod, és igen, tud ártalmas lenni, ha túl nagyra nő. De mindegy, ezen ne vesszünk össze, én nem akarlak győzködni, csak aki elolvassa lásson árnyaltabb tapasztalatról is beszámolót.

Nem volt abban a gráfos tesztben semmi speciális. Kb 2.5x-3x tömörítési aránya megvolt annak is. A JVM heap kezelése, garbage collection sweep-ek biztosan rátettek a problémára, mert a GC végig touch-olja a memóriát minden ciklusban. De ez kb minden java-s dologra igaz. Sőt több-kevesebb mértékben minden managed-memóriás nyelv runtime-jára is, mindennapi használatban nehéz kikerülni, hogy semmi ilyet ne használj.

Lehet, hogy félreérthető volt, én sem állítom, hogy statikusan foglal helyet, ahogy telik a swap úgy fogyasztja a ramot is, csak nem érdemes engedni a méretét az egekig nőni, mert a végén már nagyon trashelni fog.
---
Régóta vágyok én, az androidok mezonkincsére már!

Azzal egyetértek, hogy ha olyan programot akarsz futtatni, ami eleve alig fér el a memóriában, ahhoz nem jó, mert ott csak azt érjük el hogy sok lesz a lapozás a működése közben és így dög lassú - érthető, mivel nem fér el a memóriában.

Fogalmazhatunk úgy szerintem, hogy több olyan folyamat egyidejű futtatását lehetővé teszi, amelyek külön igen de együtt nem férnének el a memóriában zram nélkül, míg zram-mal igen. Ezeknél gyorsan vissza tudja lapozni az adatot a tömörített memóriából, például task váltásnál. Tehát mégiscsak lehetővé tesz olyan dolgot, mely nélküle nem jól megvalósítható sima disk swap-pal.