Swapovací komprese

19.2.2012 18:41 | Přečteno: 2190× | Software | poslední úprava: 19.2.2012 18:43

Zajímavou, pro mnohé zřejmě novinkou je vlastnost jádra vytvořit pomocí zram swap oddíl uložený v paměti.

Menší zrychlení v případě většího swapování se koná, komprese přecijenom ušetří nějaké ty zápisy na disk. Stačí zakompilovat zram a nastavit mu počátačení velikost, mkswap /dev/zram0 a swapon /dev/zram0 (případně to hodit do skriptu po startu)

K zamyšlení tu je otázka, zda by nebylo vhodné též komprimovat swap oddíl na disku (zejména u počítačů s 1.5G paměti a chutí kompilovat firefox, jako je třeba teď ten můj).

A proto bych tento zápisek chtěl spojit s dotazem, jakej komprimovanej fs by nejlépe padl gigovému swapu? Má to vůbec cenu?

A jelikož jsem dlouho nenapsal, tak takové shrnutí - chodím na FEL, je to sranda, práce je dost :D

Stručnější jsem asi bejt nemohl ;)

       

Komentáře

[sasula]

A proto bych tento zápisek chtěl spojit s dotazem, jakej komprimovanej fs by nejlépe padl gigovému swapu?

Nejspíš asi žádnej. Smyslem komprimujících filesystémů je minimalizovat velikost dat uložených na disku. Představ si že máš swap soubor nějakým způsobem zkomprimovaný a nyní do něj chceš na nějaké místo zapsat. Zapisovaný blok ale může být větší než jiný zkomprimovaný blok, který má být přepsán, takže je potřeba pro něj na disku najít jiné místo, Tohle by ve výsledku vedlo k velké fragmentaci swap souboru a filesystém by se pěkně nadřel (musí invalidovat původní blok - zapsat na jedno místo na disku a pak ještě zapsat jinam samotný blok). Zatímco u nerostoucího a souvislého souboru se filesystém spokojeně fláká.

[David Heidelberg]

Díky, takhle jsem o tom neuvažoval. Kdyby alespoň šlo do swapu ukládat to co je už "předkomprimované" ZRAMem, protože když vidím vytížení cpu kolem 10% a disk se nezastaví, tak bych klidně jedno jádro obětoval na nějaký způsob komprese...

[Ivorne]

Mě teda přijde, že komprimovat to na disk je blbost. Na disku je s porovnání s tím, kolik toho tam můžeš naswapovat, místa hromada. A že by se tím nějak snížilo IO disku si taky nemyslím. Mám za to, že komprimovaná data vyžadují mnohem výraznější random access narozdíl od nekomprimovaných dat, která jsou orientovaná spíše na sekvenční přístup.

[Chulda]

Komprimovaný swap je tuším u vmware esxi 4.1, takže až taková blbost to asi nebude, ale je možné, že největší efekt je u více virtualizovaných systému než v běhu jednoho systému.

[xvasek]

On je vmware při overcommitu paměti (bez vmware tools, které naopak nějakou paměť ušetřit umí) taky pěkný šnek, třeba je to tou kompresí.

[Bedňa]

Swap v pamäti je nezmysel.

[Ivorne]

No já ti nevím, také mě to zarazilo. Jsem teda v tomhle ohledu laik, ale zdá se mi tam důležité to slovo "komprimovaný". Já to chápu tak, že například když naplníš 75% paměti, tak se ti míň používané části v té paměti zkomprimují. Mělo by to poskytnout více prostoru na ram a stále je to rychlejší než swap na disk. A přitom se to při běžném provozu s malou zátěží ram vůbec neprojeví.

Tohle jsem si teda odvodil jen selským rozumem, takže to neberte tak, jakože tomu nějak hrozně rozumím.

[R]

Ano, tak nejako by to malo fungovat. Za predpokladu, ze procesor (a pouzity kompresny algoritmus) je dost rychly, aby to nebolo pomalsie ako disk.

Alebo to moze byt ako nahrada swapu v zariadeniach, ktore nemaju disk.

[Limoto]

Není... z principu je to sice podívný, ale co si pamatuju, tak to mělo poměr komprese kolem pěti... a představa, že mám 4GiB RAM a udělám si z toho 3+dalších 5 "pomalých" není zlá.. mně se to osvědčilo

[Bedňa]

Tak občas sa to môže hodiď.

[Peter Golis]

Á, pán majster sveta komentuje niečo čo ešte nevidel. Vyskúšaj a potom poreferuj. Ja som s zram spokojný.

[Bedňa]

