Sectionsd abnehmender Speicher -> Reproduzierbar!!!

[Homar]

Zwischenbericht:

- die Memleaks dürften zu 80 Prozent weg sein
- der EGP-Thread ist fertig (eitThread)
- heute werde ich die Änderungen in nit und sdt übernehmen
- Laufzeittest ist bisher erfolgreich
- Table 60 ist auch mit drin

Die Auswertung der einzelnen Sectionen habe ich bei mir nun umgestaltet, sodas nicht wie bisher schleifen durchlaufen, bis alle events einer Tabelle eingelesen werden, sondern nach der Häufigkeit der events ausgewertet werden.
D.h. die aktuellen, deren häufigkeit erhöht sind, werden sofort eingelesen und der Rest auf Anfrage (immer wenn mann kanal wechselt werden eingelesen) sonst bei verbleib auf den Kanal.
Vorteil ist, das die Prozessorlast nicht mehr bei 98% rumschwirt, sondern minimum um die hälfte gesunken ist.

Speicherverbrauf im Kabelnetz ist um ca. 40% nach unten gegangen.
Anstelle von 18MB sind es nun knapp 10MB, wenn ich durch alle Kanäle zappe und zeit zum einlesen der events gebe.

Was noch nicht getestet ist, sind nvod-events und Sat-Provider ohne EPG.

Falls das jemand testen mag, gibts heute im laufe des langen abends, die binary auf http://dboxupdate.info/sectionsd

[mash4077]

Cool!

Gruß
mash

[mb405]

das klingt sehr gut
is denn schon weihnachten ?

[PauleFoul]

Absolut stabil auf 3 Boxen am laufen...

Ihr könnt anfangen neu zu schreiben... Mit diesem Stand können wir
solange leben...


Gruß
____Paule

[Innuendo]

uiuiui

homar: könntest du auch neben dem bin die source anbieten?

innu

[Homar]

Sourcen ist noch jede menge mit Kommentaren verseucht... aber kommt eh ins cvs

ahja.. die Sourcen von Nirvana müssen auch eingepflegt werden

[Innuendo]

Sourcen ist noch jede menge mit Kommentaren verseucht

vlt versteht man dann ein klein bisschen mehr, wo was passiert

[Innuendo]

Ich habe nur filter 0x60 an und "static long secondsToCache = 7*24*60L*60L;" + "static long oldEventsAre = 20*60L;" .
Aber das ist nicht so wichtig.

zusätzlich kannst du noch an nirvana's max_events drehen, aber auch das ist nicht so wichtig.
nur dmxEIT mußte ich bei mir wieder auf houdinis fix 1024 hochsetzen. mit 256/384/512 kamen regelmäßig received pollerr oder read: value too large ... meldungen im log

[PT-1]

@ Homar

Deine http://dboxupdate.info/sectionsd geht nicht !!!

[Houdini]

heute im laufe des langen abends

[PT-1]

Jetzt habe ich ja schon eine extra Stunde gegenueber euch ;-)

Danke aus London ;-)

EDIT: 2 Minuten noch bis zum neuen tag ;-)

[Hollo]

@ Homar

Deine http://dboxupdate.info/sectionsd geht nicht !!!

geht mit FlashGet oder anderem Downloadtool

[Innuendo]

hat da jemand die alte sectionsd verlinkt?

sectionsd.cpp,v 1.215 2005/12/10 03:56:15 homar

[Houdini]

Der Revision Tag ändert sich nur wenn eingecheckt wird

[PauleFoul]

Erst einmal vielen Dank und Respekt für Eure tolle Arbeit am Sectionsd!!

Erster Kurztest zeigt:
- CPU-Last der Sectionsc nicht über 52%
- Now und Next-Event nach dem Zappen auf neue Sender schnell in der Infobar
- schnelles einlesen der Events
- Speicherverbrauch liegt bei 42% (TOP)


Gruß
____Paule

[Innuendo]

Der Revision Tag ändert sich nur wenn eingecheckt wird

dann lief die neue bei mir im kurztest(!) nicht so gut
idle cpu last sehr hoch(>80%) - beim zappen ging sie runter(~30%) ?!?

fehler wegen dummen user durchaus möglich.

innu

[Houdini]

@Homar:
Ich teste gerade diene Version von gestern Abend. Funktioniert soweit, nur die old_events werden bei mir nicht richtig rausgenommen. Alle events des laufenden Tages sind noch da

[PauleFoul]

@Homar:
Ich teste gerade diene Version von gestern Abend. Funktioniert soweit, nur die old_events werden bei mir nicht richtig rausgenommen. Alle events des laufenden Tages sind noch da

