Gecomprimeerde swap op de memory plaatsen

[OrangeTux]

http://www.webupd8.org/20...rmance-in-linux-with.html

Dit artikeltje beschrijft een programma dat een gecomprimeerde swap op de memory zet.
De memory wordt hierdoor kleiner, waardoor de swap vaker gebruikt moet worden. Maar omdat de swap in de memory staat kan die swap heel snel worden benaderd.

Ik heb al positieve reacties gelezen op verschillende fora. Is zoiets niet een uitkomst voor systemen met weinig memory, en waar het swap geheugen vaak benadert moet worden?

[Verwijderd]

..

[ Voor 99% gewijzigd door Verwijderd op 21-02-2013 11:35 ]

[Gomez12]

Ik denk dat het in de praktijk een moeilijk compromis gaat worden.

Wil je meer cpu-belasting en een wisselende geheugen grens dan kan dit helpen.
Wil je enkel snelheid hebben, dan is het maar net de vraag hoeveel cpu de compressie kost en hoeveel de daadwerkelijke compressie is.

Ik vermoed dat het in de praktijk heel erg wisselende resultaten kan geven, net afhankelijk van hoeveel compressie etc er behaald kan worden.
Ik zie het niet echt voor me dat je nu een app die 4Gb vraagt goed kan draaien op een 2Gb systeempje

[dion_b]

Processors, Moederborden & Geheugen gaat over de fysieke onderdelen zelf, niet over hoe besturingssystemen ermee overweg gaan. Aangezien het hier impliciet (expliciet was beter geweest...) over Linux lijkt te gaan verplaats ik dit topic naar Non-Windows Operated Systems

Move PMG -> NOS


Inhoudelijk:
Swap is er juist om zaken die niet in RAM passen op te vangen. RAM opofferen voor swap op RAMdisk is daarom vrij onzinnig. IMHO kun je beter zorgen dat je in eerste instantie minder geheugen gebruikt.

Ik heb wat dat betreft op zeer RAM-limited systemen (denk 32-128MB) goede ervaringen met Gentoo, deels omdat je niets instaleert wat je zelf niet expliciet wilt, deels omdat je zelf compileert en (als je het goed doet) geen support inbakt voor zaken die je niet nodig hebt. Denk daarbij met name aan support voor verschillende display libraries. De meeste pre-compiled pakketten hebben support voor zowel GTK+ als Qt ingebakken. Het scheelt vaak een paar procent in executablegrootte door een (of beide) weg te laten. Wat ook een paar procent scheelt is om gcc te laten optimaliseren voor grootte, niet snelheid (-Os ipv -O2 in de CFLAGS)

Nettoresultaat op een subnotebook met 64MB RAM was dat Gentoo in ongeveer de helft van de tijd bootte van een kale Debian met zelfde packages, en dat het ook na boot sneller aanvoelde.

Als het niet zo idioot low-end is zou ik overwegen flash (desnoods een USB-stick, idealiter een SSD) in te zetten als swap - voor swap is de linear transfer speed (waar HDDs goed in zijn en USB waardeloos) irrelevant, random reads & writes des te meer.

[Boudewijn]

Je gaat je swap comprimeren; dan houd je wel meer ruimte over maar je processor wordt de bottleneck.
Minder 'snel geheugen' en meer 'extra traag' geheugen.

Lijkt me geen goed plan .

[Gomez12]

dion_b schreef op zondag 09 oktober 2011 @ 16:02:
Swap is er juist om zaken die niet in RAM passen op te vangen. RAM opofferen voor swap op RAMdisk is daarom vrij onzinnig. IMHO kun je beter zorgen dat je in eerste instantie minder geheugen gebruikt.

Daarom ook het comprimeren van de swap...
Zodat je niet je RAM 1:1 inwisselt voor swap.

Theoretisch gezien denk ik dat het best een aardig concept is (ik gok zomaar dat in-memory er best veel te comprimeren valt)
Een MP3 bijv zal in-memory decoded staan en best goed weer te comprimeren zijn, maar dan heb loop je weer tegen de performance penalty van compressen / de-compressen aan omdat de meeste mp3-spelers geen giga-buffer in het geheugen hebben staan, maar alles on-the-fly omzetten, waardoor je een chain krijgt als :
mp3-decoder plaatst het decoded in het geheugen/swap -> het moet gecomprimeerd worden -> speler probeert het uit het geheugen te lezen, hence het moet weer gedecomprimeerd worden.

Praktisch gezien zou ik dus ook simpelweg zoveel mogelijk geheugen vrij houden zodat er minder geswapt hoeft te worden. Met dit soort tooltjes ga je enkel maar meer swappen en bovendien komt er nog eens een performance-hit bovenop omdat het gecomprimeerd/gedecomprimeerd moet worden.

