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

[bmwfan]

Hallo zusammen,
aufgrund des komplexen Fehlers leider ein längerer Post.

Ich habe seit kurzem wiederholt ein Speicherproblem, dessen Ursache ich trotz intensiver Eigendiagnose nicht finde. Das Problem trat bereits vor ca. 3 Wochen auf, verschwand nach einer Konfigurationsänderung (vermutlich, aber nicht sicher belegt – siehe unten), und ist seit einem Modul-Update heute wieder exakt im gleichen Muster zurück. Ich vermute daher eine tieferliegende, wiederkehrende Ursache, die durch verschiedene Änderungen nur zeitweise maskiert wird.

Umgebung
•    Synology DS720+, FHEM in Docker (Image fhem/fhem:latest, Basis Debian, Perl 5.038005)
•    fhem.pl Build: 2026-09-20 (heute per update aktualisiert von Build 2026-08-29)
•    Featurelevel 6.4
•    Aktive Hauptmodule: HMCCU/HMCCURPCPROC (Version 2024-12, 4 RPC-Interfaces: BidCos-RF, BidCos-Wired, HmIP-RF, VirtualDevices), PRESENCE2 (01.05, mehrere Devices + Daemon), FritzSmart (26.09.15), 113× DOIF, ROOMMATE/RESIDENTS, SolarForecast, DbLog (heute aktualisiert, neue SVG-Subprozess-Architektur), SSCam (3 Kameras), Freezemon (aktuell disable=1)
•    Versionen Module: Siehe Datei

Symptom
Der Hauptprozess (perl fhem.pl fhem.cfg) wächst linear und sehr gleichmäßig um ca. 200–210 MB/h, ohne erkennbares Plateau. Gemessen über 8,5 Stunden nach einem Neustart, RSS aus ps:
Zeit seit Neustart    RSS Hauptprozess    Zuwachs/30 min
0:15 h    388.664 kB    –
0:45 h    491.020 kB    +102.356 kB
1:15 h    595.344 kB    +104.324 kB
1:45 h    696.244 kB    +100.900 kB
2:15 h    800.112 kB    +103.868 kB
...    ...    konstant im selben Bereich
8:45 h    2.135.340 kB    +104.844 kB

Die Schwankung zwischen den Intervallen liegt bei nur ±5 %. Es handelt sich um einen praktisch konstanten Zuwachs pro Zeiteinheit – das spricht für einen regelmäßig laufenden internen Vorgang (Timer/Notify-Zyklus), der bei jedem Durchlauf eine ungefähr gleich große Speichermenge bindet, ohne sie wieder freizugeben. Unbehandelt führt das nach 20–24 h zu vollständiger Speichererschöpfung des Hosts (Cannot fork: Cannot allocate memory).

Was ich bereits ausgeschlossen habe (mit Belegen)
•    apptime/Freezemon (helper->{bm}): Struktur wuchs zwar durch aktive apptime-Nutzung, aber nach apptime pause/clear blieb bm bei 0 – die Hauptprozess-Wachstumsrate änderte sich dadurch nicht merklich.
•    HMCCURPCPROC: Die vier RPC-Kindprozesse wachsen mit ca. 1,7–2 MiB/h/Prozess – deutlich, aber konstant über mehrere Messreihen (auch vor dem heutigen Update) und in einer völlig anderen Größenordnung als der Hauptprozess. Modul-Dateidatum unverändert seit 08.01.2025.
•    DbLog-Subprozess (PID separat gemessen): RSS blieb über die gesamten 8,5 h bei exakt 81.812 kB – der neue SVG-Subprozess-Mechanismus selbst wächst nicht.
•    FritzSmart: helper- und fhem-Hash-Keys des Devices blieben über den gesamten Zeitraum konstant (16 bzw. 30 Keys).
•    PRESENCE2/DOIF-Timer-Anzahl (@intAtA): schwankt im Bereich 250–280, kein Aufwärtstrend.

Der Zuwachs sitzt also, wie ich vermute, im Hauptprozess selbst, ohne dass eine der von mir beobachtbaren Perl-Datenstrukturen (%defs-Helper-Hashes der genannten Devices) dafür sichtbar verantwortlich ist.