Podľa mňa je to Googlacky Compache, viem si to prestaviť nasadiť vo výnimočných prípadoch ako napríklad na prácu s RAW formátom ale inak je to fakt blbosť ako som písal, vždy je lepšie dokúpiť RAM, dobre vyľadený systém neswapuje. Prípadne embedded HW, odkiaľ asi pochádza aj nápad.

[Lol Phirae]

Zkoušel jsem na Androidu ZRAM i compcache, obojí na funkci (rostlináře) nemělo žádný kladný vliv.

[Bedňa]

Mám rovnakú skúsenosť. (nemyslím rostlináře :) )

[Michal Kubeček]

zejména u počítačů s 1.5G paměti a chutí kompilovat firefox, jako je třeba teď ten můj

Takovému počítači bych se ty chutě asi pokusil rozmluvit. :-)

[David Heidelberg]

ona samotná kompilace je vlastně v pohodě, ale jak se na konci pustí ld... tak to swapuje

[Limoto]

Myslím si, že komprese swapu na disku moc zásadní význam nemá, protože příčinou pomalosti není rychlost čtení, ale přístupová doba, kterou tím nezlepšíš. Trochu by to ale pomoct mohlo

[JS]

Divam se na to ryze teoreticky, ale me prijde jako hloupost oboji. Jak swap v pameti (rutiny v OS, co resi swap jsou uz z principu pomalejsi nez ty, co proste resi spravu pameti, protoze delaji I/O), tak kompresovany swap (u swapu je potreba, kdyz uz ho mas, aby ten pristup byl nejrychlejsi mozny; pokud je potreba optimalizovat prostor na disku, je lepsi zacit resit neco jako hierarchicke uloziste nebo neco takoveho).

Navic konkretne v Linuxu mi prijde swap nesmyslny. Z moji zkusenosti (zrovna dneska me to nastvalo a konecne jsem to vypnul), mam 4GB RAM a (z historickych duvodu) 1GB swap. Pokud aplikace zacne (polehoucku) leakovat pamet, bude se swapovat, a nakonec ji stejne OOM killer zabije (nebo umre sama). Tak to uz je lepsi, pokud proste klekne rovnou a nebude se zbytecne opotrebovavat disk. A u aplikaci v modernich jazycich je to jeste vetsi nevyhoda. Takovy program, co zere hodne pameti zacne swapovat, misto aby provedl uklid (spustil garbage collector). Takze na desktopu to IMHO nema smysl.

[JS]

Vlastne jo, nezni to tak spatne.. kombinace komprese a swapu do pameti je zajimava.

[xHire]

Je komprimovaný swap bezpečný? Nemůže tu nastat podobná situace jako u swapování po síti? (Tj. aby se mohla data uložit na swap, tak je potřeba extra paměť pro jejich zpracování, což může být při aktuálním nedostatku paměti problém.)

[Ivan]

SWAP je prezitek. Pokud zacne (pravidelne) swappovat server tak mate spatny sizing a je potreba dokoupit RAM, ktera je uz dneska konecne levna. Pokud zacne swapovat desktop tak vetsinou staci restartovat Firefox.

[David Heidelberg]

přesně :D Firefox je nemožnej kus, za chvíli vyžere na 3 taby klidně 1G...

[Řepa]

A co když provozuji třeba Linux na tabletu? Nebo v routeru? Jinými slovy někde, kde paměť prostě nevyměním?

A pokud funguje zapnutí zram, které je zadarmo, proč bych měl vyhazovat tablet a kupovat nový (což zadarmo jistojistě nebude)?

[Bystroushaak]

Pak zkus bez swapu uspat komp na disk :)

[Limoto]

Přesně!

[Jakub Lucký]

Do souboru?

[Bystroushaak]

No, to třeba u mě na šifrovaném disku nejede (swap se sice připojí, ale neumí to do něj uspat), takže si (až nasbírám dost duševních sil) dám reninstall s posunem šifrovaných oddílů.

[Semo]

Takze budem mat na disku vyhradene miesto, kam sa system uspi a inak sa to miesto pouzivat nebude. Namiesto toho, aby som mal swap, ktory ma vyuzitie ako pri uspani, tak aj za zivota. Fakt vylepsenie.

[Jakub Lucký]

A co chcete? Ke každému laptopu dva číňany, co si hodně ryhle pamatují čísla, kteří budou při uspávání rychle memorovat? Někde se to ukládat musí a když někdo nechce mít swap (který se asi bude vypínat (a mergovat do /) o dost složitěji než tenhle file), tak mi tohle nepřijde jako špatná volba...

[Michal Kubeček]

Předchozí příspěvek upozorňoval právě na to, že to místo je potřeba tak jako tak a když se použije swap, tak se to místo využije i tehdy, když počítač není zrovna uspaný.

