LBS19000809 - Alexa Control

[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.

[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]

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

[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]

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]

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]

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]

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

[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....

[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]

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

[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]

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.

[wintermute]

fürchte der LBS 19000523 von wintermute könnte das gleiche Problem haben

Das ist aber kein Problem, das ist einfach Absicht und hat schlicht mit dem Speichermanagement des Kernels zu tun...
Erstmal stellt sich ja fuer den unwissenden Beobachter die Frage: wieso baut ihr 8x soviel Speicher wie benoetigt in euren Edomi-Rechner um euch dann zu beschweren dass 20% davon auch tatsaechlich benutzt werden obowhl 5% ja auch reichen wuerden... was soll das System mit den ueberfluessigen 95% am Speicher denn anstellen? Fuer schlechte Zeiten aufbewahren?

Ansonsten: wenn Speicher zur Verfuegung steht, dann wird der Kernel den auch benutzen. Im haeufigsten (und am einfachsten zu verstehenden Fall) wird er als Cache fuer I/O Operationen benutzt. Der obigen Befehl mit dem /proc/blah/fasel fuehrt auch deswegen zur gefuehlten Verbesserung weil eben genau die Caches geleert werden und alle ausstehenden I/O-Operation gezwungen beendet werden. Wuerde es sich um ein Memory-Leak handeln, wuerde der Befehl garnix bringen denn dadurch wird einem Prozess kein Speicher weggenommen. Wie soll sowas auch funktionieren ohne den Prozess zu stoeren oder abstuerzen zu lassen? Genau deswegen kann man Memory-Leaks auch nur dadurch aus dem Weg raeumen indem man den betreffenden Prozess beendet.
Im uebrigen ist es nicht so trivial wie es scheint den tatsaechlichen Speicherverbrauch eines Prozesses festzustellen, wer das machen moechte kann aus /proc/<PID>/stat bzw /proc/<PID>/statm recht ausfuehrliche Informationen ueber das Speichernutzungsverhalten einzelner Prozesse rauslesen, angefangen von tatsaechlich belegten Pages, der Anzahl an Pages die der Prozess gern haben moechte, die Anzahl an Pages die der Kernel gern abgeben moechte, die Anzahl an Pages die im Swap liegen und noch viel mehr anderes, nicht nur ueber Pages

Wer noch keinen echten Memory-Leak gesehen hat dem sei gesagt: das ist keiner.

Weiterhin als gut gemeinten Rat: wenn ihr euren Speicher nicht braucht (oder brauchen wollt), dann verkauft ihn. Der ist ja von Tag zu Tag weniger wert

[Winni]

Mag ja alles richtig sein, ich versuche halt aktuell dem Problem auf den Grund zu gehen, warum ich immer wieder Probleme mit KNX Verbindung und Speicherbedarf bis 80% habe. Beides geht irgendwie Hand in Hand und beginnt spätestens bei 20% und immer häufiger muss ich Edomi mehrfach täglich neu starten, weil ich nichts mehr auf den Bus bekomme, das kann ja nicht Sinn und Zweck sein.
Ich hatte Zeiten, da lief der Server wochenlang ohne irgendwelche Mucken.