Also bei mir wächst der Speicherverbrauch stetig an... Das wir dann
wohl auch an den alten Events liegen. Ansonsten läuft die Sache aber
recht stabil...


Gruß und ein schönes Weihnachtsfest
_______________________________Paule

[Homar]

hi,

das hatte ich gemerkt, aber an der removeEvents habe ich nichts verändert.

Im Protokoll sieht mann, das die events gelöscht werden, jedoch wird der Speicher nicht freigegeben.

Einmal allokiert und für immer behalten

Die SharedPointers ist nicht wirklich cool.

Kannste vielleicht eine Klasse proggen, die die Verwaltung der Pointer übernimmt?

Ich hatte eine fertige klasse mal geschrieben, für ein Projekt in der Uni...

Ich finde es bloss nicht mehr.

[mws]

hi,

das hatte ich gemerkt, aber an der removeEvents habe ich nichts verändert.

Im Protokoll sieht mann, das die events gelöscht werden, jedoch wird der Speicher nicht freigegeben.

Einmal allokiert und für immer behalten

Die SharedPointers ist nicht wirklich cool.

Kannste vielleicht eine Klasse proggen, die die Verwaltung der Pointer übernimmt?

Ich hatte eine fertige klasse mal geschrieben, für ein Projekt in der Uni...

Ich finde es bloss nicht mehr.

ehm homar? shared_ptr sind genau für sowas gedacht
wenn das nicht funktioniert, muss man mal kuggen, was damit falsch gehandelt wird. sind nicht soooooooo einfach zu handeln.

gruss
mws

[Torsten73]

Hi Homar:
habe nun auch Deine Sectionsd mal laufen gelassen.

Die schon beschriebenen Vorteile kann ich nur bestätigen. Leider auch, dass die Sectionsd nach 12h bereits 43% Mem verschlingt (Specherfrax Old Events)
Mit dem Problem hat doch Houdini oder Nirvana auch gekämpft und gelößt. Vielliecht läßt sich deren Lösungsansatz auch in Deine implementieren? Da werden die alten events tatsächlich mittlerweile gelöscht.

Was mich noch sehr verwundert, ist der Free Mem Verlauf. Bei deiner Sectionsd wird immer ein sehr hoher freier Speicher angezeigt (>6000KB) selbst wenn die Sectionsd bei 12000kb bereits liegt. Dafür ist der Buffers sehr niedrig (ca 300). Ob das gut oder schlecht ist, weiß ich nicht wirklich, da ich noch immernicht so ganz durchblicke welche Werte wofür wichtig sind. Bei Nirvanas war es halt ganz anders, da war Buffers bei ca 2500 und Sectionsd bei ca 6000kb und Freemem bei ca 5500KB.

Wenn Buffers auch für den Ringbuffer verantwortlich sind, dann habe ich allerdings eine Erklärung dafür, warum alle 2 Aufnahmen auf ZDF bisher mit Deiner Sectionsd fehlgeschlagen sind. Bei mir steht RingBuffers auf 99.

Mit Nirvanas Sectionsd aus dem CVS funktionierten die Aufnahmen.

Was ich noch sehr positiv finde sind die wesentlich besseren Debugausgaben! (Auch wenn sie mir nur teilweise was sagen, aber das erkennt selbst ein Laie !)

Cu
Torsten

[Homar]

hi Thorsten,

das dauert nicht mehr lange...

Nirvana hat sein code geschickt, den ich noch einpflegen muss.

in der Zwischenzeit habe ich eine neue Version geuppt,

Der Speicherverbrauch ist um weitere 20 % gesunken, die buffer sind optiemert und es löscht in der zwischenzeit auch noch.

Nun noch Nirvanas sachen einpflegen und wenn ok, dann einchecken.

[mb405]

das klingt alles schon sehr gut. mit der letzten offiziellen (open source) sectionsd kann ich schon gut leben (ohne sectionsd scan).
aber ihr macht das schon, so wie ich das sehe.

[PauleFoul]

@ Homar

Also der Speicherverbrauch liegt jetzt bei 28% mal sehen ob er
über die Zeit noch ansteigt...

Allerdings in die Cache jetzt auf 8000kb angestiegen. War in der ersten
Version nicht so...


Gruß
____Paule

[Torsten73]

Hi,
so nach über 4 Tagen Uptime mit dem JTG 26.12. auf der Nokia Avia 500 Sat mit CVS Sectionsd gibt es mal wieder ein Top:

Code: Alles auswählen

