Sectionsd abnehmender Speicher -> Reproduzierbar!!!

Hi,
habe mich bestimmt 3 h damit befasst den Speicherverlauf von Sectionsd zu verfolgen um dort auffälligkeiten zu finden. Und die habe ich reproduzierbar gefunden. Image JTG 10.12. Nokia Sat Avia 500

Vorgehensweise:
Webif auf der Box starten, telnet -> top starten

Im Webif habe ich jetzt mit killall sectionsd den max frei Speicher ermittelt, ausgelesen mit top:
12660k-13032k

Nun habe ich die Box immer auf dem Sender gelassen um den Speicherbedarf de Bouqets zu ermitteln, d.h. killall wenn der Speicher sich nicht mehr ändert und neustart sectionsd, das immer mind. 3 -5 mal bis ich eindeutige Werte habe.

ARD= 5636k min 6624k max
ZDF= 2516k min 3664k max
Pro7=1840k min 2996k max
RTL= 688k min 1840k max
---------------------------------

ergibt insgesamt mind. 10680k bis max 15140k !!!

Die Maxwerte ergeben sich wenn man den Speicherverlauf beobachtet und stellt den Scheitelwert dar, i.d.R geht er nach einigen Sec. um ca 1160k wieder zurück, d.h. im Freilauf werden 1160k freigegeben.

Warum? keine Ahnung, der %Max vom Sectionsd bleibt gleich, der gibt den Speicher nicht frei!!!

Dann habe ich immer munter zwischen ARD, ZDF, Pro7 und RTL gezappt und den Speicher geobachtet ohne sectionsd zu killen. Irgendwann war er bei ca 2000k frei im idle. dazu habe ich ca 10 * gezappt vom einen zum anderen.

Jetzt kommt aber das großte Problem:
Nun zappe ich nur noch zwischen ARD und ZDF hin und her, dabei warte ich immer bis die Box idle ist und den Speicher freigegeben hat:

Mit jedem Zappen geht der Speicher um 16k runter !!!! die Differenz zwischen min und max bleiben immer gleich.

Das beweist meine Beobachtung, dass solange die Box auf dem gleichen Kanal/ Bouqet bleibt der Spicher nicht abnimmt, erst wenn zwischen den Bouqets gewechselt wird gehts runter. Daher kann ich auch seit 3 Tagen auf MCE aufnehmen ohne dass der Free Mem weniger wird!!!

Wenn ich diese Beobachtung zuende denke, gibt es nach ca 50mal Bouqet Wechsel keinen Speicher mehr, da der Min Wert <=0 sein müßte, d.h. exitus für den sectionsd. Und das schafft meine Schwiegermutter in 2 Tagen locker!!!

Uff, wenn das nicht weiterhilft...

Cu
Torsten

Edit: 18.12.05
Aktueller Stand ist eine Sectionsd, die insgesammt weniger an Speicher benötigt, als die im CVS. Sie scannt nicht mehr alle Events (7500 z.Zt) und nicht mehr auf allen Sendern zugleich.
Langzeittest noch nicht abgeschlossen.

Bekannte Probleme z.T.:
- Neutrino, Movieplayer & Tuxtext scheinen ebenfalls Speicherleeks zu haben.

Hier gibt es sie zum Download (von Nirvana):
http://s58.yousendit.com/d.aspx?id=0HSO ... LIBM6N2EXK

So wird sie installiert:

jmittelst hat geschrieben:Einfach nach /var/bin legen, chmod auf ausführbar, start_neutrino aus /etc/init.d nach /var/tuxbox kopieren - mit Editor den Start-Aufruf des sectionsd nach /var/bin/sectionsd ändern, chmod auf ausführbar, Box rebooten und dann kannste testen. (für JtG)

cu
Jens

hört sich interessant an, das könnte auch auf ein Leak hinweisen, das durch die Abarbeitung der sectionsd-Kommandos kommt.

d.h. im Freilauf werden 1160k freigegeben.

das scheint dann freigegeben zu werden, wenn sich EIT schlafen legt, damit wird dann auch das DMX-device zugemacht

zumindest beim addbouquet() gibts ja noch leaks

Houdini hat geschrieben:...zumindest beim addbouquet() gibts ja noch leaks

..wahrscheinlich auch noch woanders...der Ramverbrauch von 'neutrino' scheint auch langsam anzusteigen...

der Ramverbrauch von 'neutrino' scheint auch langsam anzusteigen

ack

