EE stürzt kontinuierlich ab

[Familienvater]

Hi,

FileIO (schreibedatei und lesewertedatei) habe ich schon mal getestet, das schien mir sauber zu sein.
xmlrpc nutzt Du natürlich indirekt schon, weil der rfd/hs485d alle Events per xmlrpc bei der EE anliefern, und die EE alle Schaltungen per xmlrpc beim rfd/hs485d anliefert.
Ich versuche gerade, künstlich Events vom rfd zu erzeugen, die dieser an die EE liefert, um die Seite auf "härte" zu testen, aber mehr als das Auslösen von kurzen und langen virtuellen Tastendrücken fällt mir dazu nicht ein...
Ich habe auch schon aus der EE heraus 1000x den Status eines TFKs abfragen lassen, das verursacht auch xmlrpc-Schnittstellenverkehr, aber nur in einer Methode, auch das scheint zumindest bei 1000x noch kein Problem zu verursachen, evtl. ist es einfach die Kombination aus allem so ein bisschen, das manchmal der Speicherplatz für eine größer gewordene Zeichenkette neu alloziert werden muss, und der alte Speicherplatz zwar sauber dealloziert wird, aber das dann ungenutzte Loch bleibt trotzdem im Speicher vorhanden, weil es keinen Garbage-Collector gibt, der irgendwann mal die ganzen Löcher "einsammelt" und alles übrige neu im Speicher anordnet (quasi wie eine Festplatte die mit der Zeit fragmentiert, und mal ein Defrag braucht). Das ist dann aber so langsam so tief in C, das da auch meine Kenntnisse ein Ende haben, wer da im Endeffekt schuld ist, und ob man dazu selbst ein Speichermanagement programmieren müsste, um soetwas zu verhindern (quasi den Garbage-Collector für C erfinden)...

Der Familienvater

[Familienvater]

Hi,

RK hat mich gerade informiert, das er ein Speicherleck durch den Hinweis gefunden und gefixt hat, das es aber nicht die normale xmlrpc-Kommunikation betrifft (das wurde Contronics angeblich von EQ3 beigestellt), neue Version kommt in ein paar Tagen...

Ob sich damit unser Absturz-Problem erledigt hat...

Der Familienvater

[ubecker]

Hi,

jetzt wird das einfache Abschmieren der EE aber langsam äußerst kompliziert.

Fakt bei mir:
Keine sets und gets, kein xml, kein tcl, kein clweb und die Visu ist ausschließlich temporär geöffnet --> Datt Dingen schmiert trotzdem ab.

Einzig die Zustände bestimmter Variablen / Sensoren schreibe ich wie Udo alle 10 Minuten in eine Datei (nicht über Allewerte ), welche ich per Init beim Neustart wieder einlese.
Ausserdem lasse ich diverse Schaltvorgänge und Sensorwerte (bei Änderung) in unterschiedliche Textfiles schreiben.

Aber auch hier könnte ich einmal die Zeitspanne erhöhen bzw. ausschalten.
Allerdings mit der Vermutung, dass auch dies nicht zum Ziel einer nicht mehr abschmierendenn EE führen wird.

Ich benutze zur Zeit auch noch keinen dieser Aufrufe.
Zusätzlich zu AlleWerte schreibe ich noch ein paar Dateien die ich dann mit einem anderen Gerät dort abhole und weiter verarbeite.

Aber dann hoffen wir mal auf eine neue EE

gruß udo

[Daimler]

Hi,

RK hat mich gerade informiert,

Ich wusste ja, dass du ihn nerven würdest.

Aber dann hoffen wir mal auf eine neue EE

Yepp.
Der 1. der's weiß gibt bitte Laut.

[Familienvater]

Hi,

RK hatte mir heute morgen wegen einer ganz anderen Geschichte geantwortet, da hatte ich im das Nebenbei und Offtopic mitgeteilt, und ihm später noch mal was zum ursprünglichen Thema mitgeteilt, und die weiteren Erkenntnisse von mir, was das Speicherthema angeht.

Von daher wie immer in kritischen Dingen:
Vielen Dank an RK für die zügige Problemfindung...

Der Familienvater

[Daimler]

Hi,

Vielen Dank an RK für die zügige Problemfindung...

You remember - mein Reden.

[Pietro]

Na dann bin ich mal sehr gespannt - der Speichervebrauch steigt bei mir zwar auch schon wieder sukzessive an, hab aber nun vermutlich mit Raspberrymatic genug Speicher-Luft um CCU-Updates abzuwarten
Wäre dennoch sehr an einer nachhaltigen Lösung interessiert.

An dieser Stelle herzlichen Dank nicht nur an RK sondern auch an den Familienvater, der dies mit hartnäckiger Akribie analysiert !

Danke !

Liebe Grüße Pietro

[Pietro]

Ganz spannende Beobachtung:
Gestern um ca. 08:00h bleib bei mir das erste mal ein CCU-Timer "hängen" - konkret der Timer der für das Auslesen von DutyCycle und freiem Speicher zuständig ist.
Dies wäre an sich - laut Forum - ja noch nichts ungewöhnliches - habe nun mittlerweile auf einen CuxD-Timer umgestellt.

Das Spannende aber ist, dass nach dem Reaktiveren des CCU-Timers (de- und wieder aktivieren) - oder möglicherweise auch knapp vor dem Abschmieren des Timers der Speicherverbrauch stetig nach unten geht und die CCU-Last deutlich höher als vor dem Hänger ist.
Und das obwohl ich nichts, aber auch wirklich nichts geändert habe (es gab auch keinen Exec-Restart).

Any Ideas ?

[Familienvater]

Hi,

Any Ideas ?

ne gar nicht... Aber Du läufst doch auf einem Raspi? Gab es da nicht Probleme mit cuxd-Timern?
Egal... Ich würde/mache solche Dinge, die z.B. alle 5 min laufen müssen aus der cronTab heraus, so richtig klassich, damit läuft mein Health-Monitoring der CCU, und das praktisch wie ein Schweizer Uhrwerk.
Dafür hat heute der ssdpd (irgendso uPnP-Announce-Daemon) auf einmal angefangen Amok zu laufen, auf der Live-CCU2, und auf der zur Zeit laufenden Reserve-CCU2, beiden hatten 100% CPU Last von dem doofen Daemon. Den habe ich einfach per killall zum Teufel geschickt, und es läuft wieder alles, auf dem YAHM läuft kein ssdpd, sonst hätte der vielleicht auch getobt. Ich weiß nur nicht, was die getriggert hat...

Der Familienvater

[Pietro]

auch strange...

Bzgl. CUXD: Ansich läuft der bis dato unter Rasperrymatic problemlos bei mir - however, mit crontab fühl ich mich wohler und dann kann ich gleich ganz auf cuxd verzichten - fein, wieder ein plugin weniger.
Sind denn die cronjobs im gewöhnlichen CCU-Backup enthalten ?

lg Pietro