Stiftung: Stabiler sectionsd

Beitrag von **petb** » Donnerstag 8. Dezember 2005, 17:08

dietmarw hat geschrieben:und was war hiermit??
Günther:
Weiterhin ist mir aufgefallen, daß ganz schon auf dem heap rumgeorgelt wird (mallocs). Ich weiss ja nicht wie das bei Linux ist, aber Speicherfragmentierungen sind ansonsten die größten Probleme bei embedded C++Projekten (nicht ohne Grund sind malloc in der embedded Welt oft verboten). Das könnte auch der Grund sein, warum die Boxen nach Stunden oder Tagen abschmieren.
http://forum.tuxbox-cvs.sourceforge.net ... &start=380
ich bin ja kein coder, aber könnte man da nicht testweise andere methoden anwenden?

Würde mich auch interessieren.
Und ich hatte heute wieder nen Hänger mit Boxneustart.
Freier Speicher geht immer wieder runter auf unter 1 MB und dann klemmts.

Der Gedankengang von Günther scheint mir sehr vielversprechend zu sein.
Ich weis von früher auch noch das es mit malloc und dann später wieder freigeben usw. nicht nur das Problem gibt, wird überhaupt alles wieder freigegben....
Sondern auch die Defragmentierung der ganzen Geschichte kann problematisch werden.
Und wenn dann wie wild in den allozierten bereichen hantiert wird, erwischt es schnell einen noch aktiv genutzten usw...
Aber wie immer, was red ich, ich bin eh nicht mehr up to date was das alles angeht

Auch wenns schwer fällt:
Vor einiger Zeit meinte mal jemand wie wäre es denn den ganzen sectionsd neu aufzusetzen ?
ich weis es tut weh eine bereits gemachte Arbeit wegzuwerfen, aber wenn der Fehler nicht debugt werden kann .....
Wäre toll wenn ihr Devs das mal in Erwägung ziehen würdet.

Und so nebenbei, kommen dauernd Debugmeldungen vom sectionsd das er Transponder findet usw. und da obwohl der sections scan auf aus steht.

Ich wundere mich sowieso warum der sectionsd dauernd so 80% CPU Last macht, wenn er doch seine Daten hat.
War das vor dem Umbau auch so ?
Bye
PetB

@Dietmarw
Günther hat vollkommen recht, aber ohne ein grundsätzliches Refacturing geht da nix.
Ich hatte ja vor einiger Zeit schon einiges an unnötigen mallocs/frees rausgeworfen.
Nirvana hat ja auch oben den Ansatz die Events nur auszutauschen, wenn sie sich geändert haben. Ich habe bei mir einen ähnlichen Ansatz, da wird die Versionsnummer des events mit abgespeichert und nur wenn sich diese ändert, folgt das add_event(). Aber es hat sich gezeit, dass die Versionsnummern der events sich ändern können(z.B gleiche Events auf dem Pro7/Sat1 und den Premiere Transponder haben gleiche IDs aber andere Versionsnummern)
Aber ich sehe das aber auch als guten Ansatzpunkt.
Dazu sollte mal ein DVB-Spezi was sagen (rasc?)

Houdni

Auslagern geht ja schlecht,

Ich meine ja, irgendwo schon mal ne Begründung gelesen zu haben, aber kanns nochmal jmd erklären? Ansonsten wärs ja ideal, die EPG-Daten auf den NFS-Server zu schreiben. Wäre evtl. in der Kombi mit JtG auch ganz interessant, wenn die Daten schon auf dem PC liegen. Und das ganze wenn möglich als Option, damit diejenigen, die über Scart auf Bandlaufwerk aufzeichnen nicht wehklagen.

Was ich herausgefunden habe ist, dass alleine ca. 50% für die Verwaltung der Events verbraucht wird (std::set, std::map) - auch wenn man alle events nachher löscht bleibt der maximalstand der maps bestehen.

Houdini

Es ist aber nach einem killall sectionsd der Speicher wieder frei. Vielleicht sollte man so etwas alle 24h machen, solange bis der sectionsdspeicherbedarf nicht mehr von alleine zunimmt

(Das war ein Witz...)

1. Warum löscht der Sectionsd nicht die alten Events (daraus resultiert der wachsende Speicherbedarf) ?

zu 1:
macht er doch (ok mit meinem letzten Patch gibts da ein Problem...)

Wenn ichs richtig verstehe wird daran also bereits gearbeitet...