Het is leuk in situaties waar je geheugen overhebt (maar dan heb je met een beetje OS al geen swap meer)

[MacGrumpy]

Dit werkt verrassend goed. Ik zit op werk in de situatie dat ik regelmatig net (10-20%) buiten werk geheugen loop. Het swappen naar disk maakt het erg traag.
Met zram blijft mijn PC lekker snel.
(het is eenvoudig een probleem loos uit te proberen, dus ipv roepen dat het niet werkt of nutteloos is, kan even proberen vaak helpen. Meten is weten (of zo iets))

CPU is zo veel sneller dan je vasteschijf dat de 'compress/decompress' penalty te verwaarlozen is bij de tijd die de roundtrip naar de harddisk nodig heeft.


Ook word dit op veel (compcache ) op android 'custom roms' gebruikt.
e.g. http://wiki.cyanogenmod.com/wiki/Swap_and_Compcache

[ Voor 14% gewijzigd door MacGrumpy op 09-10-2011 17:52 . Reden: zeuren. ]

[dion_b]

toch blijf ik erbij dat voorkomen beter dan genezen is, en dat je dus beter naar compile opties kunt kijken (en sowieso onnodige services e.d. uitschakelen)

[Boudewijn]

Of gewoon meer geheugen? Dat is tegenwoordig ook echt belachelijk goedkoop.

[Gomez12]

Boudewijn schreef op dinsdag 11 oktober 2011 @ 15:31:
Of gewoon meer geheugen? Dat is tegenwoordig ook echt belachelijk goedkoop.

Het is enkel mainstream belachelijk goedkoop, wil je het embedded oid hebben dan wordt het al snel belachelijk duur

Gaat je kostprijs van telefoon bijv 80 euro omhoog en wordt hij daarmee duurder dan wat alle concurrenten in de markt zetten dan worden dit soort concepten wel heel erg aantrekkelijk.

Maar voor consumenten pc's en dergelijke kan je idd beter of meer geheugen kopen of wat dingen afsluiten dat levert simpelweg betere performance op...

[Boudewijn]

Inderdaad, voor gewone computers en servers is het extreem goedkoop. Lijkt me beter dan dit soort dingen; ook omdat die volgens mij echt een forse performance hit geven als je hard staat te swappen.

[Gomez12]

Boudewijn schreef op dinsdag 11 oktober 2011 @ 23:52:
Inderdaad, voor gewone computers en servers is het extreem goedkoop. Lijkt me beter dan dit soort dingen; ook omdat die volgens mij echt een forse performance hit geven als je hard staat te swappen.

Ach, laat ik het zo zeggen, vroegah had je stacker en doublespace voor je hdd. Allemaal hartstikke handig voor die tijd en hdd-ruimte. Maar dat gebruiken we ook niet meer.

Ik zie het heel simpel, het is geen performance hit als je pc goed genoeg is (en je memory intensive job ook niet hdd-intensive is) maar dan heb je vanzelf weer genoeg cheap-geheugen.
Het is wel weer een performance hit als je het op oudere pc's gaat draaien waar weinig geheugen in zit.

De enige echte use-cases die ik zie zijn :
- Hedendaagse pc met extreem weinig geheugen (=memory upgrade efficiënter)
- Oudere pc's die heel veel memory-verslindende progs open hebben staan die geen cpu vragen (=programma's afsluiten)

[Boudewijn]

Dat bedoel ik: dit soort gein heb je niet bij een netjes gebalanceerde machine die normale (!) everyday taken draait.

Daarom vind ik het een redelijk exotische oplossing voor een relatief simpel probleem. Dat het een leuke hack kan zijn voor een cheapass bak is uiteraard wel een punt... maa reen 4GB dimm kost een whopping 17 euro's volgens de PW (ddr3, bij REG ECC DDR1 of obscuur FBDIMM geheuen heb je wel een goed punt ja ).

[Wolfboy]

dion_b schreef op dinsdag 11 oktober 2011 @ 15:17:
toch blijf ik erbij dat voorkomen beter dan genezen is, en dat je dus beter naar compile opties kunt kijken (en sowieso onnodige services e.d. uitschakelen)

Het ene sluit het andere niet uit natuurlijk, met de huidige multicore processoren heb je bijna altijd wel cpu capaciteit over dus ram compressie is helemaal nog geen gek idee.

Boudewijn schreef op dinsdag 11 oktober 2011 @ 15:31:
Of gewoon meer geheugen? Dat is tegenwoordig ook echt belachelijk goedkoop.

Dat wil natuurlijk niet zeggen dat je dan nooit zonder geheugen komt te zitten, de grens zit alleen iets hoger

[Gomez12]

