Speicherverwaltung optimierbar?

[PauleFoul]

Hallo zusammen,

da ich nun meine Sagem mit 64MB als Wohnzimmer / Aufnahme-Box verwende ist mir aufgefallen,
das nach einer Aufnahme 97% Speicher belegt sind.
Im normalen Betrieb sind es maximal 52%, wenn der EPG aller Sender eingelesen ist.

OK, jetzt werden alles sagen, dass der Speicher nicht wirklich belegt ist. Aber was Fakt ist, das
man eine merkliche Verlangsamung der Bedienung feststellen kann.
Wenn man dann kurz mit dem Movieplayer einen Film abspielt, sind danach nur noch ca. 70%
Speicher belegt und die Bedienung der box wieder schneller.

Gibt es denn nicht eine Möglichkeit nach einer Aufnahme den Speicher wieder "richtig" freizugeben?
Ich meine das es auch beim Sectionsd so ein Problem mit der Speicherfreigabe gibt...

Gruß
____Paule

[seife]

OK, jetzt werden alles sagen, dass der Speicher nicht wirklich belegt ist. Aber was Fakt ist, das
man eine merkliche Verlangsamung der Bedienung feststellen kann.
Wenn man dann kurz mit dem Movieplayer einen Film abspielt, sind danach nur noch ca. 70%
Speicher belegt und die Bedienung der box wieder schneller.

Nun ja. Man könnte natürlich versuchen, das Speichermanagement des Kernels zu optimieren... ist allerdings nicht trivial, da haben sich schon ganz andere Koryphäen dran versucht...

Gibt es denn nicht eine Möglichkeit nach einer Aufnahme den Speicher wieder "richtig" freizugeben?

Das einfachste ist es, den Speicher einfach zu belegen, dann werden die Caches etc. verworfen (was anderes macht der Movieplayer in der Praxis auch nicht: er fordert Speicher an, der dann freigemacht wird, und gibt ihn nach dem Beenden frei, was dann in deinem Fall die Performance erhöht), der Klassiker in dieser Kategorie ist: ein 10MB-File in /tmp/ erzeugen und dann wieder löschen (aber Achtung: wenn keine 10MB mehr frei sind, dann fliegt dir die Box bei dieser Aktion um die Ohren).

Beim 2.6er Kernel geht einiges mit "echo 3 > /proc/sys/vm/drop_caches"

Ich meine das es auch beim Sectionsd so ein Problem mit der Speicherfreigabe gibt...

Ich habe so ein Gefühl, dass ich seit dem update auf boost-1.35.0 kein Speicherleck im sectionsd mehr habe, er bleibt bei mir brav knapp unter 10MB (5000 events), aber das kann auch nur der Glaube sein, der Berge versetzt...

[PauleFoul]

Nun ja. Man könnte natürlich versuchen, das Speichermanagement des Kernels zu optimieren... ist allerdings nicht trivial, da haben sich schon ganz andere Koryphäen dran versucht...

Ja, ich glaube auch dass das den Rahmen sprengen würde. Soll ja auch nicht in Arbeit ausarten...

Das einfachste ist es, den Speicher einfach zu belegen, dann werden die Caches etc. verworfen (was anderes macht der Movieplayer in der Praxis auch nicht: er fordert Speicher an, der dann freigemacht wird, und gibt ihn nach dem Beenden frei, was dann in deinem Fall die Performance erhöht), der Klassiker in dieser Kategorie ist: ein 10MB-File in /tmp/ erzeugen und dann wieder löschen (aber Achtung: wenn keine 10MB mehr frei sind, dann fliegt dir die Box bei dieser Aktion um die Ohren).

Ist im Prinzip auch mein Ansatz gewesen und ist auch recht einfach umzusetzen. Stellt sich nur die Frage wie main das "um die Ohren fliegen" vermeiden kann und warum der Movieplayer den Speicher wieder frei gibt die aber Aufnahmefunktion nicht?

