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
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…
Joachim
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…
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“:
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.
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:
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