Stiftung: Stabiler sectionsd

Nico 77 hat geschrieben:Ganz einfach, weil der Speicher trotzdem vollgeschrieben wird.
Ein hinauszögern durch weglassen ist kein Fixen.

Das lösen von Houdini's beschrieben Problem 1 und 2 wäre meiner Meinung nach der richtige Weg und das ohne zusätzlichen Konfigrationsdschungel.

verstehe die diskussion nicht - der gemeine user stellt doch beim senderscan ein, was er haben will. demnach gehören die radio events natürlich dazu, wenn er tv+radio eingestellt hat - andernfalls muss man die box mit radio events nicht zuballern, wenn eh keine sender dafür gescannt wurden. ich seh da keinen konfig-dschungel.

kann der sectionsdclient zwischen tv und radio event unterscheiden?
an welcher stelle finde ich die eine solche info?

for(int i = 0; i < nBufSize;i++)
if(((unsigned char)pData) == ???? )
//radio event

aber ich geb dir recht, dass erstmal die beiden probleme gelöst werden sollten, bevor man sich über features und wünsche unterhält.

innu

p.s.: @nirvana
checkt doch bitte alles ins cvs ein, wenn hier darauf bezug genommen wird. dein max_event patch ist nur hier als link vorhanden - finde es sehr unübersichtlich, wer gegen was ein diff/binary/patch anbietet.

@Innuendo.

Weder Houdini noch ich haben Schreibrechte im CVS.

dann sind es 3 probleme die gelöst werden sollten.
wußte ich nicht nirvana

innu

Beitrag von **kroki** » Dienstag 13. Dezember 2005, 10:19

Hi all,

Meine Idee:

Wenn der Speicher nicht reicht, dann muss man eben weniger Events es speichern oder das ganze platzsparender (komprimieren)! versuchen.

Da es sich bei den Events um reinen Text handelt, sind hier bestimmt Komprimieriungsraten von ca 70% möglich ......

Vielleicht ist das ein sinnvoller Ansatz....

Gruß Kroki

Beitrag von **Homar** » Dienstag 13. Dezember 2005, 13:14

also ich weiss im moment nicht, ob die radio-events ausgefiltert werden können, aber...

Die Radio-events brauchen nur eingescannt werden, wenn ich auf Radio switche, vorher nicht

Ich habe die DVB-SI Doku nicht zur Hand, aber ich müsste mich schon sehr täuschen:

Man kann einem Event nicht direkt ansehen, ob es für Radio oder Fernshen ist. Man müsste die Service ID auswerten und damit dann die Senderliste durchsuchen.

Nirvana hat geschrieben:Moment. Auf ARD braucht der sectionsd min. 15 Minuten bis er das Limit erreicht. So lange kommen tatsächlich neue Events. Er schlummert ja immer zwischendurch ein.

Also, hier der aktuelle Zwischenbericht:

Box neu gestartet, steht seit 22 Min auf arte

Code: Alles auswählen

 10:44pm  up 22 min,  0 users,  load average: 0.05, 0.01, 0.00
40 processes: 39 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   2.6% user,   4.3% system,   0.0% nice,  93.1% idle
Mem:     30916K total,    20776K used,    10140K free,     2452K buffers
Swap:        0K total,        0K used,        0K free,     7348K cached

Programmwechsel auf ARD

Code: Alles auswählen

 10:45pm  up 23 min,  0 users,  load average: 0.71, 0.17, 0.05
41 processes: 38 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  76.4% user,  23.6% system,   0.0% nice,   0.0% idle
Mem:     30916K total,    22356K used,     8560K free,     2452K buffers
Swap:        0K total,        0K used,        0K free,     7348K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  105 root      18   0  5592 5588   960 R    90.6 18.0   1:02 sectionsd

stehen lassen

Code: Alles auswählen

 10:50pm  up 28 min,  0 users,  load average: 0.11, 0.19, 0.09
41 processes: 40 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   3.0% user,   4.1% system,   0.0% nice,  92.9% idle
Mem:     30916K total,    21348K used,     9568K free,     2452K buffers
Swap:        0K total,        0K used,        0K free,     7348K cached

Hab dann auf ARD aufgenommen, Stand heute morgen:

Code: Alles auswählen

  7:48am  up  9:26,  0 users,  load average: 0.05, 0.17, 0.16
41 processes: 40 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   3.0% user,   3.7% system,   0.0% nice,  93.3% idle
Mem:     30916K total,    20048K used,    10868K free,     2444K buffers
Swap:        0K total,        0K used,        0K free,     5940K cached