Historie (die mich verwirrt):
Vor ca. 3 Wochen bin ich von 72_FRITZBOX.pm auf 72_FritzSmart.pm umgestiegen (Vorgängermodul lief jahrelang unauffällig, ohne erkennbares Speicherproblem). Meiner Erinnerung nach trat das Speicherwachstum (ca. 190–220 MB/h, linear) erst im Zusammenhang mit dieser Umstellung auf – ich bin mir aber nicht zu 100 % sicher, ob es tatsächlich erst danach begann oder ob es zufällig zeitlich zusammenfiel. Behoben schien es dann durch eine Erhöhung der Ping-Parameter für die lan-ping-Presence-Checks für Android-Smartphones von Default auf -c 3 -w 5. Ich frage die Android-Smartphones über lan-ping und über checkAllFritzMACpresent ab und fasse es über eine structure zusammen. Auch hier kann ich nicht ausschließen, dass stattdessen ein zwischenzeitlicher Neustart die Ursache war. Danach lag das Wachstum bei ca. 8–11 MB/h (deutlich niedriger, aber nicht null).

Heute habe ich ein reguläres update durchgeführt (12 Dateien: fhem.pl, 01_FHEMWEB.pm, 14_SD_RSL.pm, 60_Watches.pm, 72_FritzSmart.pm, 76_SolarForecast.pm, 93_DbLog.pm, 93_DbRep.pm, 98_CDCOpenData.pm, SetExtensions.pm, lib/FHEM/Core/Weather.pm, CHANGED), gefolgt von shutdown restart – und ab der ersten Messung nach dem Neustart war die hohe Rate sofort wieder da.

Meine Frage an euch
1.    Ist ein derartiges lineares Hauptprozess-Wachstum (nicht in RPC-Kindprozessen, nicht in bekannten Helper-Strukturen sichtbar) ein bekanntes Muster, z. B. im Zusammenhang mit fhem.pl-Kernänderungen, FHEMWEB, oder der neuen DbLog-SVG-Subprozess-Architektur?
2.    Gibt es ein empfohlenes Werkzeug/Vorgehen, um Perl-Speicherwachstum im Hauptprozess zu identifizieren, das nicht über %defs-Helper-Hashes sichtbar ist (z. B. Closures, zyklische Referenzen, die vom GC nicht aufgelöst werden)?
3.    Hat jemand mit einer ähnlichen Modulkombination (HMCCU/HMCCURPCPROC + PRESENCE2 + FritzSmart + DOIF in größerer Zahl) etwas Vergleichbares beobachtet?

Für jeden Hinweis bin ich sehr dankbar – auch für Vorschläge, wie ich das systematischer eingrenzen kann als bisher.

[DS_Starter]

Hallo bmwfan,

ich kann deine Beobachtung zum Teil bestätigen wobei 200MB/h wirklich außerordentlich sind. Jedenfalls kann ich sagen, dass es nicht dieses oder jenes eine Modul ist.
Bei mir auf dem Proxmox Cluster laufen einige FHEM Instanzen, jeweils mit mehreren bis vielen Devices von SSCam, DbLog, DbRep, SolarForecast nur um meine eigenen bzw. betreuten zu nennen. Daneben natürlich auch SVG, notify, at, MQTT2 ... und weitere. Ein ganzer Zoo.
Manche Instanzen zeigen Wachstum, andere nicht. Ich habe bis jetzt noch nicht DEN "Schuldigen" identifizieren können. Das Verhalten scheint sich auch manchmal bei einem Neustart zu verändern, sowohl negativ als auch positiv.
Aktuell lasse ich nach und nach alle bei mir eingesetzten Module mit KI-Unterstützung auf Speicherleaks hin untersuchen. Eventuelle Funde bewerte ich nochmal manuell und gebe sie den Maintainern bekannt (zum Beispiel hier).
Möglicherweise lassen sich mit dieser Vorgehensweise diese Probleme finden und reduzieren. Aber es ist ein mühseliges Geschäft ... Ergebnis/Erfolg ungewiß.

LG,
Heiko

[JoWiemann]

Hallo bmwfan,

ich würde mal mit einer frischen Fhem Installation, ohne jegliche Devices, beginnen. Läuft diese unauffällig, dann Device für Device hinzunehmen.

Ich selber habe eine umfangreiche Fhem Installation, u.a. mit FritzSmart und Presence2 laufen. Ein entsprechendes Verhalten zeigt sich bei mir nicht.
Allerdings hatte ich das immer mal wieder sporadisch mit dem RPi 3b+ und konnte auch dort die Ursache nicht finden. Ich habe dann auf einen RPi4 gewechselt und alles ist seid dem gut.