Hast Du denn eine Erklärung, warum während des EPGscannens bei einem Freemem unter 4,5MB nach dem Einlesen der Freemem auf 4,5MB von <2,8MB wieder zurückspringt? Denn das passiert erst wenn der Speicher auf unter 4,5MB geht! Wenn man nur z.b. ARD einliest, bleibt der Wert ja konstant.
Das scheint eine Art Grenze zu sein, bei dessen Unterschreitung wieder der Speicher geleert wird, oder es gehen EPG Daten verloren...

Günters Heap Theorie habe ich ja auch schon mal angemerkt, habe nur nicht seinen Beitrag wiedergefunden gehabt. Aber das stellt dann natürlich ein schweres Stück Arbeit dar, und ob sich dafür jemand mit dem nötigen Knowhow findet ist fraglich, leider...

Cu
Torsten

InTheCliringSt&sTheDB hat geschrieben:
Auslagern geht ja schlecht,
Ich meine ja, irgendwo schon mal ne Begründung gelesen zu haben, aber kanns nochmal jmd erklären? Ansonsten wärs ja ideal, die EPG-Daten auf den NFS-Server zu schreiben. Wäre evtl. in der Kombi mit JtG auch ganz interessant, wenn die Daten schon auf dem PC liegen. Und das ganze wenn möglich als Option, damit diejenigen, die über Scart auf Bandlaufwerk aufzeichnen nicht wehklagen.

Abgesehen davon das das eine nette Funktion wäre, hilft es nicht den Absturz des Sectionsd zu verhindern. Und was machen die User die nicht im Netz sind? Das wäre lediglich optional etwas...

Da fällt mir noch ein, Riker hat mal testweise die EPG Vorschau auf 3 Tage begrenzt-> weniger Speicherbedarf, das hat zwar nur wenig gebracht, aber müssen es 7 Tage bei ARD & Co sein, wenn das so viel Speicher benötigt?

Cu
Torsten

Beitrag von **petb** » Donnerstag 8. Dezember 2005, 19:13

Torsten73 hat geschrieben:Da fällt mir noch ein, Riker hat mal testweise die EPG Vorschau auf 3 Tage begrenzt-> weniger Speicherbedarf, das hat zwar nur wenig gebracht, aber müssen es 7 Tage bei ARD & Co sein, wenn das so viel Speicher benötigt?
Cu
Torsten

Meine Meinung:
Ja, so viel wie möglich speichern.
ABER ich könnte darauf verzichten ALLE Sender zu speichern.
Zum programmieren etc. reicht es einen Sender zu bearbeiten und nur diesen bei Anforderung voll einzulesen.
Sonst z.B. für die EPG-Gesamtübersicht aller Sender kann es dagegen locker auf 1 Tag begrenzt werden.

Aber so unterhalten wir uns über ein Feature und nicht über eine Fehlerbeseitigung, die eigentlich vor einem Feature kommen sollte.
Es macht ja keinen Sinn, nur um Ram zu sparen, eben weniger einzulesen, wenn der sectionsd trotzdem muckt.

Wieso fragen wir nicht einfach Günter was er meint....ob er sich nicht der Sache annehmen kann bzw. möchte.

Hallo Günter, was meinst du denn dazu ?

Ich will damit jedoch nicht:
einen der aktuellen DEVs verprellen, ihm die Fähigkeit absprechen oder ihm seine Arbeit madig machen oder gar wegnehmen, wenn er sich der Neuprogrammierung annehmen will.

Ein Ertrinkender greift nach jedem Stück Holz das er kriegen kann

Bye
PetB

dietmarw hat geschrieben:und was war hiermit??

Günther:
Weiterhin ist mir aufgefallen, daß ganz schon auf dem heap rumgeorgelt wird (mallocs). Ich weiss ja nicht wie das bei Linux ist, aber Speicherfragmentierungen sind ansonsten die größten Probleme bei embedded C++Projekten (nicht ohne Grund sind malloc in der embedded Welt oft verboten). Das könnte auch der Grund sein, warum die Boxen nach Stunden oder Tagen abschmieren.
http://forum.tuxbox-cvs.sourceforge.net ... &start=380

ich bin ja kein coder, aber könnte man da nicht testweise andere methoden anwenden?

Ich hab mir sectionsd gebaut , wo alle "new char[]" weg waren. Speicher war trotzdem nach einem tag weg.

