Zram / miért futok ki a RAM-ból?

Linux-haladó

Sziasztok,

Nem világos az alábbi. Egy virtuális gépbe 4 G RAM-mal Ubi 16-ot bootolva és zram-config csomaggal előtelepítve az alábbit teszem:

Nyitok egy Ruby shellt (irb) és azt mondom hogy a = "1111111111111111111111111111111111111" majd a = a+a parancsot ismételem, így exponenciálisan nő a változó által lefoglalt memória. Ezzel elmegyek 400 és 800 MB közöttig. Ebből több shellt nyitok és többszőr megteszem ugyanezt azért, hogy teszteljem a memória foglalást, de külön külön akkora processzekkel, amelyek még kilapozhatóak.

Ugye Zram felezi a fizikai RAM-ot és így összesen 2 G Zram-om lesz (2 x 1 G a 2 maghoz) és így 2 G fizikai RAM marad a 4-ből.

Viszont a memória foglalással nem tudok 2 G fölé menni. Miért?

7%-ra lenyomja a foglalt 2 G swap-ot Zram, és így még rengeteg swap-om lenne. A kernel miért nem cserélgeti nekem ki a fizikai memóriából az aktuálisan használtat (amelyik konzolra éppen visszalépek)? Lásd az alábbi képet:

Magyarul a kérdésem az, hogy ha lenyomja 7%-ra a swap-ot, akkor a maradék 93%-ot miért nem tudom tovább tölteni? Allocate error-t ír ki a shell.

Ötlet? Kösz.

  • 2527 megtekintés

( szilas | 2018. 02. 05., h – 19:37 )

Nem véletlenül zswap-ot akarnál használni? A zram csak egy alapból tömörítő memdisk. Így a swapra csak kevés ráhatása van. Vagy én tudom rosszul? Vagy nagyon félreértelek.
Egyébként is, mi a cél?

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Szerintem félreérted:

https://en.wikipedia.org/wiki/Zram

Cél hogy a fizikai memória és a disk swap közé ékelődjön egy tömörített memória, ami nagyban fékezi a disk swap használatát azzal, hogy csak akkor használja azt, ha már ő is telítődik. Ezzel nő a teljesítmény és a memória kapacitás (kicsi CPU-t beáldozva érte) és adott esetben olyan programot is el tudsz indítani, amely Zram nélkül nem férne el a memóriában.

Talán kevés hozzá a csomagot telepítened?
https://wiki.archlinux.org/index.php/improving_performance#Zram_or_zswap

Amennyire emléxem, még a 3.11 verzió előtti kernelekkel tudtál ezzel zram meghajtóra swapet beállítani, azóta már a zswap_enabled//max_pool_percent, amivel egyszerűbben, rugalmasabban és transzparensebben kezelhető az ügylet.

Akkor nem értettem félre. A régi nevén zswap kellene neked. Annak a fejlesztésével már leálltak, helyette lett a compcache.
Én is bűvészkedtem vele, de nem csodaszer. Ráadásul van egy nagy hibája, hogy megzavarja a gép (esetemben laptop) hibernáló funkcióját.
Sejtettem hogy ezt akarod, de szerintem (is)rosszul van beállítva.
Én úgy csinálnám, hogy létrehoznék egy adott(kicsi?) méretű ramdisket swapra formázva, hozzáadnám az fstabban, majd ugyanott beállítanám a prioritást is.
És így elvileg 3 lépcsős a ram adat kezelésed.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( gabrielakos v | 2018. 02. 05., h – 20:00 )

Java-nál azt mondanám h a JVM duplázni akarja a lefoglalt helyet, annyi egybefüggő(!) meg nincs.
Lehet h itt is ez a helyzet?

--
Gábriel Ákos

( wauf | 2018. 02. 06., k – 05:37 )

A kepbol egyertelmu mi tortenik:

A swap a tomoritetlen meretet hasznalja limitaciokent, ez megtelik.
Viszont a memoriabol csak 143M-et foglal, a tobbi foglalas meg nem swapbol megy.

Megoldas: a swap 3.5G-re novelese a 2G helyett

Ez is egyszeru: mert nem minden tartalom tomoritheto. Igy legrosszabb esetben tele lesz nem tomoritheto tartalommal.

A root cause persze az, hogy a malloc() C fuggveny csak lefoglal helyet a memoriabol (vagy hibat ad vissza hogy nincs eleg hely), viszont csak a lapozaskor derul ki, hogy az adott memoriatartalom mennyire tomoritheto. Mivel a swap-nak pont az a lenyege, hogy az alkalmazasok szamara transzparens (vagyis nekik nem kell vele foglalkozni, a kernel dolga) -- igy nincs mod arra hogy lapozaskor hibat jelezzen a kernel az alkalmazasnak.

Igy a "hasznalj n MB-ot" valojaban azt jelenti, hogy MAXIMUM n MB-ot hasznal swap-ra, amit megprobal tomoriteni, hogy kevesebbet foglaljon.

( saxus | 2018. 02. 06., k – 13:54 )

32 bites az irb?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem. Az egy Ruby script, a Ruby meg 64 bites:

$ which irb | xargs file
/usr/local/bin/irb: a /usr/local/bin/ruby script, ASCII text executable

$ which ruby | xargs file
/usr/local/bin/ruby: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=803cdaf29b7e13bda89115e74c6ce91d5f1474cc, not stripped

( log69 | 2018. 02. 07., sze – 19:24 )

Egyéb ötlet esetleg? Miért nem lehet kihasználni a tömörítés által meghagyott helyet a swap-ból?

Igazából ha megnézed a képet, akkor a free parancs kimenete full-nak jelzi a swap-ot, miközben a legalsó sorban látszik hogy valóan majdnem 2 GB foglalt, csakhogy az 7%-ra le van tömörítve, tehát 93%-nak szabanak kellene lenni.

Vagyis 0 MB helyett 1800 MB-ot szabadnak kellene jeleznie a free-nek.