Grüße Jörg

[Guybrush]

hast du zufällig configdb laufen? bei mir sind die beiden fhem Prozesse auch recht groß:

Code Auswählen Erweitern

ps -eo pid,user,%mem,rss,command --sort=-rss | awk 'NR==1 {printf "%-10s %-10s %-6s %-10s %s\n", $1, $2, $3, "RSS(MB)", $5} NR>1 {printf "%-10s %-10s %-6s %-10.2f %s\n", $1, $2, $3, $4/1024, $5}' | head -n 3
PID        USER       %MEM   RSS(MB)    COMMAND
***        fhem       26.8   2167.81    /usr/bin/perl
***        fhem       20.3   1638.27    /usr/bin/perl
***        mysql      14.0   1135.72    /usr/sbin/mariadbd

mag Zufall sein, aber ich meine, dass fhem deutlich genügsamer war bevor ich auf configdb umstellte. Mag sich aber auch zeitlich überschnitten haben.

[bertl]

Hallo bmwfan,

mir ging es genauso, darum bin ich so ähnlich vorgegangen wie es Jörg beschrieben hat.
Ich habe immer 5 Module rausgeschmissen und kontrolliert, ob es noch einen Speicherzuwachs gibt - dann die nächsten 5 - usw. (zeitaufwendig).
Zu guter Letzt blieben bei mir dann SolarForecast, freezemon, speedtest, Installer und DWD_OpenData übrig.
Nachdem ich diese Module nicht wirklich benötige (damals zum Ausprobieren installiert), habe ich auch nicht geprüft welches für den Speicherzuwachs verantworlich war.
Oder vielleicht war es sogar einfach eine Kombination aus einigen Modulen.

Zum Prüfen des Speicherzuwachses habe ich folgendes im Einsatz:

Code Auswählen Erweitern

defmod memUsage dummy
attr memUsage devStateIcon {\
  "<pre>".ReadingsVal( $name,'check','-' )."</pre>"\
}
attr memUsage event-on-change-reading Data_Stack,RSS,Shared,Text,VSZ
attr memUsage event-on-update-reading wert
attr memUsage group RaspberryPi
attr memUsage icon RPi
attr memUsage readingList wert
attr memUsage room system
attr memUsage setList wert
attr memUsage sortby 02_01
attr memUsage userReadings check:wert:\scheck$ {\
  use Memory::Usage;;\
  my $result = "initialized... (".TimeNow().")";;\
\
  # Read result and keep it\
  if( defined( $hash->{helper}{mu} ) ) {\
    $hash->{helper}{mu}->record();;\
    my $state_ref = $hash->{helper}{mu}->state;;\
\
    if( scalar( @$state_ref ) == 2 ) {\
      my ($timestamp1, $message1, $vsz1, $rss1, $shared1, $text1, $data_stack1) = @{$state_ref->[0]};;\
      my ($timestamp2, $message2, $vsz2, $rss2, $shared2, $text2, $data_stack2) = @{$state_ref->[1]};;\
\
      my $timestamp_d = $timestamp2 - $timestamp1;;    # time in seconds between records\
      my $vsz_d = $vsz2 - $vsz1;;                      # virtual memory size\
      my $rss_d = $rss2 - $rss1;;                      # resident set size\
      my $shared_d = $shared2 - $shared1;;             # shared memory size\
      my $text_d = $text2 - $text1;;                   # text (aka code or exe) size\
      my $data_stack_d = $data_stack2 - $data_stack1;; # data and stack size\
      my $mem_vh = sprintf( "%.2f", 100 / 3887992 * $data_stack2 );;\
      my $time1 = substr( FmtDateTime( $timestamp2 ),11,8 );;\
      my $time2 = sprintf( "%02d:%02d:%02d", int( $timestamp_d / 3600 ), int( ( $timestamp_d % 3600 ) / 60 ), $timestamp_d % 60 );;\
      # my $time2 = strftime( '%T', gmtime( $timestamp_d ) );; # if seconds > 1 day (86.400), hours starts with 0\
\
      $result  = sprintf( "Total: Timestamp: %8s, VSZ: %7d, RSS: %7d, Shared: %5d, Text: %5d, Data_Stack: %7d (%6.2f %%)\n",\
                          $time1, $vsz2, $rss2, $shared2, $text2, $data_stack2, $mem_vh );;\
      $result .= sprintf( "Diffs: Timestamp: %8s, VSZ: %7d, RSS: %7d, Shared: %5d, Text: %5d, Data_Stack: %7d (%6.2f %%)",\
                          $time2, $vsz_d, $rss_d, $shared_d, $text_d, $data_stack_d, ReadingsNum( 'sysmon','ram_used_vH',0 ) );;\
\
      readingsBulkUpdate( $hash, "timestamp", $timestamp2 );;\
      readingsBulkUpdate( $hash, "VSZ", $vsz2 );;\
      readingsBulkUpdate( $hash, "RSS", $rss2 );;\
      readingsBulkUpdate( $hash, "Shared", $shared2 );;\
      readingsBulkUpdate( $hash, "Text", $text2 );;\
      readingsBulkUpdate( $hash, "Data_Stack", $data_stack2 );;\
\
      readingsBulkUpdate( $hash, "timestamp_diff", $timestamp_d );;\
      readingsBulkUpdate( $hash, "VSZ_diff", $vsz_d );;\
      readingsBulkUpdate( $hash, "RSS_diff", $rss_d );;\
      readingsBulkUpdate( $hash, "Shared_diff", $shared_d );;\
      readingsBulkUpdate( $hash, "Text_diff", $text_d );;\
      readingsBulkUpdate( $hash, "Data_Stack_diff", $data_stack_d );;\
\
      readingsBulkUpdate( $hash, "MEM_vH", $mem_vh );;\
    }\
  }\
\
  #initiate profiling (again)\
  $hash->{helper}{mu} = Memory::Usage->new();;\
  $hash->{helper}{mu}->record();;\
\
  return $result;;\
}
attr memUsage webCmd wert check
Vielleicht hilft es ja.