Ich hoffe, ich bin nicht im falschen thread:

Habe gestern mal neu ausgecheckt und ein Neutrino-jffs2 erstellt.
In der Programmvorschau werden nun "ß" als "C" dargestellt, Umlaute ergeben ein heilloses Zeichenwirrwarr!
Ansich läuft der sectionsd recht stabil (ich boote jeden Tag neu), aber das oben beschriebene ist mir unklar.
Der Fehler tritt auf allen Sendern auf.

Habt ihr ne Idee dazu?

Danke.

Gruß Boardgeist

Der EPG auf Premiere ist kaputt, das hat mal nix mit dem sectionsd zu tun.

DieMade hat geschrieben:Der EPG auf Premiere ist kaputt, das hat mal nix mit dem sectionsd zu tun.

Sorry, ich schrieb "alle Sender"--> ARD, RTL, etc.!

Überlesen, ich sag schon nix mehr

Boardgeist hat geschrieben:
DieMade hat geschrieben:Der EPG auf Premiere ist kaputt, das hat mal nix mit dem sectionsd zu tun.
Sorry, ich schrieb "alle Sender"--> ARD, RTL, etc.!

ARD , RTL wo ?
Sat1/Pro7 und PW schon.

Aber dann gilt

Der EPG auf Premiere ist kaputt, das hat mal nix mit dem sectionsd zu tun.

Beitrag von **Npq** » Donnerstag 8. Dezember 2005, 21:12

Malloc ist auf der dbox2 nicht so kritisch, da dort ein PowerPC werkelt, der eine MMU besitzt, das ist bei anderen embedded Systemen nicht immer der Fall. Somit besitzt jeder Prozeß einen eigenen Adreßraum und der Speicher wird virtuell dort eingeblendet.

Malloc und Konsorten werden "dicht" sein, was Günther meinte und was ein Problem speziell bei C++ darstellt, ist die Fragmentierung des Heaps.

Der Heap ist quasi der Speicher, über den jeder Prozeß verfügt, und der bei Bedarf auch vergrößert werden kann. Das geschieht allerdings vollkommen transparent.

Nun nimmt dieser Speicher über die Zeit hin natürlich zu, wenn immer mehr Objekte angelegt und gehalten werden. Hat man eine Auslagerungsdatei wie auf dem PC ist das nicht so kritisch, bei der dbox2 gibt es diese aber noch nicht (IDE-Projekt2

)

Wenn man immer nur kleine Mengen an Speicher allokiert (bei C++ geschieht das häufig durch die ganzen Klassenobjekte), dann passiert zum Beispiel so etwas:

3 Objekte:

Objekt A (120 byte)
Objekt B (30 Byte)
Objekt C (190 Byte)

jetzt wird B gelöscht

Objekt A (120 Byte)
freier Speicher von 30 Byte
Objekt C (190 Byte)

So, und wenn nun z.B. Objekt A und C "langlebige" Objekte sind und nur wenige Objekte mit dieser kleinen Menge von 30 Byte existieren, dann kann es sein, daß immer wieder kleine Lücken im Speicher auftreten, die nicht gefüllt werden können. (Diese Darstellung ist allerdings stark vereinfacht)

Die Lösung besteht darin, daß man die Speicherverwaltung selber übernimmt.

Das läuft aber im Grunde auf eine Neuimplementierung hinaus wie Houdini ja schon andeutete.

EPG ist nur auf Ex-Kirch Sendern kaputt.

http://s55.yousendit.com/d.aspx?id=3470 ... DPX913YAQG

Könnte jemand bitte mal testen, ob die Box mit dieser sectionsd.cpp noch langsam wird? Weil Memory auffressen bis auf 500k ist okay. Langsam werden und abstürzen ist nicht okay. Ich habe nochmal den sdt-thread modifiziert. nit spielt vorerst nicht mit, um besser zu testen. Ich verspreche mir davon ne ganze Menge. Wenn das Ding hier besser läuft mach ich auf der Basis weiter.

Beitrag von **petb** » Donnerstag 8. Dezember 2005, 22:13

Npq hat geschrieben:Wenn man immer nur kleine Mengen an Speicher allokiert (bei C++ geschieht das häufig durch die ganzen Klassenobjekte), dann passiert zum Beispiel so etwas:

3 Objekte:

Objekt A (120 byte)
Objekt B (30 Byte)
Objekt C (190 Byte)

jetzt wird B gelöscht