13 mal auf arte - Das Erste - WDR in einminütigem Abstand umgeschalten:

Code: Alles auswählen

  8:25am  up 10:03,  0 users,  load average: 1.25, 1.37, 1.25
41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  67.1% user,  20.7% system,   0.0% nice,  12.2% idle
Mem:     30916K total,    25372K used,     5544K free,     2444K buffers
Swap:        0K total,        0K used,        0K free,     5940K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  105 root      20   0  9700 9696   960 R    78.3 31.3  56:18 sectionsd

Top ist in der Telnet-Sitzung jetzt zum 2. Mal ausgestiegen, Box läuft:

Code: Alles auswählen

 12:36pm  up 14:14,  0 users,  load average: 1.59, 1.54, 1.47
41 processes: 39 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  77.3% user,  22.7% system,   0.0% nice,   0.0% idle
Mem:     30916K total,    28900K used,     2016K free,     2632K buffers
Swap:        0K total,        0K used,        0K free,     6176K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  105 root      15   0 12668  12M   960 R    88.1 40.9 258:56 sectionsd

nach 118 Durchläufen, also 354 mal Umschalten sieht es jetzt so aus:

Code: Alles auswählen

  1:48pm  up 15:26,  0 users,  load average: 1.30, 1.42, 1.41
41 processes: 38 sleeping, 3 running, 0 zombie, 0 stopped
CPU states:  55.9% user,  27.5% system,   0.0% nice,  16.5% idle
Mem:     30916K total,    29704K used,     1212K free,     2632K buffers
Swap:        0K total,        0K used,        0K free,     6176K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  105 root      18   0 13468  13M   960 R    70.6 43.5 317:21 sectionsd

Also für mich sieht das eindeutig so aus, dass die sectionsd da noch suckt. Werd jetzt die Box mal stehen lassen und abwarten, ob wieder Speicher freigegeben wird.

Weder Houdini noch ich haben Schreibrechte im CVS.

Also ich hab jetzt schon...

Houdini hat geschrieben:
Weder Houdini noch ich haben Schreibrechte im CVS.
Also ich hab jetzt schon...

..but some are more equal.

Ich hatte gestern diesen nervigen Premiere Sportal Bug gejagt, bei dem ein Event mit ganz komischen Zeiten angezeigt wird und kein next Event.

Ich konnte ihn zurückverfolgen bis:
findActualSIeventForServiceUniqueKey

Wenn man da

Code: Alles auswählen

for (SItimes::reverse_iterator t = (*e)->times.rend(); t != (*e)->times.rbegin(); t--)

gegen

Code: Alles auswählen

for (SItimes::iterator t = (*e)->times.begin(); t != (*e)->times.end(); t++)

austauscht, tritt er nicht mehr auf. Zum Verstehen fehlte mir allerdings die Zeit.

Ansonsten hatte ich gestern den Vorschlag realisiert, weiter entfernt in der Zukunft liegende Events bei Erreichen den Eventlimits zu löschen und durch näher liegende zu ersetzten. Klappt hervorragend und ist nur eine 3-Zeilen Änderung. Stelle ich nachher zur Verfügung. Da kann man dann schön sehen, dass wenn man Events von einem neuen Sender holt, die Vorschau der ARD immer weiter zusammenschrumpft. Kleiner als 5 Tage habe ich sie aber nicht bekommen.

Hallo,

ich habe mir gestern mal den sectionsd bezüglich memory leak angeschaut und dabei ist mir folgendes aufgefallen. Hier meine Notizen, vielleicht könnt ihr ja mal einen Blick drauf werfen...

.com// $Id: sectionsd.cpp,v 1.215 2005/12/10 03:56:15 homar Exp $

