[Gelöst?]Speicherverbrauch: Irgendwo ein memory leak in FHEM? APPMEM?

[cwagner]

Seit Monaten nun schlage ich mich mit einem steten Speicher-Verzehr auf meinem FHEM 5.6 update force gestern Abend herum. Stetig werden in kleinen Happen (so um die 100 kB) verbraucht. Habe das System schon um 40 Entitäten reduziert bis an die Schmerzschwelle des WAF
Ich komme dem Übeltäter nicht auf die Spur und hoffe nun aus hilfreiche Tipps aus der Gemeinde, was ich zur Fehlereinkreisung noch tun kann. Apropos Fehler: Mir deucht, dass Fehlermeldungen vom FHEM Speicher verbrauchen, ihn aber nicht zurückgeben...

Habe ich eine Chance, den Speicherverbrauch einzelner Module zu loggen? Meine Kenntnisse reichen aktuell nur dazu, die Summe über TOP auf der Konsole zu beobachten.
Gibt es so etwas wie apptime (das mir ja die Ausführungszeiten aufzeigt), ein "appmem" sozusagen?

Herzliche Grüße

Christian

[schka17]

Hallo Christian,

stand letzten September vor der selben Situation

http://forum.fhem.de/index.php/topic,27223.0.html

Meine Lösung wird dir wahrscheinlich nicht helfen/gefallen, ich habe mein FHEM vom CB2 auf eine x86 Platform mit 2 GB Ram migriert, natürlich auf eine frische Debian Installation. FHEM habe ich einfach kopiert, lief ansatzlos ohne Probleme, also auch ohne diesen memory Leak.

Habe dann nochmal zum Spaß das CB2 komplett neu aufgesetzt, siehe da, auch kein Problem.....

Ich konnte damals die Ursache nicht wirklich herausfinden, aber in dem verlinkten Thread sind ein paar Diagnose Schritte beschrieben, die dir vielleicht weiterhelfen.

Gruß

Karl

[cwagner]

Hallo Karl,

danke für den Tipp, auf diesen Thread war ich auch schon gestoßen und war damit nicht zum Ziel gekommen. Die Vorstellung, FHEM neu aufsetzen zu müssen, ist nicht gerade lustig, aber vielleicht probiere ich tatsächlich das einmal am Wochenende...

Monatelang lief die FHEM-Instanz halt mit 40 Devices mehr zuverlässig und bezüglich Speicher höchst unauffällig, grrrrrrr

Christian

[schka17]

Naja, ich glaube nicht das FHEM das Problem war, das kopierte lief ja auf dem neuen System ohne jede Änderung ohne Probleme, ich vermute eher dass da etwas im Zusammenspiel owserver, mysql, perl und FHEM war. Auf dem komplett neu aufgesetzten CB2 lief es dann ja auch testweise, bin dann aber trotzdem auf der neuen Platform geblieben, war einfach auch viel schneller..

Gruß

Karl


Sent from my iPad using Tapatalk

[cwagner]

Leider habe ich auch nach Neuaufsetzen mit Übertragung der fhem.cfg mein Problem...

[SommerSonnenWende]

Hallo,
bin (leider) ebenfalls von dem 'mysteriösem' Speicherverbrauchsproblem betroffen; auch eine Neuinstallation von FHEM brachte keinen Erfolg. Die Hinweise im bereits verlinkten Beitrag http://forum.fhem.de/index.php/topic,27223.0.html kann ich im Problemfall nicht mehr ausführen, da der physische Speicher wie auch die CPU zu 100% von 'perl fhem.pl fhem.cfg' ausgelastet sind.

Das Logging ist voll mit folgenden Einträgen:

Code Auswählen Erweitern