Objekt A (120 Byte)
freier Speicher von 30 Byte
Objekt C (190 Byte)

So, und wenn nun z.B. Objekt A und C "langlebige" Objekte sind und nur wenige Objekte mit dieser kleinen Menge von 30 Byte existieren, dann kann es sein, daß immer wieder kleine Lücken im Speicher auftreten, die nicht gefüllt werden können. (Diese Darstellung ist allerdings stark vereinfacht)

Die Lösung besteht darin, daß man die Speicherverwaltung selber übernimmt.

Das läuft aber im Grunde auf eine Neuimplementierung hinaus wie Houdini ja schon andeutete.

Perfekt, da lag ich also nicht so falsch mit meiner Erinnerung an die Garbage Collection usw.
Zu DOS Zeiten war das nämlich schon ein Problem, als es noch keine Memory Manger etc. gab. Da musste man sehr sparsam mit dem Speicher umgehen 640k sind schnell voll, wenn man mit strings um sich wirft. Auch wenn diese dann wieder frei gegeben wurden.
Fragmentiert ist fragmentiert. (Aber gab es da nicht Funktionen innerhalb der Sprache selbst die das irgendwie aufgeräumt haben

)

Aber egal, das wichtigste überhaupt ist, das an der Sache weiter gearbeitet wird und kein Stillstand eintritt.
Sonst säßen wir ganz schön der Tinte, mit einer nicht stabil laufenden Box.

In diesem Sinne sag ich auch nochmal Danke an alle die an den ganzen Sachen rund um die Box Hand anlegen.
Ich finde das echt klasse.

bye
PetB

so hier ist mein Patch, der einen Teil der Abstürze fixen sollte und wieder die "Stabilität" von vor 5.12.05 zurückbringen sollte.

Code: Alles auswählen

