FHEM-Hauptprozess wächst linear ~200 MB/h, Ursache trotz Diagnose nicht gefunde

[bmwfan]

Hallo DS_Starter,

danke für den Hinweis und den Wiki-Auszug. Ich habe ihn heute getestet:

• MALLOC_MMAP_THRESHOLD_=65536 und MALLOC_TRIM_THRESHOLD_=65536 per Container-Neuerstellung (docker-compose) gesetzt und im FHEM-Prozess per %ENV bestätigt.
• Messung mit psize_full (RSS/Data/Swap), 12:10–12:35: Zuwachs je 5 min 17,5 / 17,7 / 16,8 / 16,9 / 16,3 MB, Mittel 17,0 MB (≈ 204 MB/h). Referenz ohne die Variablen am Vortag: 16,7 MB je 5 min. Swap=0.
• Ergebnis: kein Effekt. Das Wachstum liegt vollständig im Datensegment, der Schwellwert-Mechanismus scheidet bei mir damit als Ursache aus.

Zu deinen Fragen:

• Perl/glibc: Der Wechsel von fhem/fhem:latest (Perl 5.38.5) auf ghcr.io/fhem/fhem-docker:5-bookworm (Perl 5.40.5) am 26.09. hat die Rate nicht verändert (ca. 193 MB/h). Beide Images basieren auf Debian Bookworm, die glibc-Version habe ich nicht variiert. Kernel und Hardware (Synology DS720+, Docker) blieben gleich.

Weitere Fakten, falls sie dir helfen:

• Die Rate ist linear und unabhängig von der Tageszeit (185–205 MB/h). Neun Modul-/DOIF-Gruppen (u. a. SolarForecast, SSCam, FritzSmart komplett) wurden einzeln deaktiviert, ohne Effekt. apptime und Freezemon sind ausgeschlossen.
• Fork-Kinder sind COW-Kopien und für das Wachstum nicht verantwortlich.

Nächste Schritte bei mir: Diff von Konfiguration und Modulen zwischen guter Phase (Backup 21.09.) und schlechter Phase (28.09.), danach ein Rollback der am 22.09. aktualisierten Dateien. Falls du zuerst bestimmte Kernpfade (z. B. MQTT2_SERVER, FHEMWEB, XS-Module) isolieren würdest, wäre ich für einen Hinweis dankbar.

So langsam gehen mir (und der KI) die Ideen aus, an was es noch liegen und wie man das testen kann. Ich fürchte langsam wirklich, und das wäre wegen der umfangreichen Installation der Horror für mich, dass ich FHEM von Grund auf neu aufsetzen muss.

[bertl]

Hallo bmwfan,

ich habe damals, als ich ein Speicherproblem hatte, die Module nicht deaktiviert sondern gelöscht (natürlich vorher gesichert).
Wer sagt denn, dass ein "disable", "ignore", "inactive" vom jeweiligen Entwickler richtig umgesetzt wurde?
Einen Versuch ist es wert!

Gruß, Robert

[MadMax-FHEM]

Ich weiß nicht, ob es hier (auch) das Problem ist aber seit bzw. vor einer Woche habe ich einen Drucker ersetzt (HP).
Von dem (also dem alten Drucker) wurden Statistik- und Verbrauchsdaten mit HTTP-MOD abgefragt (attr-Template).

Seit der neue Drucker, ebenfalls HP (selbe IP), im Netz hängt, hat fhem auch "Sägezahn" bzgl. Speicher.
Nicht so krasse 200MB/h aber alle 2 Tage booten.

Das mit dem Drucker war nur mein Verdacht, da es eben losging, wo ich den Drucker getauscht hatte...

Habe die beiden HTTP-MOD deaktiviert, seither ist Ruhe...

Also die HTTP-MODs liefen nicht ins leere, IP war ja da aber der neue Drucker leifert(e) halt nichts (mehr).

Wie geschrieben, mag hier nicht passen/helfen, wollte es nur loswerden...

Gruß, Joachim

[DS_Starter]

Bei HTTPMOD hatte ich kürzlich auch Strukturen für potenzielles Speicherwachstum entdeckt und bei mir gepatcht.
Da die Änderungen bei mir noch im Test laufen, habe ich sie noch nicht kommuniziert.
Möglicherweise helfen die angepassten Module im vorliegenden Fall, was gleichzeitig die Wirksamkeit der Änderungen bestätigen würde.

Weiterhin wäre mein Hinweis auch mal den eigenen Code in der 99_MyUtils anzuschauen. Möglicherweise hast du dir dort ein Problem eingebaut was jetzt zum Tragen kommt. Wenn du magst, kannst du die Datei auch mal bereitstellen zum Check.

[bmwfan]

Hallo Heiko,

danke für die Module und den Hinweis auf die 99_myUtils.pm. Bei mir wäre der Effekt ohnehin begrenzt, ich habe nur ein HTTPMOD-Gerät mit einem Abruf alle 12 Stunden.

Meine 99_myUtils.pm habe ich durchgesehen: keine dateiweiten Daten, die wachsen, movingAverage begrenzt auf 25 Einträge, die Funktion für die Anwesenheit liest nur Readings. Wenn du sie dir trotzdem anschauen möchtest, hänge ich sie gern an.

Zum Stand, in Kurzform:

Zeitlinie: Aus den SYSMON-Daten (RAM im Minutentakt) beginnt die hohe Rate (ca. 200 MB/h) am 09.09. um 18:10 mit einem Neustart, endet am 14.09. um 21:53 mit einem Neustart (danach 8 Tage nur ca. 15 MB/h) und kommt am 22.09. um 09:40 mit einem Neustart zurück. Konfiguration und Module waren an den letzten beiden Starts identisch. Die Rate wird also offenbar beim Prozessstart festgelegt.
Ausgeschlossen: Docker-Image und Perl-Version (5.38 → 5.40), MALLOC_MMAP_THRESHOLD_/MALLOC_TRIM_THRESHOLD_ (Rate unverändert, 17 MB je 5 Minuten), neun DOIF-Gruppen, SolarForecast und ein Start ganz ohne FritzSmart-Gerät. Ein Test mit längerem Abfrageintervall der Shelly-Geräte senkte das Wachstum nur um etwa 8 %.
Beobachtung: Das Wachstum liegt vollständig im Datensegment (kein Swap), ca. 1,5 Ereignisse und ca. 1 ausgehende Verbindung pro Sekunde.

Meine Frage: Gibt es Fälle, in denen der Zustand beim Start (Reihenfolge der Initialisierung, Timer, Verbindungen) die Wachstumsrate eines FHEM-Prozesses festlegt? Und kennt jemand Werkzeuge, um den Speicher einer laufenden Instanz nach Perl-Strukturen aufzuschlüsseln, ohne die ganze Instanz zu stoppen? Devel::MAT ging bei mir an der Größe des Dumps (3,9 GB) vorbei.

Gruß, Jürgen