111 replies to this topic

[BuGless]

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

The difficult we do today, the impossible tomorrow :-P.
Nee, helaas, de toolchain gereedmaken zodat ik daadwerkelijk een enigma2 binary kan compileren vergt iets meer werk, en dan moet ik nog zien wat ik aantref; Erik voorspelde niet veel goeds.

[Erik Slagter]

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 :-/).

Ik weet nog wel een paar van dat soort projecten

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?

Er is altijd meer virtueel geheugen dan fysiek. Denk maar aan shared memory, shared libraries... Van executables en shared libraries worden alleen pages ingeladen die aangesproken worden. Enz...

[Erik Slagter]

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.

Ik denk dat je zeker een punt hebt, ik heb er even de documentatie op nageslagen Nou is mijn ervaring dat er altijd verrassingen zijn, maar ik denk dat het zeker de moeite waard is om te proberen. Ik ga het denk ik hier ook maar eens invoeren. Hoe zijn je ervaringen tot nu toe?

Edited by Erik Slagter, 13 September 2012 - 16:41.

[pieterg]

Als je hiervoor al nooit OOM problemen had, zal je geen verschil merken.

[BuGless]

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

Ik ga het denk ik hier ook maar eens invoeren. Hoe zijn je ervaringen tot nu toe?

Op een OpenPLi 3.0 ET9500 gaat het uitstekend, tot dusverre, niks wat opeens niet meer loopt.
Maar het is in principe zoals pieterg al aangeeft, als je geen af en toe vasthangend iets had, is de kans dat je wat merkt, klein. Tenzij je een potentieel tekort had wat zich zelden verzilverde, dan zul je daarna merken dat de boel in een vroegtijdig stadium aangeeft dat er te weinig geheugen is.

Edited by BuGless, 13 September 2012 - 19:38.

[Stephan296]

Hoe kun je dat invoeren want ik zit nog steeds met een Et5000 haha

[Erik Slagter]

Op een OpenPLi 3.0 ET9500 gaat het uitstekend, tot dusverre, niks wat opeens niet meer loopt.
Maar het is in principe zoals pieterg al aangeeft, als je geen af en toe vasthangend iets had, is de kans dat je wat merkt, klein. Tenzij je een potentieel tekort had wat zich zelden verzilverde, dan zul je daarna merken dat de boel in een vroegtijdig stadium aangeeft dat er te weinig geheugen is.

Aangezien ik nogal eens vastlopers had op de dm8000 is dat wel een goede kandidaat Hij is nu in gebruik, maar ik zal later even de swap weer uitzetten en de overcommit force uitzetten. Eens kijken hoe het dan gaat. Meten = weten hè

[pieterg]

Eens kijken hoe het dan gaat.

als het helpt, klapt e2 er gewoon wat eerder uit dan anders

[Erik Slagter]

Kan ik me ook wat bij voorstellen. Aangezien e2 gewoon in de hoeveelheid moet kunnen draaien, wat is dan het probleem... Toch die epg in ram?

[BuGless]

Hoe kun je dat invoeren want ik zit nog steeds met een Et5000 haha

Je kunt, in beginsel, die 2 echo commando's gewoon in de commandline als root intypen.
Nadelen van die optie zijn (our two main weapons are):
- Is alleen geldig tot aan de volgende reboot.
- Er crasht misschien gelijk iets (enigma2 bijv.) omdat er eigenlijk niet genoeg geheugen is.
- Enigma2 (en andere programma's) krijgen niet de gelegenheid om tijdens het opstarten te merken dat er te weinig geheugen is, en kunnen daardoor geen intelligente beslissingen treffen (of nette foutmeldingen geven).

Ikzelf heb een /usr/local/sbin/rc.preboot.sh script waar ik het in doe.
Maar die heb ik zelf weer ingehangen via:
ln -s ../../usr/local/sbin/rc.preboot.sh /etc/rcS.d/S01preboot.sh
in het bootproces, zodat het geinitialiseerd wordt *voordat* alle andere programma's opstarten.

[Erik Slagter]

Nog even een update, sinds ik een swap-stick gebruik is enigma niet meer geOOMkilled.

[Erik Slagter]

... maar hij staat wel regelmatig stil en dan is-ie heel hard aan het swappen.

Ik ben maar eens flink in de EPG gaan snoeien en dat lijkt al een stuk te schelen.