111 replies to this topic

[Stephan296]

Ik heb ook een swap file aangemaakt op een usb stick van 2gb.
Geformatteerd naar fat32, in de ontvanger gedaan, toen ge-unmount want hij mount hem inderdaad direct.
Toen de swap-commando's toegepast zoals een stuk hierboven beschreven.
Toen via systools gekeken wat het geheugen verbruik was, en wat bleek bij het afspelen van een 1080p film pakte hij meer dan 30 mb van de usb stick.
Terwijl er op RAM nog maar 7mb vrij was, dan is het ook niet zo gek dat hij zijn geheugen vol laat lopen als hij niet meer heeft haha.
Tot nu toe werkt het goed, inderdaad bij het wisselen tussen films lijkt het net alsof hij even stil staat maar het werkt wel gewoon.
Verder draait het super tot nu toe.
Mijn et9000 ontvanger komt donderdag als het goed is weer hier dus dan heb ik daar geen last meer van.

[BuGless]

Maar de kernel (nfs...) heeft soms wat aaneengesloten fysiek geheugen nodig, en dat is op dat moment gewoon "op".

Normaliter zou dat toch niet veel meer moeten zijn dan 2 pages (8KB) oid, 2MB aaneengesloten voor NFS (her)ken ik niet.

Als je een swap device hebt, dan kan de kernel pages van user space processes uitswappen om zo voldoende aaneengesloten stukken geheugen te verkrijgen. Op het moment dat dat nodig is, zal enigma even heel traag zijn en misschien wel even stil staan, maar hij kan tenminste wel blijven draaien, terwijl enigma anders gewoon wordt afgeschoten om meer geheugen te verkrijgen. In dat opzicht ben ik het dus niet met Pieter eens dat swap alleen maar uitstel is. Het bewijs is dat het bij mij nu achter elkaar gewoon draait.

Als het de fragmentatie is, ja, dan heb je gelijk, en is het een echte oplossing.
Alhoewel ik dan ook gelijk me afvraag waarom Linux niet zelf al in geval van geen-swap een defragmentatie intern uitvoert, want dat zou feitelijk net zo goed moeten kunnen, en sneller moeten zijn dan daadwerkelijk naar swap swappen en terug. Beetje inefficient dat perse een swap device nodig is alleen om defragmentatie te faciliteren.

[Erik Slagter]

Yep, klagen bij Linus Ik denk dat de achterliggende gedachte is dat bijna iedereen wel iets van swap heeft. Hoewel... er zijn genoeg embedded apparaten waar linux op draait, meestal zonder swap. Ik denk dat enigma in die zin wel "bijzonder" is, omdat die heel veel geheugen in één proces gebruikt (wel meerdere threads, maar dat is niet van belang). Zeker als je een week vooruit EPG gaat inlezen. Daar moeten we ook echt eens wat aan doen, dat moet gewoon op schijf blijven staan.

[pieterg]

het is geen geval van fragmentatie lijkt mij, als er nog een aaneengesloten blok van 1MB en eentje van 512kB beschikbaar (op totaal 2MB vrij)

[Erik Slagter]

De hamvraag is dan, waarom gaat de OOM dan aan de gang?

[pieterg]

De hamvraag is dan, waarom gaat de OOM dan aan de gang?

omdat er ergens een blok van 2MB of groter gealloceerd wordt.
Ofwel in een context die geen disk io toestaat (anders was er wel cache geflushed), of omdat er simpelweg geen cache te flushen is (omdat het geheugen echt tot de rand volgestouwd zit met epg)

[Erik Slagter]

Die EPG zal zeker meespelen, bij mij zit-ie er ook goed vol mee. En daarvoor helpt swap dan precies. De ervaring leert dat minder gebruikte pagina's preventief uitgeswapt worden, dus zou deze situatie minder vaak / niet meer moeten voorkomen. En vooralsnog komt dat ook zo uit. De ultieme oplossing is dan toch epg op schijf, maar swap komt in de buurt.

[pieterg]

Die EPG zal zeker meespelen, bij mij zit-ie er ook goed vol mee.

jouw log was anders, dat was wel degelijk fragmentatie (er was niks groters dan 4kB beschikbaar)

[Erik Slagter]

Misschien dat NFS meer dan 1 MB aaneengesloten nodig heeft, of meer dan 1 keer 1 MB?

[pieterg]

Misschien dat NFS meer dan 1 MB aaneengesloten nodig heeft, of meer dan 1 keer 1 MB?

vandaar dat we TS hebben aangeraden om eens zonder nfs te proberen, en toen trad het nog steeds op, ook weer met een 1MB en 512kB blok beschikbaar.