1970:
delete[] pResultData;
**************
609:
static void addBouquetEntry(const SIbouquet &s)
{
SIbouquet *bp = new SIbouquet(s);
************
5729:
eventServer = new CEventServer;
no delete of eventServer
***************
2783:
if (responseHeader.dataLength)
{
delete[] msgData;
}

might be dangerous if somebody is adding some code with less experience, think about this:
if (msgData != NULL)
{
delete[] msgData;
msgData = NULL;
}
********************
Frage: wo gelöscht?
375: SIevent *eptr = new SIevent(evt);
(mySIeventsOrderUniqueKey.insert(std::make_pair(e->uniqueKey(), e));)
-> housekeeping, schein OK zu sein

649: SInetwork *nw = new SInetwork(s);
mySItranspondersOrderUniqueKey.insert(std::make_pair(tpptr->uniqueKey(), tpptr));
-> housekeeping, auskommentiert ???
************************
Beim fixen am besten noch ein printf einfügen, damit man später weiss, ob es auch ein aktives Memory-Leak war.

Günther

printf(" NOTE: memory leak fixed (1)!");

Ich sage hier was zu 609 und 649.

Die werden nicht wieder gelöscht und das ist so gewollt. Der Bedarf ist endlich und abhängig von der Zahl der Transponder und Services in der SI. Geschätzt: 250 kb.

Achja, hier war noch der Überblick über DVB-S von dem ich weiter oben gesprochen habe, vielleicht hilft es ja auch den einen oder anderen in die Materie einzusteigen (mir hats jedenfalls geholfen

. In der Ersten wurde der PrivatEPG generell als problematisch angesehen. Die Arbeit ist aber schon etwas älter (2003).

http://www.theoinf.tu-ilmenau.de/~strei ... h='Andreas Schrankel'
http://www.theoinf.tu-ilmenau.de/~strei ... arch='Sven Schaepe DVB'

Die DVB-S Spec gibts ansonsten bei http://www.etsi.org

Günther

Hallo Günther, hier meine Analyse dazu:

1970:
delete[] pResultData;

ok, wird nur freigegeben, wann auch was allokiert worden war (nResultDataSize > 0)

609:
static void addBouquetEntry(const SIbouquet &s)
{
SIbouquet *bp = new SIbouquet(s);

Memory Leak, wird nirgedwo benutzt/freigegeben, kann deswegen meineserachten auch raus, es sei denn es soll mal für was benutzt werden

5729:
eventServer = new CEventServer;
no delete of eventServer

Memory Leak, wird aber nur einmal allokiert und steht solange wie sectionsd läuft. Gleiches gilt auch für die pthread_create()

2783:
if (responseHeader.dataLength)
{
delete[] msgData;
}

ok

might be dangerous if somebody is adding some code with less experience, think about this:
if (msgData != NULL)
{
delete[] msgData;
msgData = NULL;
}
********************

Frage: wo gelöscht?
375: SIevent *eptr = new SIevent(evt);
(mySIeventsOrderUniqueKey.insert(std::make_pair(e->uniqueKey(), e))
-> housekeeping, schein OK zu sein

yep housekeeping löscht die events aus den listen/maps die shared ptr rufen den destructor auf

649: SInetwork *nw = new SInetwork(s);
mySItranspondersOrderUniqueKey.insert(std::make_pair(tpptr->uniqueKey(), tpptr));
-> housekeeping, auskommentiert ???

Memory leak, wird nirgendwo wieder freigegeben, die liste wird einmal aufgebaut und dann im Speicher gehalten

Houdini hat geschrieben: SIbouquet *bp = new SIbouquet(s);
Memory Leak, wird nirgedwo benutzt/freigegeben, kann deswegen meineserachten auch raus, es sei denn es soll mal für was benutzt werden

Ist in meinen letzten Versionen längst raus. Das werden mal die automatischen Bouquets.

Das gleiche wie für die SInetworks gilt aber noch für die Services. Die Liste wird auch permanent im Speicher gehalten.

Hi,
jetzt haben wir ja schon vieles geschrieben und erörtert, was für die Probleme als Ursache in Frage kommt und wie man den wachsenden Speicherbedarf bei immer größer werdenen EPG Infos seitens der Sender Herr werden kann.

Ganz ehrlich, wie Nirvana & Houdini es in den Griff bekommen ist eigentlich deren Sache, es ist schon schwer und zeitraubend genug überhaupt den suckenden Sectionsd zu fixen.
Also übertreibt es nicht, sonst habt Ihr Eure Energie nachher beim Fixen ausgepowert, was für ein Rewriting effektiver gewesen wäre.

Ich meine es wird niemand böse sein, wenn der Speicherleek nicht gefixt wird und statt dessen die Menge der gesammelten Daten irgendwie begrenzt werden, so dass man zumindet wieder eine Woche lang den Sectionsd nutzen kann ohne Neustarten zu müssen.

Ich denke das die Tabellenverwaltung bei einem "neuen" Sectionsd noch viele andere Vorteile bringt, wie z.B. die Möglichkeit des Auslagerns auf einen Share oder die Tabelle komprimieren zu können (das wäre ja mit im Speicher befindlichen Daten nicht möglich?) und man ließt halt nur das aus der Tabelle ein was gerade nötig ist.

Des weiteren ist es beim JTG vom 10.12. weiterhin so, das bei Sat nach spätestens 1,5 Tagen die Box langsam wird (hier hilft noch ein killall) und danach ganz sich verabschiedet. Aber da fehlen auch einiger der von Euch bereits getesteten Änderungen (da ja in den letzten Tagen nichts mehr ins CVS gekommen ist).

Ich bin trotzdem guter Hoffung das Ihr dieses Jahr einen weitaus stabieleren Betrieb noch hinbekommen, danke Eurer Unermündlichen Arbeit und Mühe :!:

Cu
Torsten

Also meine Box läuft jetzt seit 3 Tagen mit dem JtG-Snap vom 10.12. Sectionsd ist die version 1.215. Wenn der so weiter läuft din ich zufrieden.

Code: Alles auswählen

~ > uptime
 00:05:56 up 3 days,  1:04, load average: 0.00, 0.00, 0.00
~ > free
              total         used         free       shared      buffers
  Mem:        30916        28780         2136            0          768
 Swap:            0            0            0
Total:        30916        28780         2136

Code: Alles auswählen

 12:09am  up 3 days,  1:07,  0 users,  load average: 0.00, 0.00, 0.00
45 processes: 44 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   3.3% user,   4.8% system,   0.0% nice,  91.9% idle
Mem:     30916K total,    29200K used,     1716K free,      852K buffers
Swap:        0K total,        0K used,        0K free,     4676K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1643 root      16   0   796  796   636 R     7.9  2.5   0:02 top
 1637 root       9   0   424  420   340 S     0.1  1.3   0:00 telnetd
    1 root       8   0   536  536   516 S     0.0  1.7   0:04 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:05 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   1:31 ksoftirqd_CPU0
    4 root       9   0     0    0     0 SW    0.0  0.0   0:00 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:01 kupdated
    7 root       9   0     0    0     0 SW    0.0  0.0   0:00 mtdblockd
    9 root       9   0   532  532   512 S     0.0  1.7   0:00 init
   10 root       9   0   528  524   444 S     0.0  1.6   0:00 rcS
   13 root      15  10     0    0     0 SWN   0.0  0.0   0:03 jffs2_gcd_mtd3
   21 root       9   0   592  588   492 S     0.0  1.9   0:00 inetd
   59 root       9   0     0    0     0 SW    0.0  0.0   3:48 avia_av_wdt
   82 root       8   0   524  520   440 S     0.0  1.6   0:00 start_neutrino
   94 root       9   0 14732  14M   956 S     0.0 47.6   0:05 sectionsd
   96 root       9   0 14732  14M   956 S     0.0 47.6   0:00 sectionsd
   97 root       9   0 14732  14M   956 S     0.0 47.6   0:04 sectionsd

Gruß Michael

@MOhlmann:
Hast Du auch Sat? Bei meiner Nokia Sat ist keine Uptime größer 2 Tage möglich, es wird viel auf ARD und ZDF gezappt, ebenso Premiere.

so sieht es bei mir aus:

Code: Alles auswählen

/>uptime
 00:16:53 up  9:50, load average: 0.11, 0.14, 0.10

Code: Alles auswählen

RAM Speichernutzung
-------------------
              total         used         free       shared      buffers
  Mem:        30916        30044          872            0         1632
 Swap:            0            0            0
Total:        30916        30044          872

Da gebe ich brief und Siegel, das der nächste Hänger nicht mehr lange auf sich warten läßt!

die 2. Nokia nimmt nur MCE auf sonst keinEPG eingelesen:

Code: Alles auswählen

/>uptime
 00:23:15 up 1 day, 53 min, load average: 0.17, 0.19, 0.18

Code: Alles auswählen

RAM Speichernutzung
-------------------
              total         used         free       shared      buffers
  Mem:        30916        23144         7772            0         2756
 Swap:            0            0            0
Total:        30916        23144         7772

Nur mit MCE Recording läuft die Box über Tage durch ohne groß sich im Speicher zu verändern.

Cu
Torsten

Beitrag von **petgun** » Mittwoch 14. Dezember 2005, 09:59

MOhlmann hat geschrieben:Also meine Box läuft jetzt seit 3 Tagen mit dem JtG-Snap vom 10.12. Sectionsd ist die version 1.215. Wenn der so weiter läuft din ich zufrieden.

ja, ich auch. Meine laeuft seit 42 Stunden...sectionsd hat sich 39,5% Ram gekrallt (scheint auch nicht mehr zu werden) aber eine Prozesszeit von 176 Minuten...an so so hohe Werte kann ich mich allerdings nicht erinnern. Die Prioritaet scheint aber sehr niedrig zu sein...bis jetzt habe ich nix negatives in Verbindung mit sectionsd mehr feststellen koennen..

@petgun

zappe mal auf das erste - ein paar minütchen verweilen - dann schallte auf einen nicht ard kanal - warte wieder ein paar minuten und geh dann zurück auf das erste und beobachte den speicher.
bei mir (sectionsd 1.125 mit nirvana max event patch) verbraucht die sectionsd dann viel speicher, obwohl eigentlich keine neuen epg daten vorhanden sein können.

Beitrag von **petgun** » Mittwoch 14. Dezember 2005, 10:24

Innuendo hat geschrieben:..zappe mal auf das erste - ein paar minütchen verweilen - dann schallte auf einen nicht ard kanal - warte wieder ein paar minuten und geh dann zurück auf das erste und beobachte den speicher..

..das habe ich schon mehrfach gemacht...Speicherbedarf hat sich nicht wesentlich geaendert.

PS:..nach einer weiteren zapping Orgie hat sich den Speicherbedarf von 39,5% auf 40,9% erhoeht. Wenn sich der Speicherbedarf auch mal verringern wuerde, koennte man vielleicht sicher sein das alles gruen ist...keine Ahnung...mir reicht die momentane Stabilitaet. Aber wahrscheinlich hast Du Recht...der Speicherbedarf steigt immer nur an...dh. irgendwann muesste das crashen..

PPS:..jetzt bin ich schon auf 43,6% Speicherbedarf...

lass die box mal über nacht laufen und wiederhol das morgen früh. gestern abend (nach knapp 22h uptime) war ich froh, dass es scheinbar besser ist (rund 5MB freier speicher) - box lief über nacht durch auf ard. heut morgen vor dem zappen rund 4.5MB - ein bissl zdf, pro7 etc und jeweils auf den sendern für einen moment verblieben (speicherveränderung kaum erwähnenswert) und zurück auf ard: jetzt geht die (speicher)post ab: im 5 sekundentakt free auf der konsole eingeben und es fehlen jeweils rund 1024kb speicher .... nach 5 minuten 768kb
vermutlich gibt es jetzt doppelte events im speicher (oder eine gespeicherte epg liste ins ins nirvana [dolles wortspiel] verschoben) - nach einer weile (oldeventsare 10 minuten) wird der freie speicher wieder etwas größer (etwa 1.5mb) - nirvanas max_event patch hat hier auch nichts bewirkt. vlt ist das noch eine sache wo die experten nachgucken könnten ... wenn sich das datum verändert ... *unwissend gugg*

innu
p.s.: wolltest du nicht deinen dreizeiler max_events && hourstocache posten?

Beitrag von **petgun** » Mittwoch 14. Dezember 2005, 11:39

...sieht wirklich immer noch nicht so gut aus. Wenn der Speicherverbrauch so ansteigt/zu wenig Restspeicher vorhanden ist, klappt auch keine Direkt-Aufnahme mehr

...die brauche ich aber gelegentlich und sollte fuer mich immer zuverlaessig funktionieren...also jetzt wieder einen Neustart gemacht....klinke mich hier also mal wieder mit Berichten zur Langzeitstabilitaet vom sectionsd aus...das Teil bringts immer noch nicht....und vor diesen ganzen Aenderungen gab es diese Probleme nicht!

Beitrag von **zexma** » Mittwoch 14. Dezember 2005, 12:12

petgun hat geschrieben:... klappt auch keine Direkt-Aufnahme mehr ...und vor diesen ganzen Aenderungen gab es diese Probleme nicht!

oh doch, nur nicht so ausgeprägt.

Beitrag von **petgun** » Mittwoch 14. Dezember 2005, 13:28

zexma hat geschrieben:oh doch, nur nicht so ausgeprägt.

..mag sein...mir ist das in der Vergangenheit nicht aufgefallen.
Ich bin erst mal (solange bis die Probleme beseitigt sind) fuer einen festgelegten Speicher von...8192 KB...(bei 32 MB Ram)...mehr darf/kann sich sich sectionsd halt nicht krallen. Wenn dann keine neuen Eintraege mehr kommen/EPG wech ist, muss man halt (EPG/Box) neu starten aber wenigstens crasht die Box nicht und andere Funktionen werden nicht beeintraechtigt.

das wollte nirvana mit seinem max event patch erreichen.
allerdings ist der patch nicht im cvs, nur weiter oben verlinkt.

wenn jetzt ein diff gegen homar's 1.125 ins cvs eingecheckt wird, bekomme ich wahrscheinlich wieder ein halbes dutzend rejects

Tuxbox-Board

Stiftung: Stabiler sectionsd

Memory leaks