...was kann der interessierte User machen, um den Entwicklern bessere Informationen zu geben? Wie sollen wir zB. evtl. memory leaks finden...welche Experimente koennen helfen?
Ich habe meine Dbox jetzt ca. 24h an und ausser zapping nix gemacht...trotzdem ist sectionsd auf 47,7% und neutrino auf 16,1% MEM und ich befuerchte das die erste programmierte Aufnahme (in wenigen Minuten) in die Hose geht....es wird wahrscheinlich nur die *.xml Datei geschrieben...schaetze ich mal...

PS:...Aufnahme ist tatsaechlich in die Hose gegangen...es wurde nur die *.xml geschrieben!

Hi,

ihr dürft euch nicht nur den freien Speicher anschauen ! Sondern auch den Disk-Cache und die Buffers ! Denn eigentlich müsst ihr Free-Mem+Buffers+Cache zusammenzählen um den Verfügsbaren Speicher zu ermitteln.
Der Kernel greift sich alles was nicht benutzt (naja gewisse Prozentzahl) und gibts es dem Cache bzw den Buffern. Wenn nun aber Speicher für eine Anwendung gebraucht wird, gibt er wieder Speicher vom Cache/Buffer ab.

Kann man gut beobachten, wenn man den Sectionsd bischen fordert. Dadurch kommen auch die Schwankungen im Free-Mem her, es wird halt mal der Cache verkleinert, dann mal wieder was vom Free-Mem genommen oder auch mal die Buffer verkleinert!

Wenn man mal nur den Cache sieht. haben wir so ca. 15MByte freien Speicher !! Und das sollte doch wohl langen...... (Wenn da kein Fehler in der Speicherverwaltung sitzt

)

Gruß Kroki

Dass nach Erreichen des idle Zustandes wieder Speicher freigegeben wird, kann ich auch bestätigen, zu meiner Testreihe von hier läßt sich dieser Zustand noch nachtragen:

Code: Alles auswählen

  6:24pm  up 20:02,  0 users,  load average: 0.08, 0.06, 0.00
41 processes: 40 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:   1.9% user,   5.7% system,   0.0% nice,  92.4% idle
Mem:     30916K total,    28720K used,     2196K free,     2632K buffers
Swap:        0K total,        0K used,        0K free,     6176K cached

Übrigens ist es bei mir ohne Wechseln des Bouquets zu diesem Speicherverzehr gekommen!

Hi,

wenn man den sectionsd auf nem Intel PC mit DVB Karte am Laufen hat, könnte man doch mal einen "memleak-checker" ala 'valgrind' o.ä. darauf ansetzen ? ...

- GMo -

..imo scheint an dem neuen Schreckgespenst 'unerkannte memory leaks' echt was dran zu sein. sectionsd bringt das Fass halt etwas schneller zum ueberlaufen....deshalb waere ich erstmal fuer eine feste Ramgroesse fuer sectionsd....zB. 8192 KB fuer die 32MB-Boxen. Dann koennen wir in aller Ruhe beobachten und evtl. weitere memory leaks finden...die es imo ohne Zweifel gibt.

Hi,
so heute morgen habe ich mal schnell den nächsten Versuch gestartet. Hat mir heute Nacht keine Ruhe gelassen

Ich bin davon ausgegangen, dass wenn ich auf ARD bin nur die EPG Daten des ARD Bouqets gesammelt werden, da auch nur in diesem Bouqet die EPGs dann angezeigt werden.
Soll heißen dass ich dachte den Speicherbedarf ermitteln zu können indem ich je einen Sender im ARD/ZDF/RTL/PRO7 Bouqet anzappe und nach obiger Beschreibung den freien Speicher auslese.

Nun wollte ich nochmal sicherstellen ob der Speicher innerhalb des Bouqets wirklich nicht abnimmt indem ich nur im ARD Bouqet zappe.

Was sehe ich da, ich fange mit ARD an, dann auf WDR, MDR (genaue Reihenfolge habe ich zuhause aufgeschrieben), habe also nur Sender genommen wo ich EPG Infos sehen konnte und im selben Bouqet waren und der Speicher ging auf 2000 runter, und das obwohl ich nur 4 Sender aufgerufen hatte!

Die Erklärung, es waren auf einmal auch auf dem ZDF Bouqet die EPG es da

also entweder senden die ihre EPG Infos nicht nur für das eigene Bouqet sondern auch für ZDF oder hier läuft was gewaltig schief!
(Fehler meinerseits sind nicht ausschließbar, war noch müde

)

