98_Analyze - Modul zur Systemanalyse (RAM-Verbrauch, Leaks, und mehr)

[DS_Starter]

Hallo zusammen,

ich habe das (neue) Modul 98_Analyze eingecheckt und ist morgen früh im Update enthalten.
Es gab es bereits schon seit langer Zeit in meinem contrib in einer Alpha-Version. Ich habe es nun komplett erneuert und erweitert.
Dieses Modul gehört zu dem Trio von FHEM System Management Modulen:

- Installer
- MemSaver
- Analyze


Was macht das Modul und wie hilft es:

Analysiert den Speicherverbrauch des FHEM-Prozesses: die Größe von Devices und ihrer Teilstrukturen, von Modul-Hashes und von den Kern-Hashes von FHEM, den Prozessspeicher, Timer, Filedeskriptoren und Kindprozesse. Snapshots können gespeichert und miteinander verglichen werden. Strukturen, die über die Zeit kontinuierlich wachsen, werden als Speicherleck-Kandidaten gemeldet. Das Modul hilft dabei, das Device, das Modul oder die Datenstruktur zu finden, die für einen wachsenden Speicherverbrauch verantwortlich ist.
Analyze ist einer von mehreren Bausteinen für die Systempflege und Analyse: MemSaver hält den RAM von FHEM so weit wie möglich sauber und klein, Analyze zeigt, wo der Speicher verwendet wird und welches Modul, Device oder welche Datenstruktur für sein Wachstum verantwortlich ist, und Installer sorgt für saubere Installationen und Updates der Perl-Pakete, die FHEM-Module benötigen, einschließlich der Voraussetzungen dieses Moduls.
Alle Messungen laufen in einem eigenen Prozess (BlockingCall). FHEM wird nicht blockiert, und ein Absturz von Devel::Size bei einem einzelnen Device reißt FHEM nicht mit.


Grundlagen

- Analyze misst und berichtet nur, es gibt keinen Speicher frei. Um den RAM klein zu halten, dient MemSaver.

- Der eigene Prozess ist eine Kopie von FHEM zum Zeitpunkt des Aufrufs. Alle Größen beschreiben deshalb genau diesen Zeitpunkt.

- Größen werden exklusiv gezählt: Jede Speicheradresse wird nur einmal gezählt, Referenzen auf andere Devices (zum Beispiel IODev) und auf die Kern-Hashes von FHEM werden nicht verfolgt. Anders als bei Devel::Size::total_size wird nichts doppelt gezählt, die Größen der Devices lassen sich also addieren. Die Werte sind Näherungen mit wenigen Prozent Abweichung.

- Die Snapshot-Ablage des Moduls selbst wird nicht mitgemessen, sonst würde das Modul immer als wachsendes Objekt erscheinen.

- Die Summe aller gemessenen Strukturen wird als attributed (zugeordnet) ausgewiesen. Der Rest der Prozessgröße (rss) erscheint als not attributable (nicht zuordenbar). Er besteht aus dem Perl-Interpreter, geladenem Programmcode, Shared Libraries, Speicherfragmentierung und - ohne deepScan - den file-scope Variablen der Module.

- Die Prozessgröße (rss) wächst nach dem Start von FHEM üblicherweise, bis der Perl-Speicher "warmgelaufen" ist, und schrumpft danach selten. Snapshots sollten deshalb nach einigen Stunden Laufzeit erstellt werden.

-  private, pss und shared ändern sich immer dann, wenn Kindprozesse (BlockingCall) starten oder enden. Für Trends wird rss verwendet, die anderen Werte sind nur bei gleicher Anzahl Kindprozesse vergleichbar.


Typischer Ablauf zur Analyse:

    set <name> snapshot t0
    ... einige Stunden warten ...
    set <name> snapshot t1
    get <name> diff t0 t1 - was hat sich zwischen zwei Snapshots verändert
    get <name> leakCandidates - ab 3 Snapshots: Objekte, die kontinuierlich wachsen
    set <name> xHashDetail $defs{myDevice}{helper} - ein auffälliges Objekt genauer ansehen

    Alternativ erstellt attr <name> autoSnapshot 6 automatisch alle 6 Stunden einen Snapshot.


Voraussetzungen:

