Sectionsd abnehmender Speicher -> Reproduzierbar!!!

[JtG-Riker]

http://s55.yousendit.com/d.aspx?id=2XPO ... ENIR61EY8L

Ist das diff gegen das aktuelle CVS.

@Metallica
Also Party machen sieht anders aus! Ich habe Kekse gebacken!

@all
Meine Meinung zu der aktuellen Version: Ich finde Table 60 sollte wieder ausgewertet werden. Sonst fehlen mir immer einige Einträge. Wie ich schon mal sagte: Die Vorschau wird dann kürzer, weil ja die MAX_EVENTs (und der Speicherverbrauch) gleich bleiben, aber sie ist dann vollständig.

@Thorsten
Du solltest nicht glauben, was im Log steht. Dass die Events immer wieder hinzugefügt werden ist okay, weil sie zunächst ohne erweiterten Text gesendet werden und die genaue Beschreibung erst später folgt.

Baut nicht hier :



sectionsd.cpp: In function `bool addTransponder(const SInetwork&, bool)':
sectionsd.cpp:711: error: 'class SInetwork' has no member named 'is_actual'
sectionsd.cpp: In function `bool updateNetwork()':
sectionsd.cpp:3919: error: 'class SInetwork' has no member named 'is_actual'
make[4]: *** [sectionsd.o] Error 1

[Nirvana]

http://s49.yousendit.com/d.aspx?id=3IJA ... KOOXSO4QXH

Achja, wohl ein paar Kekse zu viel gegessen. Ich vergaß, dass meine Version ja nicht richtig difft.

[Innuendo]

die version läuft auch bei mir erheblich besser. der max_events patch von nirvana war eine prima idee!

@riker: nimm auf jedenfall auch den letzten houdini patch mit (notifier für hourstocache)

kann von euch auch mal jemand schauen, ob er für diesen fehler die ursache finden kann:

[dmx.cpp:read:184] read(fd, buf, n): Connection timed out
zap failed!

der fehler tritt unabhängig vom speicher irgendwann auf. mal 1-3 tage gar nicht, dann mehrmals täglich.

innu

[Houdini]

den letzten houdini patch mit

Problem dabei ist aber noch: Wenn sectionsd im laufenden Betrieb neugestartet wird werden die konfigurierten HoursToCache nicht dem sectionsd nach neustart neu übergeben!

[mws]

"CVS ist ein Entwicklerbranch der nicht funktionieren muss hiess es."
Nur wozu eine Tv Software die nicht funktioniert.

Genau, da frage ich mich nämlich im Nachhinein auch, weshalb AlexWs Patches oft genug durch z.B. Obi wieder rausgeschmissen wurden. Oder weshalb es einen Kerliman-Branch gibt, oder weshalb mws Metallicas Änderungen wieder rausschmeißt...

Ich meine Head, was für mich Release ist.

Gruß
mash

Metallicas änderungen wurden 2 mal von mir reverted, weil sie in dem fall am problem vorbei gegangen sind. und GENAU DAS ist das problem.

ich will keinem zunahetreten, aber OHNE sich mal nen bischen mit der materie zu beschäftigen, _was_ da wirklich abgeht wird es eher schlimmer als besser. durch rumprobieren und "hallo, ich weiss zwar nicht wieso, aber das memleak ist weg" wird es nicht gelöst.

ich habe das mit metallica im irc diskutiert. er hat es danach verstanden, und auch gesagt, das er nach einer wirklichen lösung suchen will bzw. diese dann eincheckt.

das was reverted wurde, war zwar ein fix für ein memleak, aber es war nicht der Grund der es auslöst, sondern nur die folge eines anderen Problems.

gruss
mws

[Innuendo]

dafür müßtest du ja auch den sections deamon auf den changenotifier warten lassen, bis neutrino gestartet ist oder grad die gesammelten epg daten direkt wieder verändern. beides eher unpraktisch bei der cpu last.
ich finde eine /var/tuxbox/config/sectionsd.conf nicht so übel wie ihr - da ist beim start hourstocache, oldeventsare und max_events vorhanden. was noch fehlt ist ein notifier für die letzten beiden parameter.

bevor wieder einer konfigdschungel anführt ... es sind ja optionale einstellungen. niemand muss die verändern.

innu

[petgun]

Nach 63 Stunden ist %MEM fuer sectionsd auf 23,1% und bei neutrino auf 13,9% gestiegen. Tendenz bei beiden Prozessen stetig steigend....dh. langfristig wird das auch crashen...ein Kaltstart/Woche sollte aber reichen das zu verhindern wenn die Werte in der Geschwindigkeit weiter steigen.