Gruß, Robert

[bmwfan]

Hallo und besten Dank für die Informationen und Hilfe,

mein System ist monatelang ohne jegliches Problem gelaufen und ich habe alle paar Wochen ein Update von FHEM gemacht. Da das Problem erst durch den Ausfall von FHEM wegen des Speichermangels aufgetreten ist, kann ich die ursächliche Änderung nicht mehr eindeutig reproduzieren.

Ich weis noch, dass ich, nachdem ich gelesen habe dass es ein Nachfolgemodul von 72_Fritzbox gibt, meine Abfragen der Smartphones auf 72_FritzSmart umgestellt und an den lan-ping etwas geändert habe. Dann war es für mich gut, bis der Speichermangel auftrat und ich mit der KI einen stündlichen Zuwachs von ca. 200 MB ermittelt hatte. Nach einem erneuten Update von FHEM habe ich den Container-Manager und das Container-image (fhem-Main) upgedated. Zwischenzeitlich war der Speicherzuwachs auf ca. 18 MB/h abgesunken und ich dachte, das Problem wäre gelöst ohne wirklich die Ursache gefunden zu haben aber am nächsten oder übernächsten Tag war das NAS wieder im Speicherlimit.

@Heiko: Mit welchen Befehlen forschst Du nach dem Speicherleck? Ich verwende Putty per SSH und könnte es mal so versuchen.
@ Jörg: Das wäre meine letzte Rettung, da ich 444 Device im System habe.
@Guybrush: Nutze ich nicht
@Robert: SolarForecast und DWD nutze ich auch, sind aber monatelang ohne Problem gelaufen wobei es, meine ich, auch bei SolarForecast ein Update gab.

Wenn das Problem tatsächlich je nach Neustart mal auftritt und mal nicht, müsste es ja ein Timing-Problem beim Hochfahren sein und damit wäre es eine Lotterie, ob es mal klappt oder nicht. Schöner Mist aber ich forsche mal weiter. Spiele jetzt Schritt für Schritt die alte Konfiguration, also zuerst FritzSmart zurück auf Fritzbox etc. ein. Mal sehen, ob ich so weiterkomme.

Falls noch jemand Ideen und Ansätze einfallen bitte melden.

Grüße Jürgen

[DS_Starter]

@Heiko: Mit welchen Befehlen forschst Du nach dem Speicherleck?