- Devel::Size - zwingend erforderlich. Ohne dieses Modul kann kein Device angelegt werden.
- Optional: PadWalker - damit erfasst deepScan auch die file-scope my Variablen der Modul-Dateien. Ob es verfügbar ist, zeigt das Internal PADWALKER.
- Die Perl-Module Storable, MIME::Base64, Scalar::Util, Time::HiRes, POSIX und B (alle Bestandteil von Perl) sowie das FHEM-Modul Blocking.



Ich hoffe, dass dieses Modul hilfreich sein wird Module und Strukturen zu finden, die zu einem stetig steigenden Speicherverbrauch beitragen und wie hoch dieser Anteil ist. Manche Module können durch Datensammlung Speicher akkumulieren was in diesen Fällen keinen Fehler darstellt. Die stetigen Anteile sollten allerdings gering sein nachdem FHEM nach dem Systemstart ein Plateau erreicht hat und alle Strukturen für den normalen Betrieb geladen wurden.
Durch regelmäßige Snapshots kann man das Speicherwachstum zu bestimmten Zeiten (z.B. Tageswechsel) analysieren.
Über die Snapshots lässt sich das Speicherwachstum über einen längeren Zeutraum verfolgen.

Im Anhang eine Beispielausgabe von "get ... leakCandidates".


LG,
Heiko

[Nobbynews]

Hallo Heiko,

ich habe mal Dein neues Modul installiert und hier ein Ergebnis.
Würdest Du das schon als Speicher-Leak bezeichnen?
deepScan habe ich aktiviert.

Code Auswählen Erweitern

Leak candidates: objects growing in at least 12 of 15 intervals without ever shrinking
Snapshots: auto_20261107_185930, auto_20261107_215809, auto_20261108_005809, auto_20261108_035809, auto_20261108_065809, auto_20261108_095809, auto_20261108_125809, auto_20261108_155809, auto_20261108_185809, auto_20261108_215809, auto_20261109_005809, auto_20261109_035809, auto_20261109_065809, auto_20261109_095809, auto_20261109_125809, auto_20261109_155809   period: 45.0 h

Parts of devices ($defs{device}{key}):
     +286.9 kB  $defs{FritzOG}{fhem}                          74.8 kB -> 93.3 kB -> 111.4 kB -> 127.5 kB -> 141.9 kB -> 164.7 kB -> 178.2 kB -> 193.9 kB -> 211.0 kB -> 229.0 kB -> 247.2 kB -> 279.1 kB -> 298.9 kB -> 319.6 kB -> 341.0 kB -> 361.7 kB  (6.4 kB/h)
     +279.0 kB  $defs{FritzWohnzimmer}{fhem}                  108.5 kB -> 132.4 kB -> 149.5 kB -> 165.8 kB -> 189.2 kB -> 203.5 kB -> 218.3 kB -> 234.0 kB -> 250.3 kB -> 265.4 kB -> 298.5 kB -> 314.6 kB -> 333.6 kB -> 351.6 kB -> 369.2 kB -> 387.5 kB  (6.2 kB/h)
      +35.2 kB  $defs{FritzBox}{fhem}                         82.9 kB -> 92.1 kB -> 94.7 kB -> 97.2 kB -> 99.2 kB -> 101.3 kB -> 102.9 kB -> 104.7 kB -> 106.4 kB -> 108.0 kB -> 109.9 kB -> 111.3 kB -> 113.0 kB -> 114.7 kB -> 116.4 kB -> 118.1 kB  (800 B/h)
      +28.9 kB  $defs{FritzDach}{fhem}                        71.1 kB -> 73.0 kB -> 74.7 kB -> 76.7 kB -> 78.4 kB -> 80.6 kB -> 84.3 kB -> 86.0 kB -> 87.8 kB -> 89.5 kB -> 91.2 kB -> 93.0 kB -> 94.9 kB -> 96.6 kB -> 98.3 kB -> 100.0 kB  (657 B/h)

