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

[DS_Starter]

Vllt. von Interesse -> https://forum.fhem.de/index.php?msg=1369762

[bmwfan]

Hallo Heiko,
habe Deine Anregung aufgegriffen und malloc_trim(0) bei mir getestet.
Auf dem fhem-docker-Image (Perl 5.40.5 unter /usr/local/bin/perl) lässt sich FFI::Platypus nicht über apt einbinden, weil das Image sein eigenes Perl mitbringt. Bei mir ging es mit cpanm -L /usr/src/app/3rdparty FFI::Platypus (Compiler vorübergehend nachinstalliert).

Ergebnis bei einem FHEM-Prozess mit 3,8 GB RSS: rc=1, RSS 3817,8 → 3817,9 MB, also kein Effekt, und kein Hänger. Bei mir ist das Wachstum demnach kein freier, zurückgehaltener Heap-Speicher.

Zusätzlich malloc_stats() bei 3,8 GB RSS: In Arena 0 sind von 3.805.581.312 Bytes nur 685.584 frei (0,018 %). Bei mir ist der Heap also praktisch vollständig belegt, nicht fragmentiert.

Danke für die Idee. Da hilft nur: Weiter suchen.

[DasQ]

Ich bleib dabei, wenn der thread hier im Anfänger Bereich liegt, sieht den Rudi nur wenn ihn drauf aufmerksam macht.

[bmwfan]

@DasQ: Ich hatte keinen anderen Bereich gefunden, wo ich meinte das Thema gehört dorthin. Deswegen hier. Wie mache ich denn Rudi darauf aufmerksam? Eine PM oder wie wird das sonst gemacht?

[DasQ]

Ne lass das mal mit dem Anschreiben.

Ich war auch schon auf der Suche nach dem forumsbereich ,,Bug Report"
Aber den gibt es ganz einfach nicht. 

[DS_Starter]

@bmwfan, wieviel RAM hat dein FHEM eigentlich zur Verfügung? Du schreibst ein sehr umfangreiches System zu betreiben. Es wäre einen Test wert im global Device das Attr blockingCallMax auf einen sehr kleinen Wert, z.B. 2/3, zu setzen und zu schauen was passiert. Mich irritieren immer noch deine außergewöhnlich hohen Steugerungsraten.

[bmwfan]

Mein NAS hat 10GB und der FHEM-Container ist auf 6 GB "begrenzt" was bedeutet, dass FHEM dann zu einem Neustart gezwungen wird. Erst wird der RPC-Server OFF geschalten und mit Verzögerung dann FHEM neu gestartet..

[bmwfan]

Die Ursache könnte gefunden sein. Es scheint ein Zusammenspiel von Freezemon, disable 1 und fm_logfile zu sein. Ich lasse jetzt noch einen 24h-Test laufen und wenn es das war, stelle ich die ausführliche Erklärung vor.

Bin nach der tagelangen Suche und vielen Tests mal vorsichtig optimistisch.

[DS_Starter]

Mein NAS hat 10GB und der FHEM-Container ist auf 6 GB "begrenzt"

Auch wenn es viel ist, könnte es bei steigenden RAM Footprint + vielen forks (Blockingcalls) dennoch eng werden.
Deswegen ist der Test durchaus mal wert. Auch viele SVG-Plots mit FHEMWEB Einstellung plotfork=1 führen zu forks mit entsprechenden temp. Speicherbedarf. Mit dem neuen DbLog SVG-Management ist plotfork=0 die richtige Einstellung zzgl. der richtigen Einstellung im DbLog (plotCacheLifetime/plotCacheKeepalive). Dann entstehen kein forks in diesem Kontext.

Und freut mich dass du eine Spur hast. Wenn das passt, können die oben erwähnten Dinge bei weiteren Optimierungen helfen.