LBS19000809 - Alexa Control

[Winni]

Danke für die Recherche, bin da leider nicht so bewandert... fürchte der LBS 19000523 von wintermute könnte das gleiche Problem haben, starte ich nicht so häufig, hat aber ähnliches Verhalten.
Ich Versuch erstmal das System zu stabilisieren, dann schau ich was ich weiter machen kann.

[jonofe]

Habe mir das heute (bzw. gestern) nochmal etwas genauer angeschaut und konnte das Problem nachstellen. Je öfter man Status Info Update triggert, umso schneller läuft der Memory voll.

Die Ursache scheint ein Memory Leak in älteren Versionen von php-curl zu sein:

Siehe auch HIER ...

Damit ist da im Moment nicht wirklich was zu machen, da wir ja an PHP 5.3.3 gebunden sind.

Möglicherweise könnte man das Problem durch ein komplettes Redesign des LBS als Daemon, der dann immer denselben CURL-Handle verwendet, umgehen.

Als Quickfix Workaround kann man mit

sync && echo 3 > /proc/sys/vm/drop_caches

den Cache regelmäßig wieder aufräumen. Dadurch wird der belegte Speicher wieder freigegeben. Das aber auf eigene Gefahr!

[Winni]

Nach 40 Minuten von 7% aus 12% obwohl alle Ausgänge abgeklemmt waren...

[jonofe]

Die Ausgabe zeigt nur, das der LBS nicht läuft, was ja auch richtig ist, denn nur wenn er getriggert wird, startet er kurz, aktualisiert die Ausgänge, beendet sich und gibt auch den Speicher wieder frei. Ich gehe davon aus, dass du den LBS komplett separiert hast, und dann nur den LBS deaktiviert/aktiviert hast.
Ich würde mal alle Ausgänge trennen und nur eine 16-fach Klemme zur Debugzwecken dranhängen. Damit kannst ausschließen, dass irgendeine getriggerte Logik das Speicherproblem auslöst.

Frohes Fest ...

VG
André

[Winni]

Hallo jonofe ,

hab heute mal wieder den Baustein aktiviert, nach 2 Stunden Laufzeit von 7% auf 18%.
Ausgabe des Befehls:
root 9643 0.0 0.0 105316 908 pts/1 S+ 14:00 0:00 grep 19000809

Ich kanns jetzt nicht wirklich interpretieren :-(
Refresh war aktuell alle 30 Sekunden, Gerät wurde in dem Zeitraum nicht benutzt (30 Sekunden aufgrund eines Logikfehlers)
SQL-Verbindungen sind wie beim Start 7 Stück vorhanden.
Als Telegrammgenerator nehme ich 16000117

Schöne Feiertage
Winni

P.S.: Hab gerade nochmal neu gestartet ohne den Refresh-Eingang zu verbinden, Telegrammgenerator läuft also trotzdem....

[Winni]

Ich starte alle 5 Minuten im ausgeschalteten Zustand, ansonsten alle Minuten.
Zum entsprechenden Zeitpunkt waren alle Geräte aus....
Ich bleibe an dem Thema dran, im Moment ist der Baustein nicht aktiv, beim nächsten Mal werde ich deinen Tip ausprobieren. Danke

[jonofe]

Wie oft machst du denn das Status Update an E19?
Du könntest mal prüfen, ob das EXEC Script evtl. nicht richtig beendet wird und dadurch viele Prozesse gleichzeitig laufen. Oder ggf. startest du es so oft, dass der letzte Aufruf noch nicht fertig ist, wenn der nächste erfolgt.

ps axuw| grep 19000809

[Winni]

Wenn der Baustein aktiv ist, komme ich von 7% Speicherbedarf auf 18% in 4 Stunden. Habe die Probleme seit ca. 2 oder 3 Wochen und versuche die Ursache zu finden. Dauert natürlich etwas die Logiken nach und nach zu testen. Kann noch nicht sagen ob's noch anderen Probleme sind

[jonofe]

Falsch steht es eigentlich nicht, denn es ist quasi am Ende des Skripts, da außerhalb der Funktionen. Und das Exec des Alexa Control Bausteins ist ja auch kein Daemon, sondern wird immer als eigener PHP Thread gestartet und nach Ausführung auch beendet. Dabei gibt PHP den gesamten Speicher wieder frei. Ich wüsste jetzt nicht wie dadurch Speicher "gefressen" werden sollte.
Wie bist du denn zu dem Schluß gekommen, dass es an diesem LBS liegt?

[Winni]

Hallo jonofe ,

ich habe meinen Speicherfresser gefunden... schau dir mal bitte den Baustein an. Ich denke sql_disconnect(); ist an der falschen Stelle.

Gruß Winni

[jonofe]

Danke für den Hinweis. Ist in Version 0.2.2 gefixt.

[Winni]

Hallo jonofe ,
du musst $E noch als global definieren, sonst kommt bei jeder Abfrage ein Fehler:
Datei: /usr/local/edomi/www/data/liveproject/lbs/EXE19000809.php | Fehlercode: 8 | Zeile: 194 | Undefined variable: E

Danke

[jonofe]

Ein Update des LBS ist jetzt als Version 0.2.1 verfügbar.

Hier werden jetzt nach jedem Befehl automatisch die Ausgänge geupdated (mit 1s Verzögerung, damit der Befehl auch ausgeführt wurde). Es gibt einen zusätzlichen Ausgang (A10), der die RAW JSON Status Infos des PlayerStates ausgibt, so dass bei Bedarf noch andere LBS dahinter geschaltet werden können.

[jonofe]

Zyklisch ist eher schwierig und würde ein Redesign erfordern, da der LBS dann als Daemon laufen müsste. Das würde ich gerne vermeiden. D.h. ich würde den Triggereingang so lassen wie er ist und er kann von extern zyklisch getriggert werden. Um den Systemtrigger zu umgehen kann man ja auch einen Telegrammgenerator verwenden. Und den automatischen Refresh werde ich dann nach einem Befehl machen. Zusätzlich den Ausgang mit dem Status-JSON String.

[Winni]

Intern wäre natürlich auch ne gute Idee. Um flexibel zu bleiben ein Eingang mit fester Refreshzeit | Refreshzeit nach Befehl? Also zwei Werte, wobei der erste eine zyklische Abfrage triggert, der zweite die Wartezeit nach Befehl (0=ausgeschaltet). Die externen Sytemtrigger triggern immer viele Bausteine gleichzeitig, was man so umgehen könnte.