Wolfboy schreef op woensdag 12 oktober 2011 @ 01:33:
[...]
Het ene sluit het andere niet uit natuurlijk, met de huidige multicore processoren heb je bijna altijd wel cpu capaciteit over dus ram compressie is helemaal nog geen gek idee.

Het zal aan mij liggen, maar als ik memory-intensieve handelingen heb dan zijn het over het algemeen ook cpu-intensieve handelingen.

Met een briefje in word krijg ik mijn geheugen niet vol, met bijv een spelletje of een giga-compile actie wel. Maar die hebben dan ook weer de cpu nodig.

Kijk, als ik 50 apps ga opstarten of 100+ inet tabbladen ga openen dan krijg ik mijn geheugen wel vol zonder dat er cpu-activiteit bijzit. Maar dan geldt weer het devies : Sluit wat dingen.

[Wolfboy]

Gomez12 schreef op woensdag 12 oktober 2011 @ 01:53:
[...]

Het zal aan mij liggen, maar als ik memory-intensieve handelingen heb dan zijn het over het algemeen ook cpu-intensieve handelingen.

Met een briefje in word krijg ik mijn geheugen niet vol, met bijv een spelletje of een giga-compile actie wel. Maar die hebben dan ook weer de cpu nodig.

Kijk, als ik 50 apps ga opstarten of 100+ inet tabbladen ga openen dan krijg ik mijn geheugen wel vol zonder dat er cpu-activiteit bijzit. Maar dan geldt weer het devies : Sluit wat dingen.

Het hangt nogal van je gebruikspatroon af ja, maar toch heb ik met mijn machine (quad core) zelfs met compilen vaak meer geheugen dan cpu verbruik aangezien je niet alles parallel kan doen.

Aangezien huidige cpu's steeds meer cores krijgen en de meeste software zelden gebruik maakt van alle cores lijkt het mij een afweging die erg afhankelijk is van je gebruik. Als ik weer eens in Eclipse aan het werken ben dan zit 1 van m'n cores vaak wel vol, maar de rest toch echt niet. En de geheugenload van Eclipse is flink

Moderne compressie algoritmen kunnen best snel zijn iig

Op mijn C2D T7500 (2.2GHz) laptopje

# dd if=/dev/zero of=null bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.252941 s, 415 MB/s
# time cat null | lzop -1 -c >| /dev/null
cat null  0.00s user 0.08s system 25% cpu 0.335 total
lzop -1 -c >| /dev/null  0.22s user 0.04s system 77% cpu 0.336 total

Maar met puur random data is het best traag:

# dd if=/dev/urandom of=random bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 19.8923 s, 5.3 MB/s
# time cat random | lzop -1 -c >| /dev/null
cat random  0.00s user 0.09s system 3% cpu 2.571 total
lzop -1 -c >| /dev/null  2.47s user 0.04s system 97% cpu 2.576 total

[ Voor 25% gewijzigd door Wolfboy op 12-10-2011 02:37 ]

[M2M]

Als ik het goed zie, prop je 100MB nulletjes in je comprimeer machine. Daar doet die 0.25s over. Het verbaasd me eigenlijk dat de machine er nog zo lang over doet... Dit lijkt meer op de snelheid van de harde schijf / SSD te hangen dan de processor... Maargoed, 100MB nulletjes comprimeren is geen benchmark voor compressie. Zelfs een mens kan 100MB nulletjes comprimeren.

edit: verder is het principe wel grappig eigenlijk. Als je tegen geheugenlimieten aan loopt en je hebt nog klokcycles over, kun je die dus investeren om geheugen vrij te maken. Dat het nu via een inefficiente omweg (swap) gebeurt is eigenlijk een softwarelimitatie. Maar ik kan me indenken dat dit voor bijvoorbeeld multicore smartphones nog wel interessant kan worden. Waarom ook niet het maximale uit je hardware halen? Als je op je cpu tijd over hebt, investeer het dan in het vrijmaken van geheugen als je daar een tekort aan hebt.

[ Voor 42% gewijzigd door M2M op 12-10-2011 04:14 ]

[Wolfboy]

M2M schreef op woensdag 12 oktober 2011 @ 04:11:
Als ik het goed zie, prop je 100MB nulletjes in je comprimeer machine. Daar doet die 0.25s over. Het verbaasd me eigenlijk dat de machine er nog zo lang over doet... Dit lijkt meer op de snelheid van de harde schijf / SSD te hangen dan de processor... Maargoed, 100MB nulletjes comprimeren is geen benchmark voor compressie. Zelfs een mens kan 100MB nulletjes comprimeren.

Alles zat in de cache, maar het is geen snel laptopje meer

Daarom vergelijk ik het ook met de random zodat je kan zien wat je range ongeveer is.