Sectionsd zieht das System runter

flasher
Developer
Beiträge: 467
Registriert: Dienstag 15. Juli 2003, 10:58

Sectionsd zieht das System runter

Beitrag von flasher »

Hi

Ich habe mir mal wieder ein Image gemacht. CVS Stand 11.12.07.
Kann es sein, dass sich die Änderungen am SectionsD extrem Negativ auf die Permormance auswirken?

Bei mir sieht es fasst permanent so aus:

Code: Alles auswählen

Mem: 28784K used, 2100K free, 0K shrd, 2676K buff, 8580K cached
CPU:  73% usr  24% sys   2% nice   0% idle   0% io   0% irq   0% softirq
Load average: 0.47 0.50 0.31
  PID  PPID USER     STAT   VSZ %MEM %CPU COMMAND
  184   182 root     R    38616 125%  93% sectionsd
  572   228 root     S N  35948 116%   3% neutrino -f -u
Die 73% sind noch wenig. Dann ist mal wieder 2-3 Minuten Ruhe (1% CPU) und dann gehts wieder los.

Ich habe dann mal ein Image genommen welches ich vor der Änderung gemacht hatte und das läuft und läuft und läuft...

Gruß
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Also die einzige Änderung, von der ich mir vorstellen kann, daß sie was ausmacht, ist das aktivieren der auto-bouquets von Nirvana:

http://cvs.tuxbox-cvs.sourceforge.net/l ... 00138.html

Das ist eigentlich nur ein "if(debug) {... }", das entfernt wurde.
Wenn du das mit #if 0...#endif wieder deaktivierst, kannst du es ja einfach direkt vergleichen.

Alle anderen Sachen _sollten_ IMHO die performance eher verbessern als verschlechtern, aber man weiß ja nie...
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

das if(debug) kanns eigentlich nicht sein, wenn er keine mybouquets.xml hat
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Aber alles andere kann ich mir nicht erklären :-)

@flasher: hast du eine Revision / ein Datum, an dem es noch gut war?
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

ich denk es liegt an der malloc sache hier
http://cvs.tuxbox-cvs.sourceforge.net/c ... 2&r2=1.253
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Da kommt kein malloc drin vor :-) Und ich lehne mich jetzt mal aus dem Fenster und sage: Daran kann es nicht liegen.
Aber dieser Patch sollte sich einzeln reverten lassen, so daß flasher sagen kann, ob es einen Unterschied macht:

Code: Alles auswählen

seife@susi:/local/.../daemons/sectionsd> cvs diff -up -r1.253 -r1.252 > /tmp/delme
cvs diff: Diffing .
seife@susi:/local/.../daemons/sectionsd> patch < /tmp/delme
patching file sectionsd.cpp
Edit: @flasher: du verwendest aber schon noch kernel 2.4, oder?
flasher
Developer
Beiträge: 467
Registriert: Dienstag 15. Juli 2003, 10:58

Beitrag von flasher »

seife hat geschrieben:Aber alles andere kann ich mir nicht erklären :-)

@flasher: hast du eine Revision / ein Datum, an dem es noch gut war?
Hi

Zu Glück hatte ich gestern noch geschaut bevor ich das gelöscht hatte.
Die meiner Meinung nach noch funktionierende Revision war : Revision 1.250

Kurz zu den anderen Sachen:
1. Ich habe keine mybouquets.xml Lohnt sich irgendwie im Kabel nicht
2. Ja, es ist noch der 2.4er Kernel

Zum neu compilen und testen mit der Revision 1.250 werde ich aber heute nicht mehr kommen.

Gruß
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

In dem Fall kann es fast nur das aktivieren der auto-bouquets sein.
Mach doch mal in der jetztigen Version in Zeile 7260 ein
"#if 0" rein (zwichen "unlockEvents()" und "readLockServices()") und in füge Zeile 7321 mit "#endif" ein (nach "xmlFreeDoc(current_parser)" und vor dem auskommentierten Block).

Soweit ich das sehen kann, wird das auch aktiv und kann durchaus Rechenzeit verbraten, wenn keine mybouquets.xml da ist. Das ist dann zwar vermutlich reichlich nutzlos, aber das stört den Code erstmal nicht ;-)

Edit: das mit dem 2.6er habe ich gefragt, weil der 2.6er kernel bugs im sectionsd triggert, die bisher nicht aufgefallen sind, z.B. das extrem seltsame benutzen von SCHED_RR, das auf 2.4 ein noop zu sein scheint, aber auf 2.6 nicht...
flasher
Developer
Beiträge: 467
Registriert: Dienstag 15. Juli 2003, 10:58

Beitrag von flasher »

Hi

So mit diesen Änderungen habe ich keine Veränderung festgestellt.
Was halt auffällt ist, dass die Auslastung immer nur kurzzeitig in die Höhe geht.
Da ich mich mit dem sectionsd überhaupt nicht auskenne frage ich mich natürlich was versucht diesen Load?