Werde das heute abend nochmal nachstellen, vielleicht findet von Euch sich ja auch noch jemand der Zeit dazu hat.

Dann schaue ich mal auf den Cache und restlichen Werte. Im Grunde werden die aber doch nicht viel an der Tatsache ändern, das belegbar der Speicherverbrauch von Sectionsd ansteigt und mit einem killall sectionsd wieder alles freigegeben wird.

Übrigens gibt es ein EPG Reset Script das man als Timer einrichten kann, das funktioniert ganz gut (Täglich Nachts ein EPG Reset und meine Schwiegermutter kann in ruhe Fernsehen

)

Ich erkläre mich übrigens gerne bereit an irgendwelchen Test teilzunehmen, auch mit anderen Setionsd es, sie müßten nur entweder in Form eines JTG Squashfs sein oder ein Komplettimage, da ich leider nicht selber Images kompilieren kann.
Ich habe so in Erinnerung, dass es noch nicht eingepflegte Änderungen gibt.
Denn eines ist sicher, wenns auf der Nokia meiner Schwiegermutter funktioniert, dann haben wir gesiegt

Cu
Torsten

Beitrag von **mws** » Donnerstag 15. Dezember 2005, 14:16

wenn man sich mal mit der ETSI EN 300 468 auseinandersetzt, auch das gehört dazu, wenn man etwas verstehen will, sieht man:

auf der PID 0x12 gibt es insgesamt
34 Tables die EPG Informationen enthalten _können_
0x4e (Aktueller Transponder Present/Follow)
0x4f (Andere Transponder Present/Follow)
0x50 - 0x5F (Aktueller Transponder Schedule)
0x60 - 0x6F (Andere Transponder Schedule)

aus diesem grunde bekommt man z.b. auch auf dem Ard Transponder die EPG-Daten für das ZDF, oder bei ProSiebenSat1 die für Premiere.

das was man in der senderübersicht sieht bezieht sich ausschliesslich auf Present/Follow.

Das was ihr mal machen könnt, wäre den EPG auf die Table 0x4e zu reduzieren.
damit bekommt man zwar nur noch, das was Present/Follow für diesen einen gewählten Transponder angeht, aber man könnte sehr gut beobachten, ob es ein LEAK gibt.

gruss
mws

@Entwickler
..geht das nicht den Speicherbedarf/Buffer fuer den sectionsd auf einen bestimmten Wert festzulegen? Ich verstehe nicht so ganz warum man das nicht zumindest temp. mal macht bis die ganzen Probleme mit sectionsd gefixt sind.

Beitrag von **mws** » Donnerstag 15. Dezember 2005, 14:47

theoretisch geht das
aber um das zu machen, und auch so _richtig_, müsste man seine eigene
speicherverwaltung dafür bauen, das ist erheblich komplexer als so manche user hier denken

das problem ist halt, das man sich eigentlich mehr mit dem wie alles gecoded wurde auseinander setzen muss.

gruss
mws

mhh, hoffe, ich werde nicht zu OT, hab momentan das JtG-Komplettimage vom 20.10. drauf, da sieht man auch, wie der Speicher langsam abnimmt, aber im Gegensatz zum aktuellen Snap rödelt der sectionsd etwa 20 Sekunden in der top Anzeige rum, auch mit bis über 90%, aber im aktuellen Snap sind es bei mir um die 65 Sekunden. Dadurch vermute ich auch, dass der Speicherbedarf so sprunghaft angestiegen ist.

mws hat geschrieben: auf der PID 0x12 gibt es insgesamt
34 Tables die EPG Informationen enthalten _können_
0x4e (Aktueller Transponder Present/Follow)
0x4f (Andere Transponder Present/Follow)
0x50 - 0x5F (Aktueller Transponder Schedule)
0x60 - 0x6F (Andere Transponder Schedule)
mws

for ( int i = 0x4e; i <= 0x6f; i++) durchsucht ja alle in sectionsd.cpp

Interessant wäre doch sicherlich nur 0x4e und 0x50 - 0x5F, oder?

Ist der 0x60 - 0x6F (Andere Transponder Schedule) nicht unwichtig, und schluckt nur unnötig Speicher?

...ich experimentiere jetzt erst mal mit ausgeschaltetem EPG (blaue Taste>>>EPG ein/aus)...nach starten der Box eine kurze zapping-Session auf meine Lieblingssender und dann halt EPG ausschalten. sectionsd hat sich in der kurzen Zeit 23% Ram gekrallt und das bleibt jetzt auch dabei...merkwuerdigerweise wird sectionsd trotz ausgeschaltetem EPG periodisch/nach zappen aktiv und krallt sich imo ziemlich viel CPU-Leistung...wie laesst sich das erklaeren?

