Hallo zusammen,
ich möchte euch heute ein neues Modul vorstellen: 98_MemSaver
Viele von uns kennen das Verhalten: FHEM läuft tagelang durch, verarbeitet speicherintensive Aufgaben (z.B. Plots, HTTP-Requests oder JSON-Parsing) und der Arbeitsspeicher (RSS) wächst kontinuierlich an. Das liegt oft daran, dass die Speicherverwaltung der C-Standardbibliothek (`glibc`) einmal reservierten Speicher nicht automatisch wieder an das Betriebssystem zurückgibt, selbst wenn Perl ihn intern längst freigegeben hat.
#### 1. Zweck des Moduls
Der Hauptzweck von 98_MemSaver ist es, periodisch ungenutzte Speicherarenen der `glibc` über die Systemfunktion `malloc_trim` direkt an das Linux-Betriebssystem zurückzugeben. Zusätzlich dient es als leichtgewichtiges System-Monitoring für den FHEM-Prozess sowie die CPU- und Swap-Auslastung.
#### 2. Was kann das Modul und wie hilft es dem Nutzer?
* Speicherfreigabe: Ruft regelmäßig die `glibc`-Funktion `malloc_trim` auf, wodurch nicht mehr benötigter RAM sofort wieder dem Betriebssystem zur Verfügung steht.
* Detaillierte RAM-Analysen: Stellt präzise Speicher-Readings bereit, um das Speicherverhalten von FHEM transparent zu machen:
* `mem_rss_mb` (Physisch belegter Arbeitsspeicher / Resident Set Size)
* `mem_hwm_mb` (High Water Mark – Peak-Speicherverbrauch seit Prozessstart)
* `mem_pss_mb`, `mem_private_mb`, `mem_shared_mb` & `mem_vsize_mb`
* `trim_last_freed_mb` (Menge des beim letzten Durchlauf tatsächlich freigegebenen Speichers)
* Swap-Monitoring: Überwacht ausgelagerte Speicherseiten des FHEM-Prozesses (`swap_process_total_mb`, `swap_process_delta_mb`) sowie systemweite Swap-Aktivitäten (`swap_sys_in_mb`, `swap_sys_out_mb`).
* CPU & Laufzeit-Readings:
* `cpu_load1` (1-Minuten Load-Average)
* `cpu_usage_pct` (prozentuale CPU-Auslastung über das eingestellte Intervall)
* `fhem_uptime` / `fhem_uptime_sec` & `fhem_start_time`
Wie hilft es konkret?
* Verhindert unnötiges RAM-Wachstum: Hält den Footprint von FHEM schlank, was besonders auf Systemen mit begrenztem RAM (z. B. Raspberry Pi) hilfreich ist.
* Frühwarnsystem: Durch die Aufteilung in Private-, Shared- und Swap-Readings lässt sich genau diagnostizieren, ob FHEM tatsächlich ein echtes Memory-Leak hat oder nur Fragmente im Heap liegen.
#### 3. Grenzen – Was kann das Modul NICHT leisten?
* Kein Fix für echte Memory-Leaks: Wenn ein Perl-Modul oder ein eigenes Skript Daten dauerhaft in globalen Variablen/Hashes ansammelt (echtes Speicherleck), kann `malloc_trim` diesen Speicher **nicht** freigeben, da er aus Sicht von Perl/glibc noch in Verwendung ist.
* Nur für Linux: Das Modul setzt das Linux-`/proc`-Dateisystem voraus und läuft ausschließlich auf Linux-Systemen.
* Keine Ausführung auf Windows/macOS: Unter anderen Betriebssystemen bricht die Definition mit einer entsprechenden Meldung ab.
* C-Bibliothek notwendig: Für den Aufruf von `malloc_trim` wird das Perl-Modul `FFI::Platypus` benötigt.
#### 4. Installation & Einrichtung
**Voraussetzung:**
Auf Betriebssystemebene muss einmalig das Paket `libffi-platypus-perl` installiert werden:
sudo apt install libffi-platypus-perlAlternativ Nutzung des FHEM Installers (Modul).
**Definition in FHEM:**
define myMemSaver MemSaver [Intervall_in_Sekunden]
Beispiel:
define Saver MemSaver 900
Das Modul wird morgen früh über das Standardupdate ausgeliefert, befindet sich aktuell in meinem Contrib (Fußtext) wer es bereits ausprobieren möchte.
Über Rückmeldungen, Tests und Erfahrungswerte aus eurer Praxis freue ich mich!
Viele Grüße,
Heiko
Kurzanleitung für die Linux-User solange es noch nicht offiziell geworden ist.... ;)
sudo apt update
sudo apt install libffi-platypus-perl
cd /opt/fhem/FHEM/
sudo wget https://svn.fhem.de/trac/export/31726/trunk/fhem/contrib/DS_Starter/98_MemSaver.pm
sudo chown fhem:dialout 98_MemSaver.pm
reload 98_MemSaver
defmod Saver MemSaver 300
attr Saver alias Speicherfreigabe
attr Saver devStateIcon disabled:10px-kreis-gelb active:10px-kreis-gruen
attr Saver disable 0
attr Saver icon it_memory
attr Saver room Dienste->Allgemein
attr Saver verbose 3
Alternativ, wer evtl. schon "libffi-platypus-perl" installiert hat reicht:
in FHEM oben einfach eingeben / hiermit laden / aktualisieren:
"wget -qO ./FHEM/98_MemSaver.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/98_MemSaver.pm"
Prima Modul, danke!
Macht der MemSaver die Parametrisierung via MALLOC_MMAP_THRESHOLD_ (von hier: https://forum.fhem.de/index.php?msg=1369532 ) dann überflüssig?
ZitatMacht der MemSaver die Parametrisierung via MALLOC_MMAP_THRESHOLD_ (von hier: https://forum.fhem.de/index.php?msg=1369532 ) dann überflüssig?
Im Prinzip ja, aber die Parametrisierung und das Modul ergänzen sich optimal.
Ohne die Umgebungsvariablen erledigt malloc_trim im MemSaver die Arbeit — aber erst beim nächsten Zyklus (alle <Interval> Sekunden). In der Zwischenzeit sitzt der freigegebene Speicher nutzlos in der Arena.
Mit den Variablen werden große Blöcke sofort zurückgegeben, malloc_trim räumt dann nur noch die kleinen brk-Reste auf.
Empfehlung: Die Variablen behalten wenn du sie drin hast - sie reduzieren den RSS kontinuierlich zwischen den MemSaver-Zyklen. malloc_trim ist die periodische Tiefenreinigung, MALLOC_MMAP_THRESHOLD_ die laufende Hygiene.
Ich habe in dem Modul noch eine automatische Leak vs.Fragmentierung-Erkennung eingebaut.
Das Reading leak_status zeigt schnell den wahrscheinlichen Zustand des Systems:
initializing: Es sind noch weniger als 3 Messwerte vorhanden.
collecting_data: Der Messzeitraum ist noch kürzer als 5 Minuten (noch keine zuverlässige Trendanalyse möglich).
ok: Normales Speicherverhalten, kein bedrohlicher Anstieg erkennbar.
fragmentation_cleared: malloc_trim konnte erfolgreich signifikant RAM (> 5 MB) an das Betriebssystem zurückgeben. Der Anstieg lag also nur an Heap-Fragmentierung.
potential_leak_warning: Der Speicher wächst kontinuierlich (> 20 MB/h Trend) und malloc_trim konnte kaum Speicher freigeben (< 1 MB). Es könnte ein langsames Memory-Leak vorliegen.
leak_suspected: Sehr starker Speicherspreizungs-Trend (> 50 MB/h). Dringender Verdacht auf ein Speicherleck in einem geladenen Modul.
Nach meinen bisherigen Erkenntnissen wird der steigende RAM-Verbrauch bei FHEM meistens durch eine Überlagerung von Speicherfragmentierung und echten Speicherleaks verursacht. Bisher war es extrem schwer, beides voneinander zu unterscheiden.
Das Modul bringt hier nun mehr Sichtbarkeit rein:
- Fragmentierung (freie, aber vom OS nicht nutzbare Heap-Bereiche) wird aktiv abgeräumt.
- Echte Leaks (unveränderte Speicherbindung im Perl-Code) bleiben trotz Bereinigung sichtbar.
Dadurch kann man nun gezielt testen: Werden verdächtige Module testweise deaktiviert, lässt sich über das Reading leak_status sowie den Drift-Trend sofort erkennen, ob der Verursacher getroffen wurde. Das erleichtert die Eingrenzung und Fehlersuche enorm.