Devices:
     +290.8 kB  FritzOG                                       203.1 kB -> 223.4 kB -> 241.5 kB -> 259.2 kB -> 272.5 kB -> 295.8 kB -> 309.9 kB -> 325.5 kB -> 342.1 kB -> 360.1 kB -> 378.8 kB -> 410.8 kB -> 430.5 kB -> 449.5 kB -> 471.0 kB -> 493.9 kB  (6.5 kB/h)
     +274.5 kB  FritzWohnzimmer                               242.3 kB -> 263.9 kB -> 281.0 kB -> 295.6 kB -> 319.6 kB -> 335.0 kB -> 348.7 kB -> 365.0 kB -> 381.8 kB -> 396.4 kB -> 429.5 kB -> 445.6 kB -> 465.1 kB -> 480.9 kB -> 498.5 kB -> 516.8 kB  (6.1 kB/h)
      +29.5 kB  FritzDach                                     173.9 kB -> 175.7 kB -> 177.4 kB -> 180.0 kB -> 181.1 kB -> 183.8 kB -> 187.0 kB -> 188.7 kB -> 191.1 kB -> 192.2 kB -> 194.0 kB -> 195.7 kB -> 198.1 kB -> 199.9 kB -> 201.6 kB -> 203.3 kB  (670 B/h)

Device types (sum of devices):
     +636.4 kB  FritzSmart                                    1.19 MB -> 1.25 MB -> 1.29 MB -> 1.33 MB -> 1.36 MB -> 1.41 MB -> 1.44 MB -> 1.48 MB -> 1.52 MB -> 1.55 MB -> 1.60 MB -> 1.65 MB -> 1.70 MB -> 1.73 MB -> 1.77 MB -> 1.82 MB  (14.2 kB/h)

Interpretation:
  part/dev/type  : data inside a device grows (readings, helper hashes, queues, caches) -> look at the TYPE and use "set  xHashDetail \$defs{device}{key}".
  var/pkgvar/file: global or file-scope variables of a module grow (needs deepScan, PadWalker for file-scope variables).
  timer/timerdev : timers accumulate -> a module sets timers without removing old ones.
  cnt fds/kids   : file descriptor or child process leak (e.g. BlockingCall children not ending).
  proc unattributed grows but no structure does: memory outside the walked structures (XS/C libraries, fragmentation, file-scope variables without deepScan).

OK
Diff der beiden letzten Snapshots:

Code Auswählen Erweitern

count_fds
299
2026-11-09 15:58:15
count_kids
1
2026-11-09 15:58:15
count_timers
230
2026-11-09 15:58:15
crashListCount
0
2026-11-07 18:57:50
proc_private_kB
53540
2026-11-09 15:58:15
proc_pss_kB
166748
2026-11-09 15:58:15
proc_rssPeak_kB
284520
2026-11-09 15:58:27
proc_rssTrend_kBperHour
687.7
2026-11-09 15:58:27
proc_rss_kB
284520
2026-11-09 15:58:27
proc_swap_kB
0
2026-11-09 15:58:15
snapshot_last
auto_20261109_155809
2026-11-09 15:58:15
snapshots
16
2026-11-09 15:58:15
state
done
2026-11-09 15:58:15
unattributed_kB
240991
2026-11-09 15:58:15
myAnalyze
room
System
Attributes
autoSnapshot
3
deleteattr
deepScan
1
deleteattr
maxSnapshots
17
deleteattr
room
System
deleteattr
Help for Analyze Copy for forum.fhem.de Raw definition Select icon Extend devStateIcon Event Monitor (filtered) Delete myAnalyze

 
Comparison 'auto_20261109_125809' -> 'auto_20261109_155809'   period: 3.00 h

Process memory:
  rss            279968 kB ->   282268 kB      +2300 kB  (+767 kB/h)
  anon           267732 kB ->   270032 kB      +2300 kB  (+767 kB/h)
  pss            161956 kB ->   166748 kB      +4792 kB  (+1597 kB/h)
  priv            46256 kB ->    53540 kB      +7284 kB  (+2428 kB/h)
  shared         233712 kB ->   228728 kB      -4984 kB  (-1661 kB/h)
  swap                0 kB ->        0 kB         +0 kB  (+0 kB/h)
  attributed       +143 kB   (attributed to FHEM structures)
  unattributed    +2157 kB   (rest: interpreter, code, fragmentation, file-scope variables)

Counters:
  defs       1160 ->   1157  (-3)
  fds         302 ->    299  (-3)
  kids          1 ->      1  (+0)
  ready         0 ->      0  (+0)
  select       57 ->     54  (-3)
  timers      237 ->    230  (-7)

Timers by function - growth (top 15):
            +1  BlockingKill  (1 -> 2)
            +1  CUL_MAX_SQH  (0 -> 1)

Timers by device - growth (top 15):
            +1  cm  (2 -> 3)

