Speicherverbrauch / Nach Modul erkennbar

Begonnen von skynet, 15 September 2019, 20:17:40

Vorheriges Thema - Nächstes Thema

skynet

Ich habe gesucht aber nicht wirklich gefunden.
Seit ca. 1 Woche (ich hab einen Update Abend gemacht) Ubuntu Basis System und FHEM aktualsiert, schraubt sich FHEM über Nacht von 1 auf 8GB hoch.

Dann kommt ein -> Cannot fork: Cannot allocate memory
Das habe ich für den Übergang abgefangen mit einen automatischen Neustart.

Ich sehe aber nicht welches der Module für den Speicherverbrauch zuständig ist.
Ich habe den OWS in Verdacht. Gibt es eine Möglichkeit den Speicherverbrauch einzelner Module zu loggen ?
Ansonsten muss ich auf dem Produktiv-System einzelne Module wie MQQT / Unifi / OneWire deaktivieren ?

Freue mich über jeden Hinweis ;-)

MadMax-FHEM

Mit genau dieser Meldung "Cannot fork: Cannot allocate memory" in der Forumssuche einige Threads finden die das Problem diskutieren, Möglichkeiten zur Lecksuche/findung nennen, mögliche Lösungen "prophezeien", usw.

Z.B.:

https://forum.fhem.de/index.php/topic,84372.msg971937.html#msg971937

https://forum.fhem.de/index.php/topic,39887.msg328523.html#msg328523

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

skynet

Vielen Dank.
Ja, die habe ich auch gesehen.
Ich hoffte auf eine Funktion in der ich die internen Verbrauche abfragen kann.
Aber dann nutze ich die vorhandenen Daten ...

MadMax-FHEM

Aber in einem der Threads wird doch von Rudi erläutert was man tun kann...

Bzw. ist halt alles etwas rätselhaft...
...soll heißen eine Lösung gibt es wohl (noch) nicht...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

skynet

Ja, vielleicht nicht so einfach wie eine simple Liste mit Speicherangaben ;-)

Ich habe übrigens meine  74_Unifi_Switch.pm in Verdacht.
Bin mal gespannt ob der Verdacht stimmt ...

MadMax-FHEM

Da kann ich (leider) nur sagen:

"jeder" hat "was anderes" im Verdacht...

Es hängt halt von vielen Faktoren ab:

Perl Version

fhem Version

verwendete Module bzw. welche Per-Libs die jeweiligen Module wie verwenden...

UnifiController/Client läuft bei mir auf meinem "Speichertestsystem" unbeeindruckend...
Ich glaube Switch hab ich nicht in Verwendung (müsste ich nachschauen)...

Dort ist das echodevice-Modul klar ein Kandidat...
...womit aber "andere" kein Problem haben...

Und auch bei einem parallelen Speichertest-System mit Buster ist es schon deutlich besser...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

skynet

Scheinbar ist es UnifiVideo -> Die Switches haben sich wieder autocreated, da ich die Devices umbenannt hattet zieht die Verhinderung nicht.

MadMax-FHEM

Aber bevor du hier "alleine rumturnst" (also einen weiteren "Speicherfresser-Thread "aufmachst") evtl. bei den verlinkten oder einem davon "mitmachen"...

Dort ist mehr Dynamik als hier (mit uns beiden ;)  )...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)