[T-Tron]

Kille doch einfach die Sectionsd, wenn die Box in den Standby geht, dann hast du gar keine Probleme. beim WakeUp startest du sie neu.
Ich habe noch eine Freememkontrolle eingebaut, wenn <5000kb, dann Restart. Hart aber herzlich

[petgun]

...gute Idee...an den Werten fuer neutrino wird das aber nix aendern..

[Innuendo]

das was reverted wurde, war zwar ein fix für ein memleak, aber es war nicht der Grund der es auslöst, sondern nur die folge eines anderen Problems.

da würde man sich doch wünschen, dass derjenige mit ahnung von der materie, das problem angeht, wenn er die ursache schon gefunden hat.

[mash4077]

...ich will keinem zunahetreten, aber OHNE sich mal nen bischen mit der materie zu beschäftigen, _was_ da wirklich abgeht wird es eher schlimmer als besser. durch rumprobieren und "hallo, ich weiss zwar nicht wieso, aber das memleak ist weg" wird es nicht gelöst...

Da bin ich zu 100% bei dir! Und genau darum ging es auch die ganze Zeit. Einfach zu sagen, dass Head nun mal per Definition Head ist und damit eingecheckt werden kann was der Teufel will, kann nicht sein und so wurde in der Vergangenheit auch nie verfahren. Aber für bestimmte Teile des Codes (z.B. Treiber) fühlten sich in der Vergangenheit die entsprechenden Entwickler "verantwortlich" und für den sectionsd tut das wohl niemand.

Aber einige Egoisten, die die Anregung (von mir aus auch Kritik) von Innuendo, dass z.B. ein extra Branch vielleicht die optimalere Vorgehensweise beim Einchecken der Änderungen/Erweiterungen gewesen wäre, hatten ja gleich das P in den Augen stehen, weil sie Angst um ihren Profit hatten. Zum Glück hatte sich Nirvana offensichtlich nämlich nicht auf den Schlips getreten gefühlt, da er mal abgesehen davon ja bisher auch gar nichts eingecheckt hat. *SCNR*

Aber noch mal zurück, die letzte Version des sectionsd von Nirvana ist deutlich stabiler als die, die zurzeit im CVS ist. Nachdem das Kind jetzt schon in den Brunnen gefallen ist, wäre es sicher sinnvoll diese Version auch einzuchecken.

Gruß
mash

[petgun]

..die letzte Version des sectionsd von Nirvana ist deutlich stabiler als die, die zurzeit im CVS ist. Nachdem das Kind jetzt schon in den Brunnen gefallen ist, wäre es sicher sinnvoll diese Version auch einzuchecken.

*unterschreib*

[Nirvana]

Mal gesetzt den Fall, die aktuelle Version sei stabiler und fräße weniger Speicher - gehen wir mal optimistischerweise davon aus: Aber warum ist sie das? Ich behaupte mal, wegen der Eventschranke und der weggelassenen Table6X Scannerei.
Und nun kommt der wirklich interessante Punkt: Das gab es früher nicht. Warum waren denn die Versionen damals stabil?

Möglichkeit 1: Weil die Rahmenbedingungen sich geändert haben. (RadioTP)
Möglichkeit 2: Es lag an etwas ganz anderem als dem sectionsd - Code. (Gesteigerter Speicherbedarf anderer Apps...)

In beiden Fällen, wären unsere Änderungen am CVS irrelevant gewesen. Also waren wir schon die ganze Zeit auf der richtigen Spur? Vielleicht erscheint euch der Eincheckvorgang mal aus dieser Warte betrachtet in einem "logischrem, vernünftigerem" Licht und die Diskussion hätte sich möglicherweise auch erübrigt...

[Metallica]

"CVS ist ein Entwicklerbranch der nicht funktionieren muss hiess es."
Nur wozu eine Tv Software die nicht funktioniert.

Genau, da frage ich mich nämlich im Nachhinein auch, weshalb AlexWs Patches oft genug durch z.B. Obi wieder rausgeschmissen wurden. Oder weshalb es einen Kerliman-Branch gibt, oder weshalb mws Metallicas Änderungen wieder rausschmeißt...

Ich meine Head, was für mich Release ist.

Gruß
mash

Metallicas änderungen wurden 2 mal von mir reverted, weil sie in dem fall am problem vorbei gegangen sind. und GENAU DAS ist das problem.

ich will keinem zunahetreten, aber OHNE sich mal nen bischen mit der materie zu beschäftigen, _was_ da wirklich abgeht wird es eher schlimmer als besser. durch rumprobieren und "hallo, ich weiss zwar nicht wieso, aber das memleak ist weg" wird es nicht gelöst.

