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

Begonnen von bmwfan, 22 September 2026, 20:50:22

Vorheriges Thema - Nächstes Thema

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.
Synology DS720+ mit Docker-Container und Haupt-FHEM, HM-LAN, Jalousienaktoren HmWired, Shelly-Devices; Raspi 3B+ mit piVCCU ohne FHEM-Instanz, CUL, JeeLink; Raspi 3B+ mit FHEM und HMUARTUSB,  Raspi 3B+ mit HMUARTGPIO, 1-wire, ebusd

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