Readings per device - growth (top 15):
            +4  FritzOG  (80 -> 84)
            +1  FritzBox  (157 -> 158)
            +1  MQTT2_Server_192.168.2.217_14887  (0 -> 1)
            +1  MQTT2_Server_192.168.2.217_23695  (0 -> 1)
            +1  MQTT2_Server_192.168.2.217_5254  (0 -> 1)
            +1  MQTT2_Server_192.168.2.217_5887  (0 -> 1)
            +1  telnetPort_127.0.0.1_48906  (0 -> 1)

Parts of devices ($defs{device}{key}) - growth (top 15):
      +20.7 kB  $defs{FritzOG}{fhem}  (341.0 kB -> 361.7 kB)
      +18.3 kB  $defs{FritzWohnzimmer}{fhem}  (369.2 kB -> 387.5 kB)
       +2.3 kB  $defs{FritzOG}{READINGS}  (45.7 kB -> 48.0 kB)
       +2.0 kB  $defs{cm}{sendQueue}  (0 B -> 2.0 kB)
       +1.7 kB  $defs{FritzDach}{fhem}  (98.3 kB -> 100.0 kB)
       +1.7 kB  $defs{FritzBox}{fhem}  (116.4 kB -> 118.1 kB)
       +1.4 kB  $defs{MQTT2_Server_192.168.2.217_14887}{subscriptions}  (0 B -> 1.4 kB)
       +1.4 kB  $defs{MQTT2_Server_192.168.2.217_23695}{subscriptions}  (0 B -> 1.4 kB)
       +1.4 kB  $defs{MQTT2_Server_192.168.2.217_5254}{subscriptions}  (0 B -> 1.4 kB)
       +1.4 kB  $defs{MQTT2_Server_192.168.2.217_5887}{subscriptions}  (0 B -> 1.4 kB)
       +1.2 kB  $defs{diULANZI}{helper}  (3.0 kB -> 4.2 kB)

Devices - growth (top 15):
      +23.0 kB  FritzOG  (471.0 kB -> 493.9 kB)
      +18.3 kB  FritzWohnzimmer  (498.5 kB -> 516.8 kB)
       +6.1 kB  MQTT2_Server_192.168.2.217_14887  (0 B -> 6.1 kB)
       +6.1 kB  MQTT2_Server_192.168.2.217_23695  (0 B -> 6.1 kB)
       +6.1 kB  MQTT2_Server_192.168.2.217_5254  (0 B -> 6.1 kB)
       +6.1 kB  MQTT2_Server_192.168.2.217_5887  (0 B -> 6.1 kB)
       +3.2 kB  telnetPort_127.0.0.1_48906  (0 B -> 3.2 kB)
       +2.2 kB  FritzBox  (288.2 kB -> 290.4 kB)
       +1.9 kB  cm  (5.8 kB -> 7.7 kB)
       +1.7 kB  FritzDach  (201.6 kB -> 203.3 kB)
       +1.2 kB  diULANZI  (30.9 kB -> 32.1 kB)

Device types (sum of devices) - growth (top 15):
      +44.5 kB  FritzSmart  (1.77 MB -> 1.82 MB)
      +18.6 kB  MQTT2_SERVER  (713.5 kB -> 732.1 kB)
       +1.9 kB  CUL_MAX  (5.8 kB -> 7.7 kB)

Number of devices per type - growth (top 15):
            +3  MQTT2_SERVER  (30 -> 33)

File-scope variables of module files (PadWalker) - growth (top 15):
     +144.4 kB  01_FHEMWEB.pm  %FW_svgData  (12.18 MB -> 12.32 MB)

Module files (file-scope variables, PadWalker) - growth (top 15):
     +144.1 kB  01_FHEMWEB.pm  (13.11 MB -> 13.25 MB)

Hint: for a reliable verdict take at least 3 snapshots some hours apart and use "get  leakCandidates".
Einen Screenshot zur Speicherauswertung habe ich mal angehängt.
Dasuntere Diagramm kommt von sysmon.

[DS_Starter]

Ich würde mal sagen, dass es ein Leak gibt. Wobei in 45h der Anstieg mit 636kB in den Perl Strukturen recht übersichtlich ist.
Abhängig vom Zeitpunkt des FHEM Starts kann dieses Wachstum aber auch ein ganz normaler Vorgang bis zu einer Plateau Bildung sein.
Hier kommt es auf eine Langzeitbeobachtung an. Wenn das Wachstum nie aufhört ist der Leak bestätigt.
Es ist natürlich immer die Frage wie störend es ist. Es gibt User die quälen sich mit Wachstumsraten von mehreren MB pro Stunde herum und müssen ihr System recht kurzfristig
immer neu starten. Das sind dann die echten Leak-Kandidaten. 