ich habe das mit metallica im irc diskutiert. er hat es danach verstanden, und auch gesagt, das er nach einer wirklichen lösung suchen will bzw. diese dann eincheckt.

das was reverted wurde, war zwar ein fix für ein memleak, aber es war nicht der Grund der es auslöst, sondern nur die folge eines anderen Problems.

gruss
mws

Nur weil ich die Bugs fixen will , die schon ewig in Neutrino drin sind , wird hier so getan , als ich die Bugs produzieren würde.

[Torsten73]

@Nirvana:
da könntest Du durchaus Recht haben. Wir haben gestern abend zum Beispiel den Movieplayer benutzt. vorher waren 8MB frei, bis heute morgen hat sich der Freemem nicht erholt, er liegt weiterhin bei 700KB. Der Cache ist bei 12000 und Buffers irgendwo bei 200 nur noch!
Der Sectionsd ist daran nicht schuld, dessen Speicherbedarf lag weiterhin bei ca. 5400KB. Abgestürzt ist Sie nach 18h Nutzung dann aber noch nicht.

Auch wenn Petgun meint, bei Ihm würde der MovieplayerSpeicher wieder freigegeben werden, können das andere auch mal ausprobieren?

Wie heißt eigentlich der Movieplayer Prozess? Im Top müßte der doch angezeigt werden, aber sehen kann ich dort nichts davon.

@TTron:
Den Sectionsd ständig zu killen ist wohl auch kein eleganter Weg und äußerst unpraktisch. das ständige neusammeln der EPG es nerft dann doch ein wenig.

Cu
Torsten

[petgun]

Wie heißt eigentlich der Movieplayer Prozess? Im Top müßte der doch angezeigt werden, aber sehen kann ich dort nichts davon.

..ist in neutrino integriert...dh. CPU-Last und %MEM von neutrino steigt waehrend der Benutzung des Movieplayers.
Diese 'free'-Anzeige halte ich immer noch nicht fuer sehr aussagekraeftig...im Gegensatz zu %MEM der einzelnen Prozesse.

[petgun]

Nur weil ich die Bugs fixen will , die schon ewig in Neutrino drin sind , wird hier so getan , als ich die Bugs produzieren würde.

?? fest steht fuer mich, dass es nur durch die neuen Features/Fixes in Verbindung mit sectionsd zu der momentan fehlenden Langzeitstabilitaet gekommen ist. Und wie das hier ablaeuft/abgelaufen ist, macht das keinen gezielten/koordinierten Eindruck auf den normalen User, der die Qualitaet/Ausfuehrung der hier imo oft unnoetig diskutierten Aenderungen nicht beurteilen kann.
Ich faend's besser wenn die Entwickler zumindest die Kritik an altem/neuen Code hinter den Kulissen ausdiskutieren wuerden und unter sich einig werden, was/wie/wann eingecheckt/geaendert/verworfen wird.

[Torsten73]

@Petgun:
aha, dann werde ich mir mal den Neutrino %mem ansehen. Übrigens betrachte ich mittlerweile nicht nur den % Mem sondern links in der Spalte sieht man die Größe im Speicher in KB. Ich denke der Wert ist noch eindeutiger, denn ja nachdem welche Plugins installiert sind oder andere aktiven Threads ist der % wert ja auch nur relativ genau. In KB ist der aber auf den Boxen wahrscheinlich immer annähernd gleich groß.

Ab wo werden den Buffers und Cache eigentlich Kritisch. Gibt es da Infos zu?

Cu
Torsten

[petgun]

aha, dann werde ich mir mal den Neutrino %mem ansehen. Übrigens betrachte ich mittlerweile nicht nur den % Mem sondern links in der Spalte sieht man die Größe im Speicher in KB.

..das ist doch nur noch Dreisatz....und wenn wir hier diese Werte angeben, muessten wir eigentlich noch angeben wieviel Ram die Box hat auf der diese Werte gemessen wurden....16/32/64MB. Wenn man nix angibt gehen wohl die meisten von 32MB aus...ich zumindest.

[Metallica]

Nur weil ich die Bugs fixen will , die schon ewig in Neutrino drin sind , wird hier so getan , als ich die Bugs produzieren würde.

?? fest steht fuer mich, dass es nur durch die neuen Features/Fixes in Verbindung mit sectionsd zu der momentan fehlenden Langzeitstabilitaet gekommen ist.

Ich habe an sectionsd nix gemacht.

[InTheCliringSt&sTheDB]