Ich habe so ein Gefühl, dass ich seit dem update auf boost-1.35.0 kein Speicherleck im sectionsd mehr habe, er bleibt bei mir brav knapp unter 10MB (5000 events), aber das kann auch nur der Glaube sein, der Berge versetzt...

Schön zu hören, ich hoffe das sich Dein glaube gestätigt. Aber du gehörst ja bald zu den "Sectionsd-Verstehern"...


Gruß
____Paule

[seife]

Die Aufnahmefunktion belegt den Speicher mit dem Schreibcache der aufgenommenen Datei. Der wird - ohne Grund - auch nach Ende der Aufnahme nicht wieder freigegeben - schließlich könnte es ja sein, dass du genau das Ende der geschriebenen Datei danach wieder lesen willst, und dann wäre das schon im Speicher.
Das könnte man evtl. durch verwenden von O_DIRECT oder ähnlichem verhindern - das müsste halt mal ein Festplattenbenutzer probieren, ob das was bringt.

Der Movieplayer alloziert Speicher für das Programm (um den bereitzustellen werden z.B. Caches verworfen), und gibt den nach Beendigung wieder frei - darum ist hinterher mehr Speicher frei.

Verhindern dass einem die Box beim Erstellen des 10MB-Files um die Ohren fliegt tut man am einfachsten durch Einsatz einer swap-Partition.

[PauleFoul]

Die Aufnahmefunktion belegt den Speicher mit dem Schreibcache der aufgenommenen Datei. Der wird - ohne Grund - auch nach Ende der Aufnahme nicht wieder freigegeben - schließlich könnte es ja sein, dass du genau das Ende der geschriebenen Datei danach wieder lesen willst, und dann wäre das schon im Speicher.

Sorry aber irgendwie verstehe ich das nicht!? Warum bzw wie sollte ich nach beenden der Aufnahme das im Cache befindliche Ende der Aufnahme auslesen??


Gruß
____Paule

[seife]

Sollst du gar nicht. Aber der Kernel weiss das nicht, also behält er die Datei erstmal im Cache - so lange, bis er den Speicher für was anderes benötigt.

Mittels O_DIRECT oder fadvise() könnte man dem Kernel sagen, dass dem nicht so ist und er die Datei nicht cachen soll.

O_SYNC könnte das aber evtl. auch schon bewirken.

[PauleFoul]

Sollst du gar nicht. Aber der Kernel weiss das nicht, also behält er die Datei erstmal im Cache - so lange, bis er den Speicher für was anderes benötigt.

Mittels O_DIRECT oder fadvise() könnte man dem Kernel sagen, dass dem nicht so ist und er die Datei nicht cachen soll.

O_SYNC könnte das aber evtl. auch schon bewirken.

Wäre ja mal einen Versuch wert... Nur wie??

[seife]

Ersetze in apps/tuxbox/neutrino/src/driver/stream2file.cpp alle O_SYNC durch O_DIRECT und schalte dann "Benutze O_SYNC" ein.

fadvise() gibt es wohl erst in Kernel 2.6.

[PauleFoul]

Ersetze in apps/tuxbox/neutrino/src/driver/stream2file.cpp alle O_SYNC durch O_DIRECT und schalte dann "Benutze O_SYNC" ein.

fadvise() gibt es wohl erst in Kernel 2.6.

Sorry aber da ich leider nicht selber kompiliere wird wohl jemand ein Binary stellen müssen...

[ThulsaDoom]

Also ich würde mich auch gerne als Tester zur Verfügung stellen und ggf. die Speicherverwaltung analysieren. Meine Aufnahmebox ist quasi ein 24/7-Gerät und ich hatte in der Vergangenheit auch schon mal darüber berichtet, wie sich der Speicher bzw. swap so langsam füllt nach Aufnahmen.

Leider bin ich kein "Eigen-Image-Ersteller" und habe grundsätzlich ein Standard-JTG-Image drauf, Binärfiles in /var/xxx kann ich zwar einbauen, aber der Vorschlag weiter oben sieht mir so aus, als wenn das der Imagebauer schon gleich reinbasteln muss. Daher müsste ich warten, bis jemand (vielleicht JTG-Riker) einen Test-Image macht.