cvs: WARNING: Read-only repository access mode selected via `cvs -R'.
Using this option to access a repository which some users write to may
cause intermittent sandbox corruption.
Index: sectionsd.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/daemons/sectionsd/sectionsd.cpp,v
retrieving revision 1.213
diff -u -r1.213 sectionsd.cpp
--- a/sectionsd.cpp	8 Dec 2005 18:41:40 -0000	1.213
+++ b/sectionsd.cpp	8 Dec 2005 21:27:46 -0000
@@ -498,8 +498,8 @@
 	// Alte events loeschen
 	time_t zeit = time(NULL);
 
-	for (MySIeventsOrderFirstEndTimeServiceIDEventUniqueKey::iterator e = mySIeventsOrderFirstEndTimeServiceIDEventUniqueKey.begin(); 
-			e != mySIeventsOrderFirstEndTimeServiceIDEventUniqueKey.end(); e++) {
+	MySIeventsOrderFirstEndTimeServiceIDEventUniqueKey::iterator e = mySIeventsOrderFirstEndTimeServiceIDEventUniqueKey.begin();
+	while (e != mySIeventsOrderFirstEndTimeServiceIDEventUniqueKey.end()) {
 		goodtimefound = false;
 		for (SItimes::iterator t = (*e)->times.begin(); t != (*e)->times.end(); t++) {
 			if (t->startzeit + (long)t->dauer >= zeit - seconds) {
@@ -511,13 +511,19 @@
 		if (false == goodtimefound) {
 			// keep track of our iterator
 			etmp = e;
-			etmp--;
-			deleteEvent((*e)->uniqueKey());
+			if (etmp == mySIeventsOrderFirstEndTimeServiceIDEventUniqueKey.begin()) {
+				etmp++; // get next element
+				deleteEvent((*e)->uniqueKey());
+			} else {
+				etmp--; // get last element and iterate later
+				deleteEvent((*e)->uniqueKey());
+				etmp++;
+			}
 			e = etmp;
 		}
 		else
-			;// solange das nicht richtig funktioniert einfach bis zum ende suchen
-			// break; // sortiert nach Endzeit, daher weiteres Suchen unnoetig
+			e++;	// solange das nicht richtig funktioniert einfach bis zum ende suchen
+				// break; // sortiert nach Endzeit, daher weiteres Suchen unnoetig
 	}
 	return ;
 }

Beitrag von **petb** » Freitag 9. Dezember 2005, 03:46

Houdini hat geschrieben:so hier ist mein Patch, der einen Teil der Abstürze fixen sollte und wieder die "Stabilität" von vor 5.12.05 zurückbringen sollte.

Sei mir bitte nicht böse Houdini,...

Stabilität vor dem 5.12.05 ?
Wo war den da mal was stabil ?
Das muss man dann aber sehr relativ sehen.

Ich habe seit dem JTG Image vom 20.10.05 definitiv kein stabiles Image mehr gesehen.
Selbst das vom 04.10.05 das ich zur Zeit auf den Produktivboxen nutze lässt den sectionsd abschmieren wenn ich im EPG vom ZDF-Infokanal ein wenig aktiv werde.

Ich kenne kein Image das sauber funktioniert seit Oktober 05.
Wie es vorher war weis ich nicht genau.
bye
PetB

[/quote]

Beitrag von **Nirvana** » Freitag 9. Dezember 2005, 07:56

http://s42.yousendit.com/d.aspx?id=2GZJ ... 65RITBZJP2

Vielleicht testet ja der ein oder andere lieber das binary.

Beitrag von **Günther** » Freitag 9. Dezember 2005, 08:07

Npq hat geschrieben:Malloc und Konsorten werden "dicht" sein, was Günther meinte und was ein Problem speziell bei C++ darstellt, ist die Fragmentierung des Heaps.

Der Heap ist quasi der Speicher, über den jeder Prozeß verfügt, und der bei Bedarf auch vergrößert werden kann. Das geschieht allerdings vollkommen transparent.

Nun nimmt dieser Speicher über die Zeit hin natürlich zu, wenn immer mehr Objekte angelegt und gehalten werden. Hat man eine Auslagerungsdatei wie auf dem PC ist das nicht so kritisch, bei der dbox2 gibt es diese aber noch nicht (IDE-Projekt2 )

Wenn man immer nur kleine Mengen an Speicher allokiert (bei C++ geschieht das häufig durch die ganzen Klassenobjekte), dann passiert zum Beispiel so etwas:

3 Objekte:

Objekt A (120 byte)
Objekt B (30 Byte)
Objekt C (190 Byte)

jetzt wird B gelöscht

Objekt A (120 Byte)
freier Speicher von 30 Byte
Objekt C (190 Byte)

So, und wenn nun z.B. Objekt A und C "langlebige" Objekte sind und nur wenige Objekte mit dieser kleinen Menge von 30 Byte existieren, dann kann es sein, daß immer wieder kleine Lücken im Speicher auftreten, die nicht gefüllt werden können. (Diese Darstellung ist allerdings stark vereinfacht)

Die Lösung besteht darin, daß man die Speicherverwaltung selber übernimmt.

Das läuft aber im Grunde auf eine Neuimplementierung hinaus wie Houdini ja schon andeutete.

*Applaus* - hätte ich nicht besser erklären können

In der embedded Welt wird das auch gerne mit statischen Partitionen gelöst (e.g. 10*77byte, 17*876byte , usw). Nachteil hier ist allerdings der höhere Speicherbedarf, der Speicher steht auch bei Nichtgebrauch anderen Programmen nicht zur Verfügung. Dafür gibts hier keine Probleme mit der Langzeitstabilität .... (dafür müßte der sectionsd aber grundlegend neu designed werden ). Ich sehe das aber eher als ein Problem unter vielen an. Die Abstürze und der Speicherverbrauch habe sicher noch ganz andere Ursachen ...

Ansonsten sehe ich im Moment folgende Lösungen:
1) Weitermachen wie bisher und hoffen das unsere sectionsd Jungs den Fehlern finden.
2) Zurück zur letzten 'stabilen' Version gehen und von da - in development branches

- wieder neu aufbauen. Ich denke da an die Zeit vor dem Private EPG, also cvs vor 14. August 2005). - Falls es überhaupt jemals eine stabile Version gab
3) Wenn es nur ein Speicherprob ist (also keine Abstürze): 32 MB Speicher kaufen
4) sectionsd neu schreiben (bei der Erfahrung, die Houdini, Nirvana & Co mittlerweilte habe ....

5) ...

Anonsten Hut ab vor Houdini,Nirvana & Co - der sectionsd ist ja wirklich nicht einfach zu überblicken und die dvb-s spec muss man auch erstmal verstanden haben. Ich jedenfalls würde mich an den sectionsd (auch aus Zeitmangel ) nicht rantrauen - ok kleinere bugs schon, aber keine großen Erweiterungen.

In einer - allerdings schon älternen - Diplomarbeit habe ich übrigens ein paar Hinweise auf Probleme mit dem PrivateEPG gefunden, werde den Link mal die Tage posten (habe ich gerade nicht ). Ist auch so ein guter Überblick über das Thema...

Beitrag von **Innuendo** » Freitag 9. Dezember 2005, 08:07

Houdini hat geschrieben:

Code: Alles auswählen

+			} else {
+				etmp--; // get last element and iterate later
+				deleteEvent((*e)->uniqueKey());
+				etmp++;
+			}

einen zurück und wieder einen vor bei deinem tracker? kommt das nicht aufs selbe (*e) raus?

innu

@petb: Naja Stabilität ist immer so eine Sache. Bei dem einen (auch je nach Box oder Zapping-Gewohnheit) lief es halt immer schon stabiler, als bei anderen. Und wenn man es genau nimmt, war immer irgenwo was, was leicht instabil war. Was jetzt durch die Arbeit von Houdini und Nirvana schon an alten, bis dahin unbemerkten Fehlern aus dem CVS verschwunden ist, zeigt das doch schon ganz gut. Erklärt auch, wieso unter ungünstigen Bedingungen, früher auch schon die ein oder andere Aufnahme in die Hose gegangen ist. Das Speicherproblem war ja schon da, tritt jetzt nur deutlicher hervor.

An alle Devs: Macht weiter so! Neutrino wird besser als jemals zuvor, wenn die Arbeit am Sectionsd zu einem befriedigenden Ende führt.

Hab im Moment einen Schuß von Riker von gestern abend drauf (inkl. des letzten Nirvana Diffs) und der läuft seit gestern abend immer noch stabil.

Code: Alles auswählen

~ > free
              total         used         free       shared      buffers
  Mem:        30916        25856         5060            0         2640
 Swap:            0            0            0
Total:        30916        25856         5060
~ >

Sieht doch schon einigermaßen nett aus, oder ist 5060 free hier zu ungenau?

cu
Jens

Beitrag von **Houdini** » Freitag 9. Dezember 2005, 08:30

Selbst das vom 04.10.05 das ich zur Zeit auf den Produktivboxen nutze lässt den sectionsd abschmieren wenn ich im EPG vom ZDF-Infokanal ein wenig aktiv werde.

dieser Fehler ist definitiv gefixt

@Innuendo

einen zurück und wieder einen vor bei deinem tracker? kommt das nicht aufs selbe (*e) raus?

jein, du hast einen iterator aus einer Menge, wenn du ihn jetzt aus dieser Menge raus löscht und nachher inkrementierst, wohin kommst du dann?

Houdini

Beitrag von **Innuendo** » Freitag 9. Dezember 2005, 08:45

hmmm ...

etmp = e;
..
else
{
etmp--; // get last element and iterate later
deleteEvent((*e)->uniqueKey());
etmp++;
}
e = etmp;

für mich sieht das so aus, als wenn am end das gelöschte element wieder in e geschrieben wird - wahrscheinlich irre ich mich. nachvollziehen, was du/nirvana da macht, ist schwierig

innu

Beitrag von **Innuendo** » Freitag 9. Dezember 2005, 10:17

Günther hat geschrieben: 2) Zurück zur letzten 'stabilen' Version gehen und von da - in development branches - wieder neu aufbauen. Ich denke da an die Zeit vor dem Private EPG, also cvs vor 14. August 2005). - Falls es überhaupt jemals eine stabile Version gab

dieses thema wurde hier hin verschoben.
kurze zusammenfassung der drei seiten von einem der devs:

CVS ist nunmal dafür da,um gemeinsam entwickeln zu können.
wer was stabiles braucht, kann auf die Releases von bla und blub zurückgreifen.

und damit war eigentlich das thema durch ... du kannst aber gern das forum wieder hochholen

innu

Beitrag von **Nirvana** » Freitag 9. Dezember 2005, 13:18

Also ich habe gestern mal mächtig Events gesammelt.

So bei:
total bytes memory allocated with `sbrk' by malloc, in bytes: 14985744 (14634kb, 14.29MB)

war dann Schicht. Da wird sectionsd dann langsam. Verständlich.

Im EIT-Thread findet sich schon folgender Kommentar:
// sectionsd ist zu langsam, da zu viele events -> cache kleiner machen

Allerdings ist das Cache verkleinern auskommentiert. Weiß jemand wieso das wieder gehen musste?

Mir schwebt da eine Maximalgrenze von Events vor...