Mal gesetzt den Fall, die aktuelle Version sei stabiler und fräße weniger Speicher - gehen wir mal optimistischerweise davon aus: Aber warum ist sie das? Ich behaupte mal, wegen der Eventschranke und der weggelassenen Table6X Scannerei.
Und nun kommt der wirklich interessante Punkt: Das gab es früher nicht. Warum waren denn die Versionen damals stabil?

Möglichkeit 1: Weil die Rahmenbedingungen sich geändert haben. (RadioTP)
Möglichkeit 2: Es lag an etwas ganz anderem als dem sectionsd - Code. (Gesteigerter Speicherbedarf anderer Apps...)

In beiden Fällen, wären unsere Änderungen am CVS irrelevant gewesen. Also waren wir schon die ganze Zeit auf der richtigen Spur? Vielleicht erscheint euch der Eincheckvorgang mal aus dieser Warte betrachtet in einem "logischrem, vernünftigerem" Licht und die Diskussion hätte sich möglicherweise auch erübrigt...

Ich denke, dass die Probleme im sectionsd schon immer bestanden, deswegen auch die "vielen" Freiwilligen, die sich damit beschäftigt haben. Eskaliert ist die Problematik erst mit Houdinis Dokukanal-Fix, der wie ich schon in diesem Thread geschrieben habe, den Initial-Speicher bei mir mehr als verdoppelt hat, auch die Zunahme war dann deutlich schneller. Dieser Fix ist dahin geändert worden, dass der Speicherverbrauch wesentlich moderater geworden ist. Die Problemgrenze des sectionsd wird nicht mehr so schnell erreicht.

Trotzdem gibt es gerade was das Thema Speicherverwaltung angeht scheinbar noch einige andere offene Baustellen, da stimme ich mal petgun zu, ein immer höher werdender Speicherverbrauch bei neutrino deutet darauf hin und der Movieplayer hat auch schon immer mal unsauber beendet. Generell scheint die Freigabe von benutztem Speicher nicht immer richtig zu funktionieren, ist mir auch über Telnet häufiger aufgefallen.

Wichtig wäre nun, die Probleme richtig einzuordnen. MM ist ein Movieplayer da weniger dramatisch als ständig laufende Prozesse wie der sections Dämon oder neutrino.

[Homar]

also der sectionsd-code wird im Hintergrund systematisch angegangen.

Der sectionsd hat memleaks ohne ende (gehabt), die dadurch entstanden sind, weil hier "unbenutzer Code" deaktiviert wurde und dadurch die entsprechenden logischen Abläufe nicht mehr verständlich waren; sind die schon nie gewesen.

Einge sachen waren da, die in der Vergangenheit völlig unlogisch angelegt waren und nur durch den Code-Progger verständlich waren.

Zum Beispiel:
Wenn mann die Funktion dmx.getSection(bla) aufruft, kriegt man einen Pointer zurück, die in dmx.cpp alokiert wurde.
Nun muss mann in sectionsd.cpp den inhalt des pointer deleten, wenn es nicht mehr gebraucht wird

... und es nicht das einzige...

Seit dem "Spielstop" versuche ich die undurchsichtigen Bereiche zu entflechten. Ergebniss sieht recht gut aus.

Durch probieren, hier und da, wird das nichts und ich schliesse mich der Meinung von mws an.

CVS ist gut zum gemeinsamen entwickeln, aber eine Spielwiese ist es sicherlich nicht !!!

Wenn ich einen Bereich programmiere oder verändere, dann muss mann mir die Zeit geben es zu vervollständigen.

es hat doch keinen Sinn, das Nirvana den Code erweitert, Metalica jede Änderung eincheckt, parallel Houdini Code verändert um memleaks zu stopfen (also die Basis verändert, auf der Nirvana arbeitet) und andere Patches reinsetzten, die wiederum andere Vorschlagen.

Wie, also im gottes Namen, soll Nirvana den Überblick behalten, über dessen was er tut ???


Als ob das noch nicht ausreicht, werde ich zum Buh-Mann ausgerufen ???


Nix da

Der Spielstop gilt so lange, bis der Code umgeschrieben ist.
Vorher konnten wir es machen und mitlerweile muss mann es machen !

Wir wollen alle wieder eine stabile soft haben und dann müssen wir uns an die Regeln halten.

Ich mache die memleaks weg, in der zwischenzeit coded Nirvana an seinen Änderungen.
Zum schluss müssen wir gegenseitig angleichen un dann wird es eingecheckt, und nur dann !!!

achja, noch was an die drängler: Keep cool and drink a cup of tea...

MFG
gestresster Homar

[PauleFoul]