Allerdings sieht dein RSS-Stand recht stark steigend aus, ca. 15MB in dem dargestellten Zeitraum wenn ich es richtig interpretiere. Insbesondere ab 15:10. Vielleicht kommt dann jemand nach Hause?
Das ist schon deutlich, wobei diese Steigung nicht aus den Perl-Strukturen zu kommen scheint sonst würde Analyse andere Werte zeigen. Möglicherweise werden auch Daten in Abhängigkeit von bestimmten Sachverhalten gecacht, ich kenne das Modul nicht. Dann wäre der Anstieg ein Teil der Funktionalität (bei mir ist SolarForecast so ein Modul),
Der diff ist übrigens sehr schwer zu lesen. Ein Screenshot ist bei dem Modul besser geeignet.

In der Summe würde ich sagen, ja ein Leak ist wahrscheinlich. Aber wegen der geringen Datenmenge vermutlich nicht störend.
Eventuell liegt eine Ursache in verwendeten XS/C Modulen. Interessant ist, dass nur Fritz Devices erscheinen. Welche Module nutzt du? -> fheminfo zeigt alles.

[Nobbynews]

Da läuft natürlich noch mehr:

Code Auswählen Erweitern

System Info
ConfigType: configFile
SVN rev: 31877
OS: linux
Perl: 5.36.0
uniqueId: 86c...
 
Modules Model Count
APCUPSD
Back-UPS ES 700G 2
Analyze 1
Astro 1
BRAVIA 1
KD-43XH8505 1
CUL
CUL 2
CUL_MAX 1
CUL_TCM97001
Mebus 2
CUL_WS 1
Calendar 3
DOIF
FHEM 34
DOIFtools 1
ESPEasy 37
EnOcean 2
Eltako_FT55 2
FHEM2FHEM 2
FHEMWEB 3
FS20 15
fs20di 3
fs20s20 1
fs20st 2
fs20st2 1
fs20su 3
FileLog 241
FritzSmart
FRITZ!Box 7590 1
FRITZ!Repeater 2400 2
FRITZ!WLAN Repeater 1750E 2
FRITZ!WLAN Repeater 450E 1
HTTPMOD
clever_tanken_single_station 8
Hideki 6
HourCounter 6
IPCAM 1
IT 22
itremote 6
Installer 1
IrBlaster 1
JsonMod 1
LightScene 1
MAX
HeatingThermostat 7
MQTT2_CLIENT 1
MQTT2_DEVICE 26
SHCB-1 1
SHDW-2 1
SHPLG-S 4
SHPLG2-1 2
SHSW-1 1
eBus_daemon_splitter 1
tasmota_POW 3
tasmota_basic_state_power1 8
zigbee2mqtt_2channel_split 2
zigbee2mqtt_ContactSensor 2
zigbee2mqtt_Light_Intensity_Sensor 1
zigbee2mqtt_Rain_Illuminance_Sensor 1
zigbee2mqtt_TempHumSensor 7
zigbee2mqtt_Water_Leak_Sensor 1
zigbee2mqtt_Wireless_Button 2
zigbee2mqtt_bridge 1
zigbee2mqtt_human_body_movement 3
zigbee2mqtt_plug 4
zigbee2mqtt_plug_w_energy_measuring 7
zigbee2mqtt_scene_controller 1
zigbee2mqtt_smokeDetector 7
MQTT2_SERVER 1
MQTT_GENERIC_BRIDGE 1
MemSaver 1
Modbus 1
ModbusSDM120 1
ModbusSDM72DMV2 1
PID20 4
PRESENCE2
daemon 1
lan-ping 9
SD_RSL 28
SD_WS
SD_WS_107_H 6
SD_WS_27_TH 1
SIGNALduino 3
SVG 188
SYSMON 1
Shelly
generic 1
shelly1 1
shelly1pm 1
shellybulb 1
shellydimmer 1
shellyplug 16
ShellyMonitor 1
TCM
ESP3 1
THRESHOLD 1
TelegramBot 1
WS980 1
WeekdayTimer 11
ZWDongle 1
ZWave
0109-201c-1c03 1
0403-0003-0003 1
Aeotec Limited ZW175 Smart Switch 7 1
Aeotec Limited ZWA021 Thermostatic Valve 1
EUROtronic EUR_SPIRITZ Wall Radiator Thermostat 3
FIBARO System FGWPE/F Wall Plug Gen5 1
HANK Electronics Ltd HKZW-DWS01 Door/Window Sensor 3
Shelly Qubino Wave 1PM 1
Steinel IS140-2 1
at 32
autocreate 1
cmdalias 1
dewpoint 3
dummy 57
eventTypes 1
freezemon 1
holiday 1
logProxy 1
notify 112
readingsGroup 4
readingsWatcher 1
sequence 2
structure 17
telnet 1
watchdog 66
weblink 1
weekprofile 2
Ich habe jetzt mal largeObjectNum auf 10 hochgesetzt.
Noch tut mir der Speicherverbrauch nicht weh. Ist ein Pi4 mit 8 GB und Bookworm.
War mir halt immer mal wieder aufgefallen und da kam mir das Modul gerade recht.