[BuGless]

Misschien een domme vraag (want ik weet niet precies hoe de EPG intern gebruikt wordt), maar waarom wordt de EPG data niet gewoon ge-mmap()ed? Kost bijna geen programmeereffort, en gelijk voordeel van ruimte die vrijkomt in het geheugen (en geen swap nodig).

Overigens, wat betreft swap, dat kan (dacht ik) ook via NFS (aparte swappartitie; of kon dat alleen onder SunOS/Solaris?).

Oja, en nogmaals, NFS alloceert AFAICR nooit veel meer dan 8KB (of max. 64KB) aaneengesloten.

[Erik Slagter]

In principe is swap over NFS mogelijk, maar daar krijg je in dit geval een kip-ei-situatie mee. Ik heb het ooit wel gedaan, op totaal-diskless clients, maar de performance is vreselijk, ik kan het niet aanraden.

Het probleem met epg is dat het niet zomaar een file is die je kunt mmappen, dan was het wel heel makkelijk geweest. EPG data komt uit allerlei bronnen en wordt op dit moment als eit data (als ik het goed heb) in geheugen opgeslagen. Alles wat geen eit data is, wordt daarnaar geconverteerd. Je zou zoiets in een database-file moeten stoppen, zoals sqlite o.i.d, dat zou ideaal zijn. Alleen is dat een hele operatie en er zijn totnogtoe nog geen vrijwilligers geweest om deze flinke klus op zich te nemen. Hoor ik hier een vrijwilliger?

[pieterg]

in e1 hebben we sqlite gebruikt om epg op te slaan. Maar dit gaf veel performance verlies (blocking file io), conclusie je kan niet de epgcache implementatie veranderen zonder de epg users ook om te schrijven.

[Erik Slagter]

Misschien dat de performance op e2 beter zal zijn door meer geheugen vrij voor caching?

[dAF2000]

Beetje on-topic blijven, graag

[BuGless]

Het probleem met epg is dat het niet zomaar een file is die je kunt mmappen, dan was het wel heel makkelijk geweest. EPG data komt uit allerlei bronnen en wordt op dit moment als eit data (als ik het goed heb) in geheugen opgeslagen. Alles wat geen eit data is, wordt daarnaar geconverteerd.

In principe is het mogelijk om zo'n eit structuur op een dusdanige manier op te slaan (in het geheugen) dat het nagenoeg gemmapped kan worden. Ik heb dat in het verleden wel met squid cache index structuren gedaan.

Je zou zoiets in een database-file moeten stoppen, zoals sqlite o.i.d, dat zou ideaal zijn. Alleen is dat een hele operatie en er zijn totnogtoe nog geen vrijwilligers geweest om deze flinke klus op zich te nemen. Hoor ik hier een vrijwilliger?

Ik wil er wel eens naar kijken, no promises though. Het probleem is dat ik de sources wel al uitgepakt heb liggen, maar nog niet zo ver ben gekomen dat ik daadwerkelijk een van m'n 3 grootste ergernissen heb kunnen vinden in de source, en daarmee dus ook de rest van de toolchain nog niet geinstalleerd heb. Als de omgeving eenmaal werkt, zijn iets grotere aanpassingen ook geen probleem meer.

in e1 hebben we sqlite gebruikt om epg op te slaan. Maar dit gaf veel performance verlies (blocking file io), conclusie je kan niet de epgcache implementatie veranderen zonder de epg users ook om te schrijven.

Als je iets in een DB gooit, is het noodzakelijk om de structuur van de DB (en de indexen) aan te passen op het gebruik; dat zou voor EPG ook moeten kunnen.

Wat betreft "on topic"; het gaat hier uiteindelijk om het terugdringen van het geheugengebruik, en EPG is een redelijk wezenlijke factor daarin (lijkt me).

[Erik Slagter]

Dat laatste ben ik het zeker mee eens, EPG is een enorme verbruiker en dat komt de stabiliteit niet ten goede. Ooit was ik ook nog heel enthousiast om vanalles aan enigma(2) te gaan hersleutelen, maar e.e.a. blijkt toch behoorlijk complex. Je hebt bijvoorbeeld te maken met plugins van derden die allerlei "internals" enigma verwachten die je niet zomaar om kunt gooien. Niet om je te ontmoedigen natuurlijk

[BuGless]

Ooit was ik ook nog heel enthousiast om vanalles aan enigma(2) te gaan hersleutelen, maar e.e.a. blijkt toch behoorlijk complex. Je hebt bijvoorbeeld te maken met plugins van derden die allerlei "internals" enigma verwachten die je niet zomaar om kunt gooien. Niet om je te ontmoedigen natuurlijk