PS:..wer zum Henker schaltet EPG wieder ein? Obwohl ich das ueber die FB ausgeschaltet habe ist das jetzt wieder eingeschaltet...

PPS:..bitte erklaert mir wie ich nach Start der Box die EPG fuer meine Lieblingssender einlesen kann und dann sectionsd schlafen legen kann ohne dass die schon eingelesene Programmvorschau verloren geht?

Die Frage ist: Was schaltet das Plugin aus?
Die Sammlung der Daten findet im Hintergrund weiter statt

Hier eine Sectionsd, ohne 0x60 - 0x6F (Andere Transponder Schedule)

http://www.megaupload.com/de/?d=31ZNRZ6R

mws hat geschrieben:wenn man sich mal mit der ETSI EN 300 468 auseinandersetzt, auch das gehört dazu, wenn man etwas verstehen will,

habe mir die reference angeschaut - puuuh ....
aber ich hab da auch was gefunden:

service descriptor -> service_type:
0x02 digital radio sound service
0x0A FM radio

wenn man jetzt die idee von nirvana aufgreift und die events (nicht den speicher) begrenzen möchte [MAX_EVENTS ... was ist draus eigentlich geworden? nur ein link im forum???], dann wäre doch eine möglichkeit, bei der auswahl service->senderscan->nur tv den service_type 0x02 zu verwerfen.
da gibt es ja auf ard wie ich hier gelesen habe seit august 90 sender, die die nur-tv-box mit unnützen infos befüllen.
bevor das gezeter wieder losgeht ... wer tv+radio eingestellt hat, soll ja alles weiterhin so bekommen, wie es ist.

innu

...ich wuerde diese Daten gerne lesen koennen waehrend Radio...geht aber nicht und laut ????? waeren diese Zusatzinfos im _Audiostream_ eingepackt und nur die Dreambox kann das nebenbei per Hardware auslesen. Wieso diese Daten jetzt den Speicher zumuellen sollen verstehe ich nicht so ganz...

@petgun
das weiß ich nicht - aber ich glaube wir reden von zwei verschiedenen dingen - epg und ??? (eingepackte infos im audiostream über antenne für die anzeige im autoradio)
kann aber sein, dass ich völlig falsch liege

Innuendo hat geschrieben:..aber ich glaube wir reden von zwei verschiedenen dingen - epg und ???

jau, sorry...ich dachte Du redest von RDS
BTW suche ich immer noch nach einer Moeglichkeit den EPG 'einzufrieren' ohne das sectionsd weiterhin aktiv ist und den Speicher auffrisst...

Habt ihr mal meine angehängte Sectionsd getestet? Rennt bei mir gut und schnell

Hi,

so sieht es heute Abend aus. Eindeutig ist Mem von 2004K auf 1844K heruntergegangen. Ohne zu zappen.

Box1:

Code: Alles auswählen