Wenn man die Situation etwas länger beobachtet, dann stellt man fest, dass die CPU Load ca. 10-20 Sekunden anhällt und dann für einige Minuten wieder Ruhe herrscht.

Prüft sectionsd periodisch die EPG Daten und verbraucht desshalb soviel CPU?

Im ersten Post hatte ich geschrieben, dass dies mit einem andere älteren Image läuft. Ich muss gestehen, dass ich nicht allzu lange getestet hatte.
Wenn ich mit einem alten Image schaue dann tritt das auch auf.

Vieleicht war ich auch nur über die 93% erschrocken?
Bisher ist es ja scheinbar auch keinem anderen aufgefallen bzw. verursacht es wohl keinen Performanceverlust wenn man nicht gerade ein Powerzapper ist.

Gruß
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Weil das EIT-Update total kaputt ist (seit längerem), wacht der sectionsd nach 300sek unnötigerweise auf, checkt wieder alle EIT Tabellen ab, obwohl sich nichts geändert hat und geht danach noch die NIT und SDT durch (das geht aber flott). Die EIT dauert maximal 5 minuten (5 filter, mit 1min. timeout), aber meistens weniger, da er schon vorher merkt, daß nix neues mehr kommt. Danacht geht der EIT-Thread für 5*60 (TIME_EIT_SCHEDULED_PAUSE) sekunden schlafen, die NIT und SDT-Threads werden geweckt.

Der Housekeeping-Thread läuft auch noch irgendwann periodisch, vermutlich ebenfalls alle HOUSEKEEPING_SLEEP (5 * 60) sekunden. Der scheint nicht soo dramatisch zu sein, und außerdem hast du das, was darin kürzlich eingeschaltet wurde, ja erfolglos ausge #if 0'ed.

Kurz: ich bin froh, daß das schon mit dem älteren sectionsd so war, weil ich es dan nicht kaputtgemacht habe.
Aber vor Weihnachten noch werde ich es evtl. ganz machen (oder wenigstens wesentlich verbessern), in dem ich das EIT update fixe. Das letzte Problem, das ich damit hatte, scheine ich letztes Wochenende gefunden zu haben, es kann also so langsam mal losgehen :-))
Striper
Erleuchteter
Erleuchteter
Beiträge: 625
Registriert: Samstag 8. September 2007, 16:17

Beitrag von Striper »

seife hat geschrieben: Das letzte Problem, das ich damit hatte, scheine ich letztes Wochenende gefunden zu haben, es kann also so langsam mal losgehen :-))
Ich hoffe das ist nicht dein try4 den du da einchecken willst. Denn der bringt tlw. meine ganze Box ins straucheln. Hatte den mal vor ein paar Tagen gepatcht und kompiliert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Dieses Wochenende gibts erst mal einen bugfix, und dann einen neuen Versuch, damit das noch getestet werden kann.

Wie sehen die Probleme denn aus? "?" drücken und es dauert >10 sek. bis die Infobar erscheint? Kernel 2.4 oder 2.6?
Striper
Erleuchteter
Erleuchteter
Beiträge: 625
Registriert: Samstag 8. September 2007, 16:17

Beitrag von Striper »

Kernel 2.4. Irgendwas hängt sich komplett weg. Erst kam keine Infobar (ähnlich wie du es beschreibst) und dann konnte ich umschalten und hatte überall nur noch: "Kanal nicht verfügbar". Nur ein Neustart hat dann noch geholfen. Box ist eine Nokia Kabel mit 500er.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Ok, das scheint ein Bug zu sein, der schon länger da ist, aber durch meine "Verbesserungen" öfters getriggert wird. Bisher dachte ich, daß der auf 2.6 beschränkt wäre, weil das threading in 2.4 anders ist, aber es beruhigt mich fast, daß es dort auch auftritt.

Kurz gesagt: es ist eine doofe Idee, ein paar thread mit realtime-attributen zu erzeugen (SCHED_RR), und dann zu erwarten, daß mutex locking noch irgendwie "fair" ist => der connection-thread (bzw. die mainloop), der mit der GUI kommuniziert, bekommt für eine lange Zeit den Lock (DMX::lock()) nicht, den er zum Zugreifen auf die Daten braucht, weil der EIT thread eine höhere priorität hat.

Der Fix ist bei mir im Kopf schon fertig, ich will ihn aber heute abend zuhause erst mal probelaufen lassen, vor ich ihn committe.

Daß das auf 2.4 so selten auftritt ist entweder ein implementation detail im 2.4er threading, oder ein bug :-), daß es auch selten auf der dbox (=>2.4) auftritt haben wir irgendwann im "neutrino auf dreambox"-thread und einem alten sectionsd-Thread festgestellt, aber keiner konnte es sich erklären, und es war eben auch sehr selten.
Mein Patch triggert das nun öfters.

Langes Posting, kurzer Sinn: Alles wird gut.
:-)
Striper
Erleuchteter
Erleuchteter
Beiträge: 625
Registriert: Samstag 8. September 2007, 16:17

Beitrag von Striper »