Wie gesagt, meine Wohnzimmerbox wird familienbedingt nahezu 24-Std täglich rangenommen wie nix Gutes (zappen/aufnehmen/abspielen) und somit sehe ich relativ schnell, wann sie träge wird.

Gruß
ThulsaDoom

[seife]

Code: Alles auswählen

Index: src/driver/stream2file.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/driver/stream2file.cpp,v
retrieving revision 1.29
diff -u -p -r1.29 stream2file.cpp
--- src/driver/stream2file.cpp	5 Jan 2008 21:04:53 -0000	1.29
+++ src/driver/stream2file.cpp	13 May 2008 15:49:57 -0000
@@ -191,7 +191,10 @@ void * FileThread(void * v_arg)
 				char filename[FILENAMEBUFFERSIZE];
 				int flags = O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE;
 				if (use_o_sync)
-					flags |= O_SYNC;
+				{
+					flags |= O_DIRECT;
+					fprintf(stderr, "[stream2file] O_SYNC requested -> using O_DIRECT!\n");
+				}
 
 				sprintf(filename, "%s.%3.3d.%s", myfilename, ++filecount, ((struct filenames_t *)v_arg)->extension);
 				if (fd2 != -1)

Damit wird, wenn O_SYNC aktiviert ist stattdessen O_DIRECT verwendet. Ungetestet etc.

Binary: neutrino-O_DIRECT

Achtung, 1472560 Bytes gross, also evtl. etwas viel für /var, vielleicht besser nach /tmp und von dort aus starten.

[PauleFoul]

Hallo Seife,

danke für das Binary. Hab gleich mal getestet und ein paar Sachen aufgenommen.
Also der Speicher geht leider immer noch zu und wird nach dem Beenden der Aufnahme
auch nicht wieder freigegeben.
Allerdings läuft irgendwie alles besser. Mir scheint Neutrino einfach "bedienbarer" während
der Aufnahme.


Gruß
____Paule

PS: Eventuell könnte man das ja sogar als Option in Neutrino einbauen?

Code: Alles auswählen

"XFS journals metadata updates, not data updates. After a crash you are
supposed to get a consistent filesystem which looks like the state
sometime shortly before the crash, NOT what the in memory image looked
like the instant before the crash.

Since XFS does not write data out immediately unless you tell it to
with fsync, an O_SYNC or O_DIRECT open (the same is true of other
filesystems), you are looking at an inode which was flushed out, but
whose data was not. Typically you'll find that the inode is not taking
any space since all it has is a size but no extents allocated (try
examining the file with the xfs_bmap(8) command)."

[PauleFoul]

@ Seife

Mit welchem Befehl kann ich denn geschickt eine 10MB große Datei in /var/tmp/ erzeugen
um den Speicher frei zu bekommen?

Hast Du noch eine Iddeezum Thema o_direct?


Gruß
____Paule

[MarcM]

Mit welchem Befehl kann ich denn geschickt eine 10MB große Datei in /var/tmp/ erzeugen um den Speicher frei zu bekommen?

dd if=/dev/urandom of=/tmp/datei bs=1024k count=10

Sicher das du /var/tmp willst ?

Marc

[seife]

ich würde ja if=/dev/zero benutzen - das geht viel schneller
Typischerweise zeigt /var/tmp als symlink nach /tmp, aber darauf würde ich mich nicht verlassen...

[PauleFoul]

Hallo zusammen,

so ich hab das mal endlich getestet und die Lösung funktioniert bei mir sehr gut...


Datei freeram nach /var/bin/ Rechte 755

Code: Alles auswählen

#! /bin/sh
# Speicher frei machen
# by PauleFoul
# Version: 1.0
echo FreeRAM - Speicher frei machen - Version 1.0

dd if=/dev/zero of=/tmp/freeram bs=1024k count=5
rm /tmp/freeram

Datei recording.end nach /var/tuxbox/config/ Redche 744

Code: Alles auswählen

#!/bin/sh
freeram

Datei movieplayer.end nach /var/tuxbox/config/ Redche 744