43 processes: 41 sleeping, 1 running, 1 zombie, 0 stopped
CPU states:   3.9% user,   4.8% system,   0.0% nice,  91.3% idle
Mem:     30916K total,    29072K used,     1844K free,     2660K buffers
Swap:        0K total,        0K used,        0K free,     7472K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1718 root      16   0   792  792   636 R     7.0  2.5   0:01 top
 1715 root       9   0   424  420   340 S     0.5  1.3   0:00 telnetd
   57 root       9   0     0    0     0 SW    0.1  0.0   1:11 avia_av_wdt
    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:00 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   0:02 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:00 kupdated
    7 root       9   0     0    0     0 SW    0.0  0.0   0:00 mtdblockd
    9 root       9   0   536  536   516 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:00 jffs2_gcd_mtd3
   23 root       9   0   592  588   492 S     0.0  1.9   0:00 inetd
   79 root       9   0   520  516   436 S     0.0  1.6   0:00 start_neutrino
   92 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   93 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   94 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   97 root       9   0     0    0     0 SW    0.0  0.0   0:00 kdvb-fe-0:0
   98 root       9   0  1768 1768  1104 S     0.0  5.7   0:19 zapit
  114 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  116 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  117 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  118 root       9   0  2172 2172  1508 S     0.0  7.0   0:03 nhttpd
  119 root       9   0  4268 3456  2320 S     0.0 11.1   0:59 neutrino
  120 root       9   0  4268 3456  2320 S     0.0 11.1   0:00 neutrino
  121 root       9   0  4268 3456  2320 S     0.0 11.1   0:19 neutrino
  131 root       9   0     0    0     0 SW    0.0  0.0   0:00 rpciod
  150 root       9   0  4268 3456  2320 S     0.0 11.1   0:00 neutrino
  155 root       8   0  2172 2172  1508 S     0.0  7.0   0:01 nhttpd
 1645 root       9   0  2172 2172  1508 S     0.0  7.0   0:00 nhttpd
 1646 root       9   0   504  500   420 S     0.0  1.6   0:00 sh
 1647 root       9   0   580  576   460 S     0.0  1.8   0:00 Y_Tools.sh
 1649 root       9   0     0    0     0 Z     0.0  0.0   0:00 sectionsd <defunc
 1650 root       9   0 11620  11M   952 S     0.0 37.5   0:49 sectionsd
 1651 root       9   0 11620  11M   952 S     0.0 37.5   0:00 sectionsd
 1652 root       9   0 11620  11M   952 S     0.0 37.5   0:00 sectionsd
 1653 root       9   0 11620  11M   952 S     0.0 37.5  55:18 sectionsd
 1654 root       9   0 11620  11M   952 S     0.0 37.5   0:00 sectionsd
 1655 root       9   0 11620  11M   952 S     0.0 37.5   0:02 sectionsd
 1656 root       9   0 11620  11M   952 S     0.0 37.5   0:00 sectionsd
 1657 root       9   0 11620  11M   952 S     0.0 37.5   0:11 sectionsd
 1716 root       9   0   660  660   548 S     0.0  2.1   0:00 sh

Hier die Box meiner Schwiegermutter, auffällig ist, das der %Mem von Neutrino höher ist, und auch die Cache und buffers anders sind:

Box2:

Code: Alles auswählen

  9:25pm  up 14:31,  0 users,  load average: 1.00, 0.56, 0.44
43 processes: 41 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  23.3% user,  16.4% system,   0.0% nice,  60.2% idle
Mem:     30916K total,    29140K used,     1776K free,     1128K buffers
Swap:        0K total,        0K used,        0K free,    10544K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
   89 root      10   0 10196   9M   976 S    23.4 32.9  54:59 sectionsd
20305 root      17   0   796  796   636 R     8.4  2.5   0:02 top
20296 root       9   0   424  420   340 S     1.0  1.3   0:00 telnetd
   59 root       9   0     0    0     0 SW    0.1  0.0   0:52 avia_av_wdt
  100 root       9   0  1676 1676  1104 S     0.1  5.4   0:33 zapit
    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:00 keventd
    3 root      19  19     0    0     0 RWN   0.0  0.0   0:07 ksoftirqd_CPU0
    4 root       9   0     0    0     0 SW    0.0  0.0   0:21 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:00 mtdblockd
    9 root       9   0   536  536   516 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:00 jffs2_gcd_mtd3
   23 root       9   0   592  588   492 S     0.0  1.9   0:00 inetd
   81 root       9   0   520  516   436 S     0.0  1.6   0:00 start_neutrino
   85 root       9   0 10196   9M   976 S     0.0 32.9   0:03 sectionsd
   87 root       9   0 10196   9M   976 S     0.0 32.9   0:00 sectionsd
   88 root       9   0 10196   9M   976 S     0.0 32.9   0:01 sectionsd
   90 root       9   0 10196   9M   976 S     0.0 32.9   0:00 sectionsd
   91 root       9   0 10196   9M   976 S     0.0 32.9   0:04 sectionsd
   92 root       9   0 10196   9M   976 S     0.0 32.9   0:00 sectionsd
   93 root       9   0 10196   9M   976 S     0.0 32.9   0:06 sectionsd
   94 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   97 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   98 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
  111 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  113 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  114 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  118 root       9   0  2060 2060  1460 S     0.0  6.6   0:02 nhttpd
  119 root       9   0  4600 3788  2412 S     0.0 12.2   0:39 neutrino
  122 root       9   0  4600 3788  2412 S     0.0 12.2   0:00 neutrino
  123 root       9   0  4600 3788  2412 S     0.0 12.2   0:46 neutrino
  133 root       9   0     0    0     0 SW    0.0  0.0   0:40 rpciod
  153 root       9   0  4600 3788  2412 S     0.0 12.2   0:00 neutrino