[Jakub Lucký]

Hm, pokud tohle chápu správně, tak to ještě nemusí být pravda... Ale nestudoval jsem to komplexně...

[Kvakor]

Pamatuju, že možnost swapovat do komprimované oblasti paměti měl už QEMM 9 pro Windows 3.1, kde to vzhledem k mizernému paměťovému managementu, malým pamětem a a velmi pomalým diskům mělo smysl. A i dnes si dokážu představit případy, kdy jse paměť plná snadno komprimovatelných dat a kde je rychlejší je hodit do komprimované oblasti paměti než zapisovat na disk, protože zatímco dnešní počítače mají běžně několik jader, disk je většinoiu jen jeden.

[Semo]

Tak som sa s tym vcera hral programcekom, ktory alokuje pamat (a zapisuje do nej dobre komprimovatelne data, aby sa neprejavoval overcommit a zapisuje az dokym ho OOM killer nezostreli. Zapis do zram je asi 2-3x pomalsi ako zapis do RAM (Intel Core i3-2100 (3.1GHz), DDR3 1333MHz), co je dost slusne.

Ale nasledny swapoff trva STRASNE dlho. 4GB zram swap

#include <stdio.h>
#include <malloc.h>
#include <sys/time.h>

int main(int argc, char **argv)
{
        char *p;
        int i,j ;
        int step, us;
        struct timeval prevtv, tv;

        step = atoi(argv[1]);
        gettimeofday(&prevtv, NULL);

        for (i=0; i<100000; i+=step) {
                p = malloc(1024*1024*step);
                for (j=0; j<1024*1024*step; j+=4)
                        p[j] = 0x7f;
                gettimeofday(&tv, NULL);
                printf("%d %10ld\n", i, (tv.tv_sec-prevtv.tv_sec)*1000000 + (tv.tv_usec-prevtv.tv_usec));
                prevtv = tv;
        }

        return 0;
}

a zram asi nie je prave z najstabilnejsich (jadro 3.2.5):

zram: module is from the staging directory, the quality is unknown, you have been warned.
zram: num_devices not specified. Using default: 1
zram: Creating 1 devices ...
Adding 4194300k swap on /dev/zram0.  Priority:5 extents:1 across:4194300k SS
udisks-daemon invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Pid: 4871, comm: udisks-daemon Tainted: G         C   3.2.5-pf #1
Call Trace:
 [<ffffffff810bd927>] ? dump_header.clone.8+0x87/0x210
 [<ffffffff8106370d>] ? ktime_get_ts+0x6d/0xe0
 [<ffffffff810ae3be>] ? delayacct_end+0x7e/0xa0
 [<ffffffff810bdc8a>] ? oom_kill_process.clone.11+0x8a/0x2b0
 [<ffffffff8104937a>] ? has_capability_noaudit+0x3a/0x50
 [<ffffffff810be25e>] ? out_of_memory+0x23e/0x330
 [<ffffffff810cb216>] ? try_to_free_pages+0x76/0x80
 [<ffffffff810c1e7b>] ? __alloc_pages_nodemask+0x79b/0x7b0
 [<ffffffff810bcd3b>] ? filemap_fault+0x2cb/0x470
 [<ffffffff810d4dbb>] ? __do_fault+0x7b/0x4e0
 [<ffffffff812e6519>] ? ioctl_internal_command.clone.4+0x49/0x130
 [<ffffffff810d763a>] ? handle_pte_fault+0x8a/0x7d0
 [<ffffffff81027c4f>] ? do_page_fault+0x12f/0x420
 [<ffffffff81113a20>] ? iput+0x40/0x230
 [<ffffffff8112c7a3>] ? __blkdev_put+0xa3/0x1e0
 [<ffffffff8106370d>] ? ktime_get_ts+0x6d/0xe0
 [<ffffffff8110ccc6>] ? poll_select_set_timeout+0x86/0xa0
 [<ffffffff813f73af>] ? page_fault+0x1f/0x30

[Michal Kubeček]

a zram asi nie je prave z najstabilnejsich (jadro 3.2.5):

Zatím asi ne, ale ten výpis, který uvádíte, nic takového neukazuje, ten jen říká, že byl vyvolán oom-killer, nic víc.

[Semo]

Tak este doplnenie. Mam 12GB RAM a ked zram je nastavene iba na malu cast z toho (2GB), tak je spomalenie 2-3x. Ked podstatnu cast (8GB), tak 4-10x. Obcasne ustrely az ku 15x pomalsie spracovanemu bloku (testujem pri blok=200MB) sa stavaju pri kazdej velkosti.