Code: Alles auswählen

#!/bin/sh
freeram

Macht Neutrino deutlich schneller finde ich.

Und vielen Dank an MarcM und seife für die Hilfe!


Gruß
____Paule

[PauleFoul]

Gibt es hier eigentlich neue Erkenntnisse über die Problematik dass der Speicher nicht richtig freigegeben wird?

Das mit dem Skript "freeram" funktioniert zwar soweit, ist jedoch mehr in der Ecke "Workaround" einzustufen...


Gruß
____Paule

[mrvica]

>> Gibt es denn nicht eine Möglichkeit nach einer Aufnahme den Speicher wieder "richtig" freizugeben?

das Script freeram habe ich getestet, beim Aufrufen rebootet die Box des öfteren, je nachdem wieviel Speicher frei war, bessere Methode ist über Experteneinstellungen, Flash Save/Restore, versuchen das Image zu speichern, 8MB Datei wird in /tmp (RAM) angelegt, dann einfach mit Tuxbox Commander löschen, es müssten 8MB Speicher freigeben werden, die Box kann auch in dem Fall rebooten, ist aber seltener als mit dem Script, weil GUI (Enigma, Neutrino) Speicherfreigabe managt, das Script ist eher brute force Methode

mrvica

[seife]

weil GUI (Enigma, Neutrino) Speicherfreigabe managt,

Nein.

Das einzige was anders ist ist, dass es langsamer ist und der Kernel etwas mehr Zeit hat, sich zu retten vor ihm der Speicher ausgeht. Das war's aber auch schon.

[mrvica]

gut, daß Du mich zurechtgewiesen hast, man lernt ja nie aus, könnte man das besprochene als Plugin realisieren, über GUI ist es unbequem, dazu muss noch Tuxbox Commander installiert sein

mrvica

[seife]

Mit Zurechtweisen hat das nichts zu tun, wenn das so rüberkam war es nicht so gemeint.

Natürlich könnte man jeden ekligen Hack in die GUIs reinmachen, tatsächlich sind wir aber, zumindest ist das mein Gefühl, eher dabei, alte unnötige Hacks zu entfernen und durch korrekte(re) Lösungen zu ersetzen.
Was ich persönlich auch gut finde.

Wegen der Speicherproblematik müsste sich halt mal jemand mit valgrind (falls das auf der dbox zu benutzen ist) hinsetzen und schauen wo's kracht. Oder die malloc()-Dokumentation lesen und rausfinden, wo man da optimieren kann. Der Speicher ist ja nicht wirklich belegt, sonst würde dir die box bei deinem Stunt jedes mal um die Ohren fliegen.

[PauleFoul]

Jo, saubere Lösungen sind mir auch lieber... Ausserdem möchte ich sagen das ich mit dem Skript keinerlei Probleme sprich abstürze habe....

[mrvica]

Ich habe da was für mich gebastelt, vielleicht kann es jemand gebrauchen, im Prinzip tut es dasselbe was GUI macht, hier als Plugin, testen ob es funktioniert, in Enigma in File Mode gehen (Movie Player) und ein .ts File abspielen, in TV Modus zurückschalten, der Speicher geht zurück auf ~1MB, Plugin starten, es müssten danach ~9MB frei sein, es macht Image Backup in /tmp, mit /cat/proc/mtd kann man sich die Partionen anschauen, hier mtd4 für Complete Flash und jffs2 Image, im squashfs Image können Partionen anders belegt sein

freeram.cfg

Code: Alles auswählen

name=free some memory (8MB)
desc=may occasionally reboot Your Box
type=3
needfb=0
needrc=0
needlcd=0

freeram.sh

Code: Alles auswählen

#!/bin/sh
#cat /proc/mtd
echo
echo "memory status before:"
free
cat /dev/mtd/4 > /tmp/mtd4.img
echo
echo
echo "freeing 8 MB of RAM....."
echo "if You can read this message, everything went OK"
echo
echo
rm -f /tmp/mtd4.img
echo "memory status after:"
free
echo
cat /proc/meminfo
exit;

mrvica