18254 root       9   0     0    0     0 SW    0.0  0.0   0:00 kdvb-fe-0:0
19242 root       9   0  2060 2060  1460 S     0.0  6.6   0:00 nhttpd
20297 root       9   0   660  660   548 S     0.0  2.1   0:00 sh

nun habe ich gezappt auf WDR und als idle war wieder auf ARD zurück:

Box1:

Code: Alles auswählen

  9:31pm  up 22:39,  0 users,  load average: 0.89, 0.63, 0.30
43 processes: 41 sleeping, 1 running, 1 zombie, 0 stopped
CPU states:   4.0% user,   5.1% system,   0.0% nice,  90.9% idle
Mem:     30916K total,    29116K used,     1800K free,     2660K buffers
Swap:        0K total,        0K used,        0K free,     7476K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1718 root      18   0   792  792   636 R     7.8  2.5   1:08 top
 1715 root       9   0   424  420   340 S     0.9  1.3   0:06 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:00 keventd
    3 root      19  19     0    0     0 SWN   0.0  0.0   0:02 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:00 kupdated
    7 root       9   0     0    0     0 SW    0.0  0.0   0:00 mtdblockd
    9 root       9   0   536  536   516 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:00 jffs2_gcd_mtd3
   23 root       9   0   592  588   492 S     0.0  1.9   0:00 inetd
   57 root       9   0     0    0     0 SW    0.0  0.0   1:12 avia_av_wdt
   79 root       9   0   520  516   436 S     0.0  1.6   0:00 start_neutrino
   92 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   93 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   94 root       9   0  1124 1124   968 S     0.0  3.6   0:00 timerd
   97 root       9   0     0    0     0 SW    0.0  0.0   0:00 kdvb-fe-0:0
   98 root       9   0  1768 1768  1104 S     0.0  5.7   0:20 zapit
  114 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  116 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  117 root       9   0  1136 1136   976 S     0.0  3.6   0:00 controld
  118 root       9   0  2172 2172  1508 S     0.0  7.0   0:03 nhttpd
  119 root       9   0  4288 3476  2320 S     0.0 11.2   1:00 neutrino
  120 root       9   0  4288 3476  2320 S     0.0 11.2   0:00 neutrino
  121 root       9   0  4288 3476  2320 S     0.0 11.2   0:19 neutrino
  131 root       9   0     0    0     0 SW    0.0  0.0   0:00 rpciod
  150 root       9   0  4288 3476  2320 S     0.0 11.2   0:00 neutrino
  155 root       8   0  2172 2172  1508 S     0.0  7.0   0:01 nhttpd
 1645 root       9   0  2172 2172  1508 S     0.0  7.0   0:00 nhttpd
 1646 root       9   0   504  500   420 S     0.0  1.6   0:00 sh
 1647 root       9   0   580  576   460 S     0.0  1.8   0:00 Y_Tools.sh
 1649 root       9   0     0    0     0 Z     0.0  0.0   0:00 sectionsd <defunc
 1650 root       9   0 11640  11M   952 S     0.0 37.6   0:50 sectionsd
 1651 root       9   0 11640  11M   952 S     0.0 37.6   0:00 sectionsd
 1652 root       9   0 11640  11M   952 S     0.0 37.6   0:00 sectionsd
 1653 root       9   0 11640  11M   952 S     0.0 37.6  57:44 sectionsd
 1654 root       9   0 11640  11M   952 S     0.0 37.6   0:00 sectionsd
 1655 root       9   0 11640  11M   952 S     0.0 37.6   0:02 sectionsd
 1656 root       9   0 11640  11M   952 S     0.0 37.6   0:00 sectionsd
 1657 root       9   0 11640  11M   952 S     0.0 37.6   0:12 sectionsd
 1716 root       9   0   660  660   548 S     0.0  2.1   0:00 sh

Nun werde ich mal die Test sectionsd einbauen...
Cu
Torsten

T-Tron hat geschrieben:Habt ihr mal meine angehängte Sectionsd getestet? Rennt bei mir gut und schnell

So habe sie bei mir auf der Nokia Avia500 AMD Sat im Testlauf. Der Speicherbedarf ist deutlich niedriger. Ich habe immer noch 7476k frei und habe alle Sender / Bouqets durchgezappt. Es hat aber anscheinend länger gedauert bis alle Infos da waren.

Ich weiß nicht was Deine Änderung (andere Transponder Schedule) genau bewirkt, aber es macht Speicher frei. Ob die Leeks dadurch weniger werden wird sich zeigen.
Begrenzt Du auch die Events?

Cu
Torsten