Tatsächlich bin in um den Dreh rum nach Hause gekommen. Allerdings war vor mir schon jemand wieder als anwesend erkannt. Dürfte also soviel nicht ausgemacht haben. Durch die Anwesenheit werden aktuell hauptsächlich die Heizkörper hochgefahren und einige Steckdosen eingeschaltet.

[DS_Starter]

Das sind eine ganze Menge und unterstreicht eigentlich den Anteil von Fritz am Speicherwachstum.

Du kannst dir auch dein am meisten beteiligtes Device nehmen und genauer analysieren:

Code Auswählen Erweitern

set ... xHashDetail $defs{FritzOG}
In den Readings (refresh) siehst du die größten Objekte, ganz oben das größte, z.B.:

Code Auswählen Erweitern

01_largestObject  1707646, $defs{SolCast}{.tsCache}

Du kannst weiter reingehen:

Code Auswählen Erweitern

set ... xHashDetail $defs{SolCast}{.tsCache}
und bekommst wiederum die größte Unterstruktur:

Code Auswählen Erweitern

01_largestObject  1165956, $defs{SolCast}{.tsCache}{data}

Das kann man fortführen bis zur letzten Ebene, den eigentlichen Werten. Hier im Beispiel wäre es:

Code Auswählen Erweitern

01_largestObject  1535, $defs{SolCast}{.tsCache}{data}{TSO::SolCast::1794178800::10677}


Das ist ein gecachter Wert mit 1,5kB Größe. Die hohe Anzahl der gecachten Werte + der Verwaltungsinformationen macht dann die Größe von $defs{SolCast}{.tsCache}{data} aus.

Vielleicht baue ich noch eine Snapshot Variante ein, mit der man ein spezifisches Objekt über einen längeren Zeitraum snappen und so dessen Entwicklung nachverfolgen kann.
Das kann auch sehr hilfreich sein.

[JoWiemann]

Hallo DS_Starter, hallo Nobbynews,

als Maintainer des Moduls 72_FritzSmart habe ich 8 Devices mit unterschiedlichen Fritz Geräten in meiner Installation laufen. Ich kann keinerlei Speicher "Verbrauch" feststellen.

Für mich wäre List vom Device FritzOG interessant, sofern es nicht ein FBDect Device ist.

Grüße Jörg

[DS_Starter]

Hi Jörg,

das glaube ich dir. Es gibt sicherlich mehr als eine Handvoll Möglichkeiten weshalb bei einem User ein steigender Speicherverbrauch feststellbar ist und  bei einem anderen nicht.
Wir suchen ja bereits seit Jahren nach dem Stein der Weisen. 
Es können bestimmte Arbeitsmodi sein die Speichermehrverbräuche verursachen oder z.B. bestimmte Versionen der benutzen Perl-Pakete und Version/OS-Kombinationen. Die Perl-Pakete können ihrerseits Speicherprobleme verursachen die wir nicht beeinflussen können. Gerade XS-Pakete mit der engen Verknüpfung zum OS könnten m.M. nach unterschiedliche Verhaltensweisen verursachen.
Insbesondere wenn sie nicht aktuell sind und vllt. Leakprobleme haben die in neueren Versionen behoben wurden.
Deswegen wäre ein Punkt mit dem Installer (get showModuleInfo) zu prüfen, ob neuere Versionen der geladenen Pakete verfügbar sind und sie zu aktualisieren.

LG,
Heiko