Ich benutze eine Ganzheitsmethode. Ich stelle der KI das komplette Modul zur Verfügung und "beauftrage" sie den gesamten Code nach potentiellen Speicherleaks zu untersuchen und Fundstellen zu reporten. Die bewerte ich dann manuell denn oftmals werden auch Dinge gespielt, die in der Realität kaum oder keinen Impact haben werden. Sonst wäre diese Aufgabe schier unmöglich zu bewältigen.
Wenn ich kann, erstelle ich einen Patch, der helfen kann das Leakproblem zu lösen.
Manche Leaks kommen nur bei ganz bestimmten Situationen oder Kommunikationsformen im System zum Tragen. Deswegen kann es bei einem Nutzer zu Problemen führen, bei anderen nicht.
Und dann darf man nicht vergessen, dass man ja auch über die myUtils oder Perl-Schnittstellen in Modulen (DOIF, SolarForecast,...) eigenen Code zur Ausführung bringen kann. Auch dort kann man sich unter Umständen problematischen Code selbst einbauen.
Der Königsweg ist leider noch nicht gefunden und es gibt bereits einige Threads im Forum die sich damit beschäftigen. Und Tools, die das Speicherwachstum messen, sind manchmal selbst das Problem. 

Grüße,
Heiko

[Guybrush]

da es mehrere betrifft... vielleicht hat einer ja Lust und Zeit sich mit Devel::Size zu beschäftigen. Ich hab das bei mir gestern mal gemacht:

Code Auswählen Erweitern

sudo apt install libdevel-size-perl

dann in der fhem konsole:

Code Auswählen Erweitern

{ \
    require Devel::Size;;\
    my @x=();;\
    for my $n (keys %defs) { \
        next if ref($defs{$n}{READINGS}) ne "HASH";;\
        my $s=Devel::Size::total_size($defs{$n}{READINGS});;\
        push @x,[$s,$n];;\
    } \
    @x=sort {$b->[0]<=>$a->[0]} @x;;\
    splice(@x,100) if @x>100;;\
    join("\n",map { sprintf("%8.3f MB | %s",$_->[0]/1048576,$_->[1]) } @x) ;;\
}

das war bei mir unauffällig. helper erstmal auch:

Code Auswählen Erweitern

{ \
  require Devel::Size;; \
  my @x = ();; \
  for my $n (keys %defs) { \
    my $h = $defs{$n}{helper};; \
    next if ref($h) ne "HASH";; \
    push @x, [  Devel::Size::size($h), scalar(keys %$h), $n ];; \
  } \
  @x = sort { $b->[0] <=> $a->[0] } @x;; \
  splice(@x, 100) if @x > 100;; \
  join("\n", map { sprintf("%9.1f KB  %6d Einträge  %s", $_->[0] / 1024, $_->[1], $_->[2] )  } @x) \
}

da sind allerdings nicht die verschachtelten Einträge drin. ein query direkt auf helper führt zum Absturz bei mir. Ich vermute gerade, dass das memory leak von apptime kommen kann, was ich bei mir grad ständig am laufen hab. aber da bin ich noch nicht weit gekommen:

Code Auswählen Erweitern

{ \
  my @x = ();; \
  for my $n (keys %defs) { \
    my $bm = $defs{$n}{helper}{bm};; \
    next if ref($bm) ne "HASH";; \
    push @x, [ scalar(keys %$bm),  $n ];; \
  } \
  @x = sort { $b->[0] <=> $a->[0] } @x;; \
  join("\n", map { sprintf("%8d bm-Einträge  %s", $_->[0], $_->[1])  } @x) \
}

vielleicht hat jemand anders Zeit/Lust sich damit weiter zu beschäftigen...

[tomcat.x]

Freezemon (aktuell disable=1)

Gab es da nicht auch mit freezemon selbst ein Problem, dass es sich nicht richtig deaktivieren lässt und weiterhin selbst Speicher verbraucht? Ich habe da von früheren Speicherproblemen und Untersuchungen was im Kopf. Und tatsächlich habe ich ein freezemon Gerät in meiner fhem.cfg, aber nicht einfach disable=1 sondern ausgesternt (falls ich es mal wieder brauche).

[bmwfan]

Danke für den Hinweis! Habe es durch die KI (meine Kenntnisse reichen nicht soweit) nachprüfen lassen, ohne es selber verifizieren zu können. Seht es als Hinweis, falls jemand ähnliche Probleme hat.
----------------
Bei mir ist disable=1 von Anfang an in der fhem.cfg gesetzt (nicht erst nachträglich per set). In dem Fall ruft freezemon_Define() die Funktion, die CallFn/Log3/AnalyzeCommand/HttpUtils_NonblockingGet umhüllt, gar nicht erst auf. Die "Unwrapping ..."-Zeilen, die bei jedem Neustart im Log erscheinen, kommen aus dem Attr()-Callback (wird für jede Attribut-Zeile beim Config-Laden aufgerufen) und sind reine Log-Kosmetik ohne Wirkung, weil intern per if defined(...) geprüft wird, ob überhaupt etwas gewickelt wurde – bei mir eben nie.