Hab zwar die Hälfte nicht verstanden, aber -> Juhuuu! :wink:
ThulsaDoom
Interessierter
Interessierter
Beiträge: 86
Registriert: Montag 18. Dezember 2006, 10:28

Beitrag von ThulsaDoom »

Striper hat geschrieben:Hab zwar die Hälfte nicht verstanden, aber -> Juhuuu! :wink:
Woah, die Hälfte sind immerhin 50% mehr, als ich verstanden habe ! :P
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Nun ja, ich dachte halt, im "Developers"-Forum dürfte es ruhig mal etwas technischer werden ;-)

Egal.
sectionsd-1255-fix_eitupdate-try5.diff ist gegen den aktuellen sectionsd aus dem CVS und funktioniert bei mir. Solange sich die EIT nicht ändert, sollte der sectionsd (abgesehen vom housekeeping-Thread) nur noch jede Halbe Stunde aufwachen (könnte man auch noch wesentlich verlängern), was flashers Problem wesentlich entschärfen sollte, Stripers Bug ist mir nicht ganz klar (so hart, mit "Kanal nicht verfügbar", also zapit gecrashed oder ähnliches hatte ich das nie), aber ich hoffe daß er im Zusammenhang mit dem Thread-Priority-fix/hack im CVS aber auch verschwunden ist.
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

seife ?
kannste mal guggen, warum ab seit version 1.255 der beim ausgelagerten epgdaten einlesen beim start so lange wartet bis der fertig ist ? bei der 1.254 klappts noch.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Das hatte Riker auch schon mal erwähnt, ich kann es aber nicht reproduzieren.

Versuche mal, in sectionsd.cpp diese 3 Zeilen in commandReadSIfromXML():

Code: Alles auswählen

        writeLockMessaging();
        epg_dir = (std::string)data;
        unlockMessaging();
um 4 Zeilen nach hinten zu verschieben (also hinter das "writeNbytes()").

Edit: BTW, EPG-Daten speichern ist eh doof ;-))
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

nö bringt garnichts.
hängt beim epgeinlesen.
vielleicht ist es auch die dmx.cpp änderung mit ?
ich kann dir auch gern ein diff machen mit den unterschieden der beiden dateien.
Zuletzt geändert von mb405 am Sonntag 30. Dezember 2007, 11:58, insgesamt 1-mal geändert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

glaube ich nicht.
Sorry, das muß mal jemand debuggen, wo es genau hängt. Ich kann es nicht, da es bei mir nicht auftritt.

Was hängt denn genau? Nur sectionsd oder kommt bei dir auch kein Bild, bis das fertig ist?

Edit: in dmx.cpp ist es ja nur das "sched_yield();", kommentier das halt mal aus.
mb405
Tuxboxer
Tuxboxer
Beiträge: 2331
Registriert: Donnerstag 24. März 2005, 21:52

Beitrag von mb405 »

neutrino wartet beim booten an der stelle das aufrufs bis der sectionsd sagt enlesen fertig. dann macht neutrino weiter.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Beitrag von seife »

Genau das sollte aber, wenn du die 3 Zeilen verschiebst, nicht mehr vorkommen können (weil sectionsd sofort sagt "ok, fertig", auch wenn er noch gar nichts gemacht hat).
Also müßtest du an dieser stelle dort mal debug-Code mit Timing-Informationen reinmachen, damit wir sehen, an welcher Stelle es genau hängt. (Kommentare jeweils hinter dem Code)

Code: Alles auswählen

4264 static void commandReadSIfromXML(int connfd, char *data, const unsigned dataLength)
4265 {
4266         pthread_t thrInsert;
4267
4268         if (dataLength > 100)
4269                 return ;
4270
4271         writeLockMessaging();
====== Hier könnte es hängen =======
4272         epg_dir = (std::string)data;
4273         unlockMessaging();
4274
4275         struct sectionsd::msgResponseHeader responseHeader;
4276         responseHeader.dataLength = 0;
4277         writeNbytes(connfd, (const char *)&responseHeader, sizeof(responseHeader), WRITE_TIMEOUT_IN_SECONDS);
====== Ab hier sollte neutrino weitermachen ======
4278
4279         pthread_attr_t attr;
4280         pthread_attr_init(&attr);
4281         pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
4282
4283         struct sched_param param;
4284         pthread_attr_setschedpolicy(&attr, SCHED_RR);
4285         param.sched_priority=-10;
4286         pthread_attr_setschedparam(&attr, &param);
====== Diese 4 Zeilen sind absolut falsch, evtl. hilft es ja, die zu entfernen (SCHED_RR mit priority<1 geht nicht) ====
4287
4288         if (pthread_create (&thrInsert, &attr, insertEventsfromFile, 0 ))
====== Erst hier wird die Funktion zum einlesen gestartet ===
In die insertEventsfromFile()-Funktion (ab Zeile 4110) solltest du auch debug-Output reinmachen, damit du siehst, wann die tatsächlich aufgerufen wird. Ich vermute mal, die wird erst dann aufgerufen, wenn Neutrino schon weiterläuft.