Also ich hab mal die letzten diff von Nirvana getestet.

1. Speicherverbrauch steigt nicht mehr an. Auch noch zappen auf ARD, ZDF und Premiere mit jeweils 1 Stunde auf den Sendern verweilen sind
immer noch 8MB frei

2. Tuxtxt aktiviert. Schnappt sich 2MB Speicher. Tuxtxt beendet... Speicher ist immer noch weg (nur noch 6MB frei)

3. Box auf ARD über Nacht stehen lassen. Heute 16.00 Uhr nach Hause gekommen. Box hängt. Telnet geht net. Uhrzeit steht auf 12.14 Uhr. Die Box hat also immerhin 13 Stunden durchgehalten...


Gruß
____Paule

Irgendetwas stimmt mit der Speicherverwaltung net!

[zexma]

Kille doch einfach die Sectionsd, wenn die Box in den Standby geht, dann hast du gar keine Probleme. beim WakeUp startest du sie neu.
Ich habe noch eine Freememkontrolle eingebaut, wenn <5000kb, dann Restart. Hart aber herzlich

das ist doch wieder nur noch mehr script-gehuddel und allenfalls ein schlechter würg-around...

ich faend's besser wenn die Entwickler zumindest die Kritik an
altem/neuen Code hinter den Kulissen ausdiskutieren wuerden und unter sich einig werden, was/wie/wann eingecheckt/geaendert/verworfen wird.

Und ich fänd's besser, wenn hier die ENTWICKLER eine fachbezogene(!) Diskussion führen dürften, ohne das gewisse Leute ständig durch OT-Geposte und nicht reproduzierbare Beobachtungen die Threads ständig auf >= 8 Seiten ziehen und somit unleserlich und unübersichbar werden und in keinerweise der Problembehebung dienlich sind.
Und somit hat das zur Folge, was homar mit

also der sectionsd-code wird im Hintergrund systematisch angegangen

schon bestätigt hat. Die Know-How Vermittlung findet also nur noch NP statt.

Nur weil ich die Bugs fixen will, die schon ewig in Neutrino drin sind, wird hier so getan, als ob ich die Bugs produzieren würde.

Das wiederum ist falsch. Wer sich schon ein Weilchen mit Neutrino beschäftigt hat weiß, dass die Mem-Probleme schon sehr lange existieren.
Und das sowohl bei neutrino/movieplayer als auch beim sectionsd.
Auch wenn das hier von einigen vehement abgestritten wird...

das die bugs nun stärker zutage treten liegt doch nur daran, das hier nun diverse Faktoren zusammenkommen die das Fass eben für jederman sichbar zum überlaufen bringen.
Von Vorwürfen DARF daher keine Rede sein.

[zexma]

Kille doch einfach die Sectionsd, wenn die Box in den Standby geht, dann hast du gar keine Probleme. beim WakeUp startest du sie neu.
Ich habe noch eine Freememkontrolle eingebaut, wenn <5000kb, dann Restart. Hart aber herzlich

das ist doch wieder nur noch mehr script-gehuddel und allenfalls ein schlechter würg-around...

ich faend's besser wenn die Entwickler zumindest die Kritik an
altem/neuen Code hinter den Kulissen ausdiskutieren wuerden und unter sich einig werden, was/wie/wann eingecheckt/geaendert/verworfen wird.

Und ich fänds besser, wenn hier die ENTWICKLER eine fachbezogene(!) Diskussion führen dürften, ohne das gewisse Leute ständig durch OT-Geposte und nicht reproduzierbare Beobachtungen die threads ständig auf >= 8 Seiten ziehen und somit unleserlich, unübersichbar werden und in keiner weise der Problembehebung dienlich sind.
Und somit hat das zur Folge, was homar mit

also der sectionsd-code wird im Hintergrund systematisch angegangen

schon bestätigt hat. Die Know-How Vermittlung findet also nur noch NP statt.

Nur weil ich die Bugs fixen will, die schon ewig in Neutrino drin sind, wird hier so getan, als ob ich die Bugs produzieren würde.

Das wiederum ist falsch. Wer sich schon ein Weilchen mit neutrino beschäftigt hat weiß, dass die Mem-Probleme schon sehr lange existieren.
Und das sowohl bei neutrino/movieplayer als auch beim sectionsd.
Auch wenn das hier von einigen vehement abgestritten wird...

das die bugs nun stärker zutage treten leigt doch nur daran, das hier nun diverse Faktoren zusammenkommen die das Faß eben für jederman sichbar zum überlaufen bringen.
Von Vorwürfen DARF daher keine Rede sein.