Bei mir also entwarnt, mein Wachstum lief bei aktiv laufendem Test (Handy-Presence deaktiviert, HMCCU delayedinit) unverändert weiter. Könnte aber bei jemandem relevant sein, der Freezemon per set ... inactive zur Laufzeit aus- statt von Anfang an per Attribut disabled hat – da wird tatsächlich real gewickelt/entwickelt, und ob das beim Zurücksetzen sauber ist, habe ich (die KI) nicht geprüft.
-------------------

[bmwfan]

So, Schluß für heute. Anbei ein Zwischenstadn,w as alles getestet wurde (falls jemand auf dieselben Probleme stößt. Wieder durch die KI erstellt.
----------------
Zwischenstand zum Speicherleck-Thread

Kurzes Update, da sich seit meinem letzten Beitrag einiges an Ausschlussdiagnostik ergeben hat.

Code-Review statt weiterer Vermutungen: Ich habe 72_FritzSmart.pm über zwei Versionssprünge hinweg (07.09.→11.09.→aktuell 26.09.15) komplett diffed. Keine neuen BlockingCall-Aufrufe, keine wachsenden globalen Strukturen, ein neuer Watchdog-Mechanismus für hängende Kindprozesse ist sauber implementiert (delete() an allen Ausstiegspunkten).

Funktionstest statt Theorie: Eine eigene Utility-Funktion (checkAllFritzMACpresent, fragt FritzSmart-Readings für PRESENCE2 ab) über den einzigen erkennbaren Aufrufpfad 2,5 Stunden komplett deaktiviert (Aufrufzähler nachweislich auf 0 während dieser Zeit) — Wachstumsrate blieb bei den üblichen ~180 MiB/h. Widerlegt.

Devel::Size-Analyse aller Devices: Größte READINGS-Struktur 1,57 MB, größte helper-Struktur 2,5 KB. Bei einem Prozess, der inzwischen mehrere GB groß ist, ist das irrelevant. %defs-Strukturen damit für mich vom Tisch.

HMCCU-Start-Timing getestet: delayedinit=60 gesetzt, RPC-Start technisch nachweislich um ca. 90s statt 5-13s verzögert — Rate danach unverändert bei ~183 MiB/h. Die Boot-Race-Condition-Hypothese (danke an dieser Stelle für den Denkanstoß dazu) trägt bei mir nicht.

Systematischer Gruppentest (Module/DOIF-Gruppen je 1-1,5h deaktiviert, Sicherheitsfunktionen wie Wasserleck-Sensoren dabei außen vor): SolarForecast, alle 3 SSCam-Kameras und 24 Diagnose-/Statistik-DOIFs einzeln durchgetestet — alle drei ohne jeden messbaren Effekt (durchgehend 176-185 MiB/h).

Ein Nebenbefund aus dem SSCam-Test war es wert: Die von mir zuvor beobachteten periodischen Fork-Häufungen (kurzlebige Kindprozesse mit fast identischer Größe zum Hauptprozess) sind eindeutig SSCam zuzuordnen — mit SSCam deaktiviert traten während der gesamten Testdauer keine zusätzlichen Prozesse mehr auf. Das ist aber ein separates Phänomen, nicht die Ursache des linearen Grundwachstums.

Gescheitert: Devel::MAT/pmat-leakreport für einen Heap-Dump-Vergleich. Drei Versuche (bis zu 30 Minuten Laufzeit mit ~99% CPU), keiner lieferte auch nur eine Ausgabezeile. Auf meiner Hardware (Celeron J4125) für einen Heap dieser Größe offenbar nicht praktikabel.

Aktuell laufend: Weiterer Gruppentest, als nächstes die komplette Lichtsteuerung (16 DOIFs, vorab per DEF-Inhalt statt nur Namen verifiziert). Beschattung, Lüftung und HMCCU selbst bewusst für zuletzt aufgehoben.
-----------------

Falls jemand eine Idee hat, wo ich noch nicht gesucht habe, gerne posten.