Remote-Support-Client nimmt zunehmend mehr Speicher in Anspruch

[Gero]

Ich habe ein bisschen nodeRED zur Ansteuerung meines http-Heizstabs. Und meine homematic-CCU liest ein paar Sachen aus der openWB per MQTT. Aber keinen, der unbeabsichtigt da reinschreibt.

Zwangstrennung hat es ja aus der Modemzeit bis in Glasfaserzeiten geschafft, irgendwie normal zu sein. Und IP V6 nicht aktiv zu haben, erfordert ja heutztage entweder alte Netzwerk-Hardware oder Absicht. Ich hab‘ hier eine Dreamachine am Glasfaseranschluss. Nicht dass ich sonderlich auf IPV6 geachtet hätte, gehe ich aber mal davon aus, dass das im LAN geroutet wird. Hoffentlich auch entsprechend der IPV4-Fliterregeln. Weil sonst könnte man sich die ja sparen.

[seaspotter]

• Ja, Display vorhanden
• Aktuell Cards, vorher Colors
• Ja iobroker via MQTT, aber ich lese nur die Ladeleistung der Wallboxen aus
• Keine Zwangstrennung, FTTH
• IPv6 ist aus im internen Netz

[zut]

Bei mir ist so lange Ruhe, bis ich das erste mal über die Cloud (Android-App) Daten abrufe und der Support -Client startet. Danach steigt dessen Speicherbedarf konstant an (50MB pro Tag).

• DSL, keine Zwangstrennung
• ioBroker liest verschiedene Topics, ein WiCAN schreibt den SoC, meine Speicherüberwachung ihre Werte unter others/
• bei Ladebeginn oder bei Fahrzeugaktivierung schreibt mein SoC_helper den Fahrzeug-SoC auf den manuellen Eingabewert
• keine Ahnung, ob IPV6 aktiv ist. Vermutlich ja.
• Wallbox hat Display mit Cards-Theme

[Gero]

So, während der Nacht muss es passiert sein. Was genau, kann ich nicht sagen, hab‘ ja geschlafen. Hier aber mal ein paar Screenshots - sortiern müsstenman die nach Mem% aufsteigend.

[zut]

Mir scheint, hier liegt noch ein anderes Problem vor - in deinem Fall ist Python der Übeltäter, während der remote Client unauffällig ist. Bei mir ist es andersrum.

[seaspotter]

Das kann ich bestätigen, gestern Abend war mein Memory bei 94% und bei den Top10 mem Prozesen war python3 bei über 60% und alle anderen chromium Prozesse waren bei ca 10%. Ich hab nen Screenshot gemacht, hab nur gerade kein Zugriff drauf, reiche ich heute Abend nach.

[Gero]

Das scheint mir aber noch ein anderes Problem zu sein. Denn mittlerweile habe ich in die Auswertungen gekuckt und kein "Loch" gefunden. Aber gut, ein Restart eines Prozesses dauert ja keine fünf oder zehn Minuten. Aber dennoch müsste ich ja bei den vergangenen zwei Hängern arges "Glück" gehabt haben, das UI genau in der Sekunde aufzurufen, wo der hängende Prozess am sterben ist.

[LutzB]

Ich denke inzwischen auch, dass der Remote-Client nicht ursächlich ist. Der hat zwar definitiv auch ein Speicherleck, aber der Mehrbedarf pro Tag ist relativ gering. Bei mir konnte ich zumindest feststellen, dass Chromium in Summe kontinuierlich auch den SWAP vergrößert. Es wird inzwischen alle zwei Tage das Display-Theme neu geladen. Ein Problem in allen Themes (es werden von euch sowohl Cards als auch Colors verwendet) schließe ich jetzt mal daher aus.

Ich werde das Neuladen der Themes wieder raus nehmen und stattdessen das Display einmal komplett inkl. Chromium, Display Manager und xServer neu starten. Somit sollte zumindest Chromium kein Langzeitproblem mehr darstellen.

Die ganzen gemeldeten Fehlerbilder und Logs deuten für mich auf ein generelles Verhalten bei akutem Speicherm,angel (out of memory) hin. Dann fängt der Kernel an, mehr oder weniger wahllos Prozesse zu beenden. Den Logs nach zu urteilen, trifft es relatif häufig den Broker, weil dann keine Werte mehr ankommen und der openWB Dienst zumindest scheinbar hängt.

Bitte beachtet, dass die Angaben zu den Prozessen im Maintenance immer nur Momentanwerte sind. Interessanter wird es in den Diagrammen. Wenn dort die Speicherauslastung kontinuierlich wächst oder hoch ist und auch bei den Prozessen die Werte mehr oder weniger unverändert sind, können daraus Erkenntnisse abgeleitet werden.

[Gero]

Bitte beachtet, dass die Angaben zu den Prozessen im Maintenance immer nur Momentanwerte sind.

Du hast ja glücklicherweise daran gedacht, die PID in Klammern dahinter zu schreiben. Wenn man also wie ich über ein paar Tage Screenshots macht und die Speicherbelegung des python2-Prozesses immer weiter ansteigt und mit neuer PID dann wieder gesunken ist, bedeutet das für mich, dass irgendjemand den Prozess neu gestartet hat. Aber vielleicht macht python das ja auch selbstständig.

Die zeitliche Entwicklung in den Graphen ist vielleicht ein bisschen knapp. Und ausserdem wird der Graph nicht mehr aktualisiert, wenn der Safari der Meinung ist, dass da keiner mehr draufkuckt und er die Seite zur Ruhe bettet. Aber screenshots machen macht ja auch einen zeitlichen Verlauf

[seaspotter]

In Ergänzung zu oben viewtopic.php?p=132502#p132502 noch mein Screenshot von gestern Abend.

ksnip_20250907-214809.png

(310.26 KiB) Noch nie heruntergeladen

Was etwas merkwürdig war, heute morgen war dann der mem_used wieder bei 40-50% und aktuell auch wieder. In den Diagrammen sieht man das ab 22:55 bis 00:15 keinerlei Daten mehr vorhanden sind, hier war also wieder alles "mausetot" bis sich dann wohl alle Prozesse neu gestartet haben.

ksnip_20250908-161236.png

(280.49 KiB) Noch nie heruntergeladen

ksnip_20250908-161501.png (118.59 KiB) 85 mal betrachtet

ksnip_20250908-161531.png (109.01 KiB) 85 mal betrachtet