Dann bin ich mal gespannt, auf die Werte.
Die sollten dann passen, und dein „Speicherleck“ hat sich in Luft aufgelöst.
Ich glaube, da passt was anderes nicht, wenn symcon sich „zerlegt“
Ich habe nen Pi4CM mit 4GB und 16GB Flash für Symcon als Life System, und alles ist gut.
lg Thomas
Hallo Thomas,
ja, wenn es das nicht ist, dann ist es etwas anderes. Genau wegen dieser Unsicherheit hat der Titel des Threads ja ein Fragezeichen… 
Fakt ist: Mein Symcon wird instabiler, je länger es läuft. Das sorgt ja nicht nur bei mir für Unmut, sondern auch der „WAF“ sinkt…
Schauen wir mal wohin sich die Fehlersuche entwickelt…
Joachim
32-Bit-OS , wechsel doch mal auf 64 bit beim Pi.
…ich würde jetzt ungern „Experimente“ machen, wenn es nicht richtig läuft…
Wir finden bestimmt die Lösung. Wo auch immer die Instabilität herkommt. Ich bin erstmal gespannt ob es ein Speicherleck ist (kann ja immer passieren ) oder wir woanders suchen müssen.
paresy
Also was das Problem unter WIN11 angeht: Nach einigen Stunden steigt die Speicher und CPU Nutzung massiv an, es wird fast kontinuierlich von der SSD gelesen, siehe ProcessMonitor aus sysinternals. Ausserdam gibt es einen Buffer-Overflow … Das ganze System ist aktuell nicht gut nutzbar. Es kann ja durchaus an einem Zusatz- Modul / Instanz liegen. Ich brauche mal Hilfe, wie ich a) Das System im jetzigen Zustand sichern kann, und b) kann ich Module / Instanzen deaktivieren, ohne diese gleich aus dem Objektbaum zu löschen?.
Schau mal bitte in dem PHP Informationen ob du dort evtl. sehr viel Betrieb hast und es evtl. eine Art Endlosschleife gibt?
paresy
wie mache ich das / finde die Infos???
In der Konsole den Tab hinzufügen
Danke, werde beobachten ! LG Harald
…so nun hier mal die geloggten Werte vom Speicher „Available“:
Ist tatsächlich auch abnehmend…
Bei den PHP-Informationen habe ich auch mal reingeschaut, da ist viel los, aber nichts was so aussieht als ob es „hängt“…
Joachim
Na ja, ich wage mal zu behaupten, dass 1% in 24h jetzt nicht so dramatisch sind😉 Erst mal abwarten, ob das auf Dauer so ist.
1 „Gefällt mir“
Ich habe das Problem gefunden! Danke an Ralf. Bei Kontrolle der PHP Info zeigte sich, daß der Code für das Modul „DoorBird“ nicht beendet wurde. Ich vermute, daß der PHP-Code schon während der Ausführung erneut ausgeführt wird, und somit ein rekursiver Effekt ensteht welcher CPU und RAM (Stack!) Ressourcen verbraucht. Nachdem ich den UDP-Socket von DoorBird geschlossen hatte, dann einen Neustart des Symcon-Dienstes läuft alles normal. Weiter unten hänge ich die Screenshots dran. Aber erlaubt mir einige Bemerkungen:
- Wenn so etwas vorkommt, unterwandert das den schönen Gedanken: „Ich habe meine Konfigurations-Masken und alles ist ok“. Ihr stellt genau dies als Vorteil gegenüber HA dar.
- @paresy : Bitte die Info an den Entwickler des Moduls … entweder der PHP Code ist unsauber programmiert( fängt einen Mehrfachaufruf nicht ab) oder ich habe in dem Modul etwas nicht richtig eingestellt (welches abgefangen werden sollte)
Dier sieht man: die Anzahl der aktiven Threads läuft hoch:
LG Harald
Meinst du das?
War bekannt und ist in der stable vom Modul behoben.
Michael
Wollte ich auch gerade schreiben, dass wir letztes Jahr eigentlich das Speicherleck bei Doorbird gelöst hatten.
paresy
DoorBird Modul: Version 1.0 #23
DoorBird FirmWare: 000148, Build 17193036
DoorBird Modell: D1101V
Die Version hat Fonzo nicht angepasst.
Somit einfach nachschauen ob es ein Update gibt.
Michael
Im Modul-Store wird genau diese Version als letzte stabil angegeben???
Ja, sollte die letzte Stable im Store sein. Falls du das Problem damit weiter nachstellen kannst, würde ich gerne mir das ansehen ob evtl. noch irgendwo ein Fehler drin steckt.
paresy
Also zur Klarstellung: Die 1.0 #23 hab ich aus dem Store, und genau mit dieser Version habe ich das beschriebene Problem. Harald