Speicherleck?

175/MBs? Wow. Kannst du mit dem Windows Tool FileMon (FileMon - Sysinternals) bzw. Mittlerweile den Process Explorer mal schauen in welche Datei so wild geschrieben wird?

paresy

Hallo Paresy,

ich logge den Wert jetzt mal mit, sah mir bisher aber immer unauffällig aus…
Melde mich dann wenn ein paar Werte vorliegen… :slight_smile:

Joachim

1 „Gefällt mir“

Ich meinte eher das beim erstellen des Bckups ein temporäres (RAM-)LAufwerk verwendet wird und die temporäre (Zip?)Datei nicht gelöscht wird…

wie sieht denn ein

df -h

aus?

so:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root        59G     24G   33G   42% /
devtmpfs        1,8G       0  1,8G    0% /dev
tmpfs           1,9G       0  1,9G    0% /dev/shm
tmpfs           768M    1,1M  767M    1% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
/dev/sda1       253M     50M  203M   20% /boot
tmpfs           384M     32K  384M    1% /run/user/1000

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… :wink:

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… :wink:

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 :wink: ) 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 :wink:

grafik

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:

  1. 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.
  2. @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