Ik pas wel eens dingen aan in gcc of de Linux kernel, dus zo snel krijg je me niet ontmoedigd (tenzij het net zo erg is als de Asterisk broncode; dat is de eerste source waar ik na heel even gekeken te hebben, de bestanden snel weer dichtgegooid heb, om nooit meer te openen :-/).

Wat betreft overcommit, je zegt dat dat al uit staat op een openpli box. Toch lijkt het alsof ik zie dat op een box meer virtueel geheugen gealloceerd wordt dan dat er fysiek aanwezig is (op een DM500HD zonder swap). Dat zou dan toch eigenlijk niet mogen kunnen?

[BuGless]

Wat betreft overcommit, je zegt dat dat al uit staat op een openpli box. Toch lijkt het alsof ik zie dat op een box meer virtueel geheugen gealloceerd wordt dan dat er fysiek aanwezig is (op een DM500HD zonder swap). Dat zou dan toch eigenlijk niet mogen kunnen?

Hmmm, ik denk dat OpenPLi hier een duidelijk verbeterpunt heeft. Bij nalezen van de kernel docs blijkt dat de voor embedded/dedicated devices (zoals een OpenPLi systeem) de meest optimale instelling is:

echo 99 >/proc/sys/vm/overcommit_ratio
echo 2 >/proc/sys/vm/overcommit_memory

Dit is nl. de enige instelling die ervoor zorgt dat Linux niet speculatief meer geheugen toelaat om te alloceren. Aangezien het hier een gecontroleerde omgeving betreft (hoofdzakelijk enigma2), lijkt het me voor de hand liggen dat de kernel niet hoeft te liegen tegen enigma over de hoeveelheid beschikbare geheugen. Bijkomend gevolg is dat je verlost bent van het soort problemen dat "na een bepaalde tijd" zorgen dat de boel hangt, opnieuw start oid.

Een ander gevolg van deze instelling is dat, als je te weinig geheugen hebt om over langere tijd te blijven functioneren, je daar in een vroegtijdig stadium bericht van krijgt (omdat malloc() NULL teruggeeft, of omdat een programma bij het opstarten reeds zich beeindigd met de mededeling dat er te weinig geheugen is). Het is op dat moment dan duidelijk dat er swap bij moet, en hoeft dan dus ook niet meer geraden te worden naar een mogelijke oplossing van geheugentekorten die al naar gelang gebruik sporadisch en ogenschijnlijk random voorkomen.

Ik ga dit op m'n eigen systemen aanpassen in ieder geval.

[Stephan296]

Wat betreft overcommit, je zegt dat dat al uit staat op een openpli box. Toch lijkt het alsof ik zie dat op een box meer virtueel geheugen gealloceerd wordt dan dat er fysiek aanwezig is (op een DM500HD zonder swap). Dat zou dan toch eigenlijk niet mogen kunnen?

Hmmm, ik denk dat OpenPLi hier een duidelijk verbeterpunt heeft. Bij nalezen van de kernel docs blijkt dat de voor embedded/dedicated devices (zoals een OpenPLi systeem) de meest optimale instelling is:

echo 99 >/proc/sys/vm/overcommit_ratio
echo 2 >/proc/sys/vm/overcommit_memory

Dit is nl. de enige instelling die ervoor zorgt dat Linux niet speculatief meer geheugen toelaat om te alloceren. Aangezien het hier een gecontroleerde omgeving betreft (hoofdzakelijk enigma2), lijkt het me voor de hand liggen dat de kernel niet hoeft te liegen tegen enigma over de hoeveelheid beschikbare geheugen. Bijkomend gevolg is dat je verlost bent van het soort problemen dat "na een bepaalde tijd" zorgen dat de boel hangt, opnieuw start oid.

Een ander gevolg van deze instelling is dat, als je te weinig geheugen hebt om over langere tijd te blijven functioneren, je daar in een vroegtijdig stadium bericht van krijgt (omdat malloc() NULL teruggeeft, of omdat een programma bij het opstarten reeds zich beeindigd met de mededeling dat er te weinig geheugen is). Het is op dat moment dan duidelijk dat er swap bij moet, en hoeft dan dus ook niet meer geraden te worden naar een mogelijke oplossing van geheugentekorten die al naar gelang gebruik sporadisch en ogenschijnlijk random voorkomen.

Ik ga dit op m'n eigen systemen aanpassen in ieder geval.

Je bent goed bezig
Heb je ook een oplossing voor de EPG?