39 processes: 38 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   2.6% user,   4.6% system,   0.0% nice,  92.8% idle
Mem:     30916K total,    28116K used,     2800K free,     1788K buffers
Swap:        0K total,        0K used,        0K free,     8960K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  511 root      14   0   792  792   636 R     6.5  2.5   0:01 top
  508 root       9   0   424  420   340 S     0.5  1.3   0:00 telnetd
    1 root       8   0    88   88    68 S     0.0  0.2   0:04 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:01 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   2:03 ksoftirqd_CPU0
    4 root       9   0     0    0     0 SW    0.0  0.0   2:13 kswapd
    5 root       9   0     0    0     0 SW    0.0  0.0   0:00 bdflush
    6 root       9   0     0    0     0 SW    0.0  0.0   0:00 kupdated
    7 root       9   0     0    0     0 SW    0.0  0.0   0:01 mtdblockd
    9 root       9   0    80   80    60 S     0.0  0.2   0:00 init
   10 root       9   0    84   80     0 S     0.0  0.2   0:00 rcS
   13 root      15  10     0    0     0 SWN   0.0  0.0   0:00 jffs2_gcd_mtd3
   21 root       9   0   152  148    52 S     0.0  0.4   0:00 inetd
   80 root       9   0    84   80     0 S     0.0  0.2   0:00 start_neutrino
   84 root       9   0  8008 8004   436 S     0.0 25.8   0:09 sectionsd
   86 root       9   0  8008 8004   436 S     0.0 25.8   0:00 sectionsd
   87 root       9   0  8008 8004   436 S     0.0 25.8   0:07 sectionsd
   88 root       9   0  8008 8004   436 S     0.0 25.8 339:25 sectionsd
   89 root       9   0  8008 8004   436 S     0.0 25.8   0:00 sectionsd
   90 root       9   0  8008 8004   436 S     0.0 25.8   0:20 sectionsd
   91 root       9   0  8008 8004   436 S     0.0 25.8   4:57 sectionsd
   92 root       9   0  8008 8004   436 S     0.0 25.8   0:36 sectionsd
   93 root       9   0   524  524   352 S     0.0  1.6   0:00 timerd
   96 root       9   0   524  524   352 S     0.0  1.6   0:00 timerd
   97 root       9   0   524  524   352 S     0.0  1.6   0:04 timerd
   98 root       9   0     0    0     0 SW    0.0  0.0   0:00 kdvb-fe-0:0
   99 root       9   0   844  844   184 S     0.0  2.7   2:06 zapit
  103 root       9   0   172  168   112 S     0.0  0.5   0:00 camd2
  105 root       9   0   764  764   600 S     0.0  2.4   0:00 controld
  107 root       9   0   764  764   600 S     0.0  2.4   0:00 controld
  108 root       9   0   764  764   600 S     0.0  2.4   0:02 controld
  109 root       9   0   700  700    16 S     0.0  2.2   0:03 nhttpd
  110 root       9   0  5480 4668  1700 S     0.0 15.0   1:42 neutrino
  111 root       8   0  5480 4668  1700 S     0.0 15.0   0:01 neutrino
  112 root       9   0  5480 4668  1700 S     0.0 15.0   3:27 neutrino
  122 root       9   0     0    0     0 SW    0.0  0.0  11:32 rpciod
  132 root       9   0  5480 4668  1700 S     0.0 15.0   0:00 neutrino
  145 root       9   0   700  700    16 S     0.0  2.2   0:00 nhttpd
  509 root       9   0   660  660   548 S     0.0  2.1   0:00 sh

Es wurde Tuxtext genutzt und täglich auf ZDF "Ich heirate eine Familie aufgezeichnet. Zwischendurch ein wenig herumgezappt.
Der Sectionsdscan ist übrigens an!

Feststellungen:
Der Speicherverbrauch des Sectionsd nimmt immer noch zu, ca 1%/Tag. Das ist zwar nicht wild, aber läßt vorausberechnen wann Schluß ist... (in ca 3 Wochen...)

Übrigens wenn man jetzt eine TS Wiedergabe startet, nimmt der freie Speicher rapide ab (auf ca 500kb) läßt die Box aber weiterlaufen! So sieht es bei der Box meiner Schwiegermutter aus, selbe Uptime und seit Anfang an mit "nur" 500-700KB freien Speicher.

Warum aber der Movieplayer sich den Speicher nur bei der Wiedergabe und nicht auch bei der Aufnahme krallt und wieder freigibt, ist mir ein Rätsel. Das ist aber eine andere Baustelle.

So dann feiert heute abend mal schön!
Frohes neues Jahr!

Torsten