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
Hallo Christian,
stand letzten September vor der selben Situation
http://forum.fhem.de/index.php/topic,27223.0.html (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
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
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
Leider habe ich auch nach Neuaufsetzen mit Übertragung der fhem.cfg mein Problem...
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 (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:
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.
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.
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.
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.
Den (wahrscheinlich unnützen) irqbalance - Prozess auf dem Cubietruck startete ich nächtens per Crontab neu:
# 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/ (https://github.com/pixelb/ps_mem/).
Ein schnell gebasteltes Script schreibt die Daten in ein Logfile aller 5 Minuten via Crontab-Eintrag.
#!/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:
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ß!
Auf meinem Cubie (Igor-Image) gibt es gar keinen irqbalance-Daemon.
kennt ihr das http://forum.fhem.de/index.php/topic,28299.msg211841.html#msg211841 (http://forum.fhem.de/index.php/topic,28299.msg211841.html#msg211841) ?
Nachdem ich kaum benutzte Instanzen von FHEMWEB (Tablet und Phone) entfernt habe und das Attribut closeConn auf 1 gesetzt habe.
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.
Hast Du gedacht an plotfork 0 im Web-Modul (FHEMWEB, in einer Standard-Installation zum Beispiel WEB).
Herzliche Grüße
Christian
Hallo,
auch plotfork = 0 hat leider nicht geholfen, wobei aich auch kein dblog nutze.
hier mein WEB config:
define WEB FHEMWEB 8083 global
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB closeConn 0
attr WEB editConfig 1
attr WEB longpoll 1
attr WEB plotfork 0
Gruß
Peter F.
Hat evtl. Jemand dafür eine Idee?
# ps
PID USER VSZ STAT COMMAND
1 root 1236 S init
2 root 0 SW [kthreadd]
3 root 0 SW [migration/0]
4 root 0 SW [ksoftirqd/0]
5 root 0 SW [watchdog/0]
6 root 0 SW [migration/1]
7 root 0 SW [ksoftirqd/1]
8 root 0 SW [watchdog/1]
9 root 0 SW [yield_w/0]
10 root 0 SW [yield_w/1]
11 root 0 SW [events/0]
12 root 0 SW [events/1]
13 root 0 SW [khelper]
16 root 0 SW [async/mgr]
32 root 0 SW [sync_supers]
33 root 0 SW [bdi-default]
35 root 0 SW [kblockd/0]
36 root 0 SW [kblockd/1]
56 root 0 SW [kswapd0]
57 root 0 SWN [ksmd]
58 root 0 SW [aio/0]
59 root 0 SW [aio/1]
73 root 0 SW [pm_info]
80 root 0 SWN [avmdebug]
106 root 0 SW [mtdblockd]
115 root 0 DW [ifx_ssc]
127 root 0 SW [l2tp]
131 root 0 SW [tffsd_mtd_0]
132 root 0 SW [avmnet_workqueu]
133 root 0 SW [PhyWaspHeartbea]
139 root 0 SW [avmnet_timer]
141 root 0 SW< [loop0]
177 root 0 SW [yaffs-bg-1]
358 root 0 SW [cleanup_timer_f]
433 root 0 SW [yaffs-bg-1]
448 root 0 SW [capi_pipew/0]
449 root 0 SW [capi_pipew/1]
450 root 0 SW [capi_schedw/0]
451 root 0 SW [capi_schedw/1]
452 root 0 SW [pcmlink_ctrl]
455 root 0 SW [capitransp]
458 root 0 SW< [avm_dect_thread]
459 root 0 SW [ksock tcp worke]
460 root 0 SW [ksock tcp serve]
536 root 1288 S < /sbin/udevd --daemon
556 root 0 SW [khubd]
780 root 2556 S /bin/configd
875 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
882 root 2696 S dsl_monitor -d
884 root 2696 S dsl_monitor -d
885 root 2696 S dsl_monitor -d
888 root 2696 S dsl_monitor -d
900 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
901 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
902 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
903 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
904 root 4192 S dsl_control -i10_00_10_40_00_04_01_07 -f/lib/modules
905 root 0 SW [autbtex]
906 root 0 SW [pmex_ne]
907 root 0 SW [pmex_fe]
1026 root 0 SWN [dectuart_route]
1029 root 2692 S avmipcd
1032 root 3208 S l2tpv3d
1039 root 14048 S ctlmgr
1044 root 7120 S upnpd
1049 root 4032 S multid
1053 root 14048 S ctlmgr
1054 root 14048 S ctlmgr
1055 root 14048 S ctlmgr
1058 root 3560 S ddnsd
1066 root 2892 S upnpdevd
1071 root 2892 S upnpdevd
1080 root 2704 S wland -B
1088 root 4584 S dsld -i -n
1097 root 4648 S pbd
1099 root 4648 S pbd
1101 root 4648 S pbd
1102 root 4648 S pbd
1113 root 6376 S telefon a127.0.0.1
1115 root 1232 S telnetd -l /sbin/ar7login
1127 root 6376 S telefon a127.0.0.1
1128 root 6376 S telefon a127.0.0.1
1132 root 5492 S dect_manager
1136 root 5860 S < voipd
1140 root 3696 S /usr/bin/faxd -a
1147 root 1236 S /usr/sbin/inetd
1168 root 3692 S feedd
1177 root 3224 S audiod
1218 root 4488 S /usr/bin/aha
1220 root 4488 S /usr/bin/aha
1221 root 4488 S {upper_conn} /usr/bin/aha
1222 root 4488 S /usr/bin/aha
1223 root 4488 S /usr/bin/aha
1224 root 4488 S /usr/bin/aha
1225 root 4488 S /usr/bin/aha
1226 root 4488 S /usr/bin/aha
1227 root 4488 S {sRX} /usr/bin/aha
1240 root 1136 S /bin/run_clock -c /dev/tffs -d
1301 root 2652 S /sbin/nmbd
1312 root 1236 S init
1349 root 3420 S usermand
1352 root 1328 S oamd
1354 root 7120 S upnpd
1355 root 7120 S upnpd
1356 root 7120 S upnpd
1358 root 3300 S contfiltd
1389 root 0 SW [wlan_com_tx_thr]
1866 root 1288 S < /sbin/udevd --daemon
1872 root 1288 S < /sbin/udevd --daemon
1874 root 0 SW [tgt_alive_poll_]
1925 root 4876 S /bin/avmike
2192 root 1416 S hostapd -B /etc/wpa2/WSC_ath0.conf
2258 root 1416 S hostapd -B /etc/wpa2/WSC_ath1.conf
2304 root 1412 S /sbin/chronyd -n -f /var/tmp/chrony.conf
2345 root 1252 S -sh
3097 root 68284 R perl fhem.pl fhem.cfg
3112 root 0 SW [flush-31:0]
3127 root 7436 S /sbin/fritznasdb -a
3130 root 7436 S /sbin/fritznasdb -a
3131 root 7436 R N /sbin/fritznasdb -a
3156 root 1236 S {startwatchdog} /bin/sh ./startwatchdog
3168 root 4636 S perl watchdog.pl
3182 root 68284 S perl fhem.pl fhem.cfg
3184 root 68284 S perl fhem.pl fhem.cfg
3185 root 68284 S perl fhem.pl fhem.cfg
3186 root 68284 S perl fhem.pl fhem.cfg
3304 root 69400 R perl fhem.pl fhem.cfg
3305 root 69656 R perl fhem.pl fhem.cfg
3390 root 1232 R ps