2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $la5 in substitution (s///) at ./FHEM/42_SYSMON.pm line 1474.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $la1 in substitution (s///) at ./FHEM/42_SYSMON.pm line 1473.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/42_SYSMON.pm line 1472.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 132.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $string in substitution (s///) at ./FHEM/99_Utils.pm line 131.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $minutes in addition (+) at ./FHEM/42_SYSMON.pm line 1464.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value $hours in addition (+) at ./FHEM/42_SYSMON.pm line 1462.
2015.03.11 18:30:03 1: PERL WARNING: Use of uninitialized value in int at ./FHEM/42_SYSMON.pm line 3043.
2015.03.11 18:29:27 1: Cannot fork: Cannot allocate memory
2015.03.11 18:29:27 1: FRITZBOX FBox: Readout_Start.621 Old readout process still running. Killing old process
2015.03.11 18:29:20 1: Cannot fork: Cannot allocate memory
2015.03.11 18:28:36 1: Cannot fork: Cannot allocate memory
2015.03.11 18:28:36 1: FRITZBOX FBox: Cmd_Start.1196 Old command still running. Killing old command: ring 611 20 Budapest msg:xxxxxxx
2015.03.11 18:28:36 3: FRITZBOX: set FBox ring 611 20 Budapest msg:xxxxxx
2015.03.11 18:28:20 1: Cannot fork: Cannot allocate memory
2015.03.11 18:27:20 1: Cannot fork: Cannot allocate memory
2015.03.11 18:26:20 1: Cannot fork: Cannot allocate memory
2015.03.11 18:25:20 1: Cannot fork: Cannot allocate memory
2015.03.11 18:24:27 1: Cannot fork: Cannot allocate memory
2015.03.11 18:24:27 1: FRITZBOX FBox: Readout_Start.621 Old readout process still running. Killing old process


Ein Screenshot der grafischen SYSMON-Anzeige ist im Anhang.

Welche Informationen werden benötigt? Und wie gelange ich an die Informationen, wenn der Fehlerfall eingetreten ist und FHEM nahezu nicht mehr auf Eingaben bzw. Befehle reagiert? Selbst ein simples 'version' in der FHEM-Eingabezeile führt dann zum Timeout der NGINX-Servers ...

Danke und schönen Abend.

[Freibeuter]

Auch ich habe seit dem 5.3.15 12:30 das Problem mit dem "Cannot fork: Cannot allocate memory".
Am 4.3.15 14:00 habe ich seit einigen Wochen wieder ein Update gemacht und seit dem ist nach ca 24 h der Speicher voll.
Ich habe das Problem nur bei einer meiner 7 Installationen, alle auf FB7490

Die einzigen Module, die nur dort und nicht auf den anderen Installationen laufen sind :
    Calendar
    ECMD
    ECMDDevice
    GUEST
Wie kann ich weiter analysieren, welcher von den 4 die Probleme macht?
Gruß
Peter F.

[cwagner]

Sind denn alle Deine Instanzen auf demselben Versionsstand?

Es ist noch verrückter: Mein FHEM nutzt keines Deiner verdächtigten Module. Dennoch habe ich fortlaufend Speicherverzehr und muss praktisch täglich vorsorglich booten, will ich nicht einen Stillstand im laufenden Betrieb riskieren...
Einmal unter 20 Starts hatte ich dann ein Fhem ohne Speicherverlust.... bis zum nächsten Neustart ohne Konfig-Änderung.

[Icinger]

Mal vielleicht ne Zwischenfrage (ich weiss, eigentlich geht's um Fritzen): Läuft bei euch zufällig der irqbalance-Daemon?

Der hat hier bei meinen beiden Cubies für ständig steigenden Speicherverbrauch gesorgt.
Einmal pro Woche waren die komplett unbrauchbar.

[SommerSonnenWende]

Den (wahrscheinlich unnützen) irqbalance - Prozess auf dem Cubietruck startete ich nächtens per Crontab neu:

Code Auswählen Erweitern


# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
30 02 * * * /etc/init.d/irqbalance restart >/dev/null 2>&1


Zur Fehlersuche habe ich ihn komplett deinstalliert (apt-get purge irqbalance && apt-get autoremove).

Den FHEM-Prozess überwache ich momentan mittels ps_mem.py, zu finden unter https://github.com/pixelb/ps_mem/.
Ein schnell gebasteltes Script schreibt die Daten in ein Logfile aller 5 Minuten via Crontab-Eintrag.

Code Auswählen Erweitern


#!/bin/bash

# Logfile
LOGFILE="/root/memusage_fhem.txt"

# Check if datafile exists, if not create header
if [ ! -f "$LOGFILE" ]; then
echo "UNIXTIME   DATE                PID  Private  + Shared    = RAM used Program" > $LOGFILE
fi

# Determine date/time
DATUMUNIX=$(date +"%s")
DATUMREAD=$(date -d @$DATUMUNIX +'%Y-%m-%d %H:%M:%S')
DATUMYEAR=$(date -d @$DATUMUNIX +'%Y')
DATUMDATE=$(date -d @$DATUMUNIX +'%Y%m%d')
DATUMTIME=$(date -d @$DATUMUNIX +'%H%M')
DATUMNOTE=$(date -d @$DATUMUNIX +'%d.%m.%Y %H:%M')

# Determine PID
PIDOFFHEM=$(ps -ef | grep fhem.pl | grep -v grep | tr -s ' ' | cut -d' ' -f2)

# Get Memory usage
MEMOFFHEM=$(/root/ps_mem.py -p $PIDOFFHEM | grep perl)

echo $DATUMUNIX $DATUMREAD $PIDOFFHEM $MEMOFFHEM >> $LOGFILE

exit 0


Das Logging sieht dann so aus:

Code Auswählen Erweitern


UNIXTIME   DATE                PID  Private  + Shared    = RAM used Program
1426239601 2015-03-13 10:40:01 1172 45.4 MiB + 852.0 KiB = 46.2 MiB perl
1426239901 2015-03-13 10:45:01 1172 45.4 MiB + 794.0 KiB = 46.1 MiB perl
1426240201 2015-03-13 10:50:01 1172 45.3 MiB + 805.0 KiB = 46.1 MiB perl
1426240501 2015-03-13 10:55:01 1172 45.4 MiB + 859.0 KiB = 46.2 MiB perl
1426242301 2015-03-13 11:25:01 1189 24.4 MiB + 653.0 KiB = 25.1 MiB perl
1426242601 2015-03-13 11:30:01 1189 26.8 MiB + 814.0 KiB = 27.6 MiB perl
1426242901 2015-03-13 11:35:01 1189 27.0 MiB + 801.0 KiB = 27.8 MiB perl


Wenn die PID wechselt, wurde FHEM bzw. der Cubietruck neu gestartet (z.B. wegen Updates)

Ob dieser Weg erfolgversprechend ist, weiss ich noch nicht. Vielleicht kann ja ein FHEM-Profi helfen den Speicherverbrauch einzelner Module innerhalb FHEMs aufzudröseln?

Gruß!

[Benni]

Auf meinem Cubie (Igor-Image) gibt es gar keinen irqbalance-Daemon.

[frank]

kennt ihr das http://forum.fhem.de/index.php/topic,28299.msg211841.html#msg211841 ?

[cwagner]

Nachdem ich kaum benutzte Instanzen von FHEMWEB (Tablet und Phone) entfernt habe und das Attribut closeConn auf 1 gesetzt habe.

[Freibeuter]

Hallo,
ich schlage mich noch immer mit "Cannot fork: Cannot allocate memory" herum.
Update ist frisch gemacht, aber es hat nicht geholfen.
Sysmon liefert mir gleichbleibend ca 80 mb freien Speicher.
Egal ob FHEM frisch gestartet wurde oder schon den Fehler meldet.
Könnte es auch die Anzahl der Forks sein und nicht deren Speicherbedarf ?
In der Installation rufe ich jede Minute eine RS232 Schnittstelle über ECMDDevice  ab, evtl. da was im argen ?!?
Manchmal meldet Sysmon nur 0 bei fs_boot.

Gruß
Peter F.

[cwagner]

Hast Du gedacht an plotfork   0      im Web-Modul (FHEMWEB, in einer Standard-Installation zum Beispiel WEB).

Herzliche Grüße

Christian