Cannot fork: Cannot allocate memory | BlockingInformParent

[en-trust]

Also mySQL und phpmyadmin ganz normal.

https://tutorials-raspberrypi.de/webserver-installation-teil-3-mysql/

Aber lt. Htop verbraucht fhem ja 55% steigend.

[Christoph Morrison]

Funktioniert das Schreiben der Logs in die MySQL auch? Mach mal bitte ein list deines DBLog-Devices.

[en-trust]

Also gestern erst neugestartet und heut ist der Speicher bereits bei 650MB von 1GB. HTop zeigt dass fhem den meisten Speicher frisst und nicht mySQL. My SQL loggt aber die Daten richtig mit.

Was könnte denn noch den Speicher bei fhem fressen ? Ich habe aber schon das Gefühl, dass das Problem erst mit dem Umstieg auf mySQL auftritt. Hab mich aber an die Anleitung von https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DTOy9eP1YR98&psig=AOvVaw3mI3rnevd5pqzlJmmfObAY&ust=1605766264332000&source=images&cd=vfe&ved=2ahUKEwjuib_Pt4vtAhVMr6QKHTGzCYUQr4kDegUIARCQAQ gehalten.

List DBLogging

Code Auswählen Erweitern

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:.*
   FUUID      5fa26001-f33f-e9d9-7b2d-89de79a5ad4b8f61
   FVERSION   93_DbLog.pm:v4.10.2-s22246/2020-06-23
   MODE       asynchronous
   MODEL      MYSQL
   NAME       DBLogging
   NR         1253
   NTFY_ORDER 50-DBLogging
   PID        845
   REGEXP     .*:.*
   STATE      connected
   TYPE       DbLog
   UTF8       1
   dbconn     mysql:database=fhem;host=localhost;port=3306
   dbuser     fhemuser
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    4.10.2
     REDUCELOG:
       DBLogging
       reduceLogNbl
       90
       average
   READINGS:
     2020-11-18 07:08:47   CacheUsage      0
     2020-11-18 07:08:47   NextSync        2020-11-18 07:09:17 or if CacheUsage 500 reached
     2020-11-18 03:00:02   reduceLogState  reduceLogNbl finished. Rows processed: 0, deleted: 0, updated: 0, time: 2.00sec
     2020-11-18 07:08:47   state           connected
   helper:
     bm:
       DbLog_Get:
         cnt        1
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:04:49
         max        9.48905944824219e-05
         tot        9.48905944824219e-05
         mAr:
           HASH(0x66a7540)
           DBLogging
           ?
       DbLog_Log:
         cnt        407
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:08:28
         max        0.101495981216431
         tot        0.842778921127319
         mAr:
           HASH(0x66a7540)
           HASH(0x554e8a8)
       DbLog_Set:
         cnt        3
         dmx        -1000
         dtot       0
         dtotcnt    0
         mTS        18.11. 07:02:47
         max        0.0655310153961182
         tot        0.0677380561828613
         mAr:
           HASH(0x66a7540)
           DBLogging
           reopen
Attributes:
   DbLogExclude .*
   DbLogSelectionMode Exclude/Include
   DbLogType  Current/History
   asyncMode  1
   room       System->LogFiles


Gibt es nicht eine Möglichkeit die in fhem mir die Prozesse anzeigt, welche Speicher die verbrauchen ?

apptime liefert derzeit nur... und da habe ich jene mit average über 1000 schon deaktiviert.

Code Auswählen Erweitern

active-timers: 182; max-active timers: 189; max-timer-load: 9  min-tmrHandlingTm: 0.0ms; max-tmrHandlingTm: 343.9ms; totAvgDly: 47.5ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-DOIF_SleepTrigger                    HASH(0x3c7ead8)                        281        1     281.62   281.62     1.75     1.75 18.11. 07:13:29 HASH(Modus_FBH.Anwesenheit)
Modus_Sommer.Auto                        DOIF_Notify                            264        8     266.71    33.34     0.00     0.00 18.11. 07:08:28 HASH(Modus_Sommer.Auto); HASH(Wetter_Pro)
Modus_FBH                                dummy_Set                              243        2     450.57   225.28     0.00     0.00 18.11. 07:13:29 HASH(Modus_FBH); Modus_FBH; Auto
Modus_Sommer                             dummy_Set                              241        1     241.35   241.35     0.00     0.00 18.11. 07:08:28 HASH(Modus_Sommer); Modus_Sommer; off
tmr-DOIF_TimerTrigger                    REF(0x8ce50a0)                         236        1     236.92   236.92     1.59     1.59 18.11. 07:05:00 REF(0x8ce50a0)
myJeeLink                                JeeLink_Read                           233      420   14952.91    35.60     0.00     0.00 18.11. 07:04:44 HASH(myJeeLink)
Modus_FBH.Sommer                         DOIF_Notify                            224        8     226.47    28.31     0.00     0.00 18.11. 07:08:28 HASH(Modus_FBH.Sommer); HASH(Modus_Sommer)
tmr-SIP_watch_listen                     mySIP                                  170       12    1732.81   144.40   229.50    27.50 18.11. 07:12:45 mySIP
tmr-FW_closeInactiveClients              0                                      118       11     429.58    39.05     1.90     1.32 18.11. 07:06:15 0
WEB_192.168.178.22_62594                 FW_Read                                110        8     165.70    20.71     0.00     0.00 18.11. 07:04:49 HASH(WEB_192.168.178.22_62594)
DBLogging                                DbLog_Log                              101      689    1355.21     1.97     0.00     0.00 18.11. 07:08:28 HASH(DBLogging); HASH(Wetter_Pro)
tmr-at_Exec                              HASH(0x6c71ad0)                         92        1      92.99    92.99     1.49     1.49 18.11. 07:02:47 HASH(DBLogging.ReOpen)
tmr-DOIF_TimerTrigger                    REF(0x7ad21e0)                          86        1      86.15    86.15     1.32     1.32 18.11. 07:06:00 REF(0x7ad21e0)
tmr-GetUpdate                            update                                  84       10     228.11    22.81     5.83     2.19 18.11. 07:03:08 update:TV_ProgrammePT
LaCrosse.Statistiken                     statistics_Notify                       70      123    4326.27    35.17     0.00     0.00 18.11. 07:08:45 HASH(LaCrosse.Statistiken); HASH(WC.LaCrosse)
FBH.DG.HomeMatic.CH_01.Auto              DOIF_Notify                             68       22     643.17    29.24     0.00     0.00 18.11. 07:04:30 HASH(FBH.DG.HomeMatic.CH_01.Auto); HASH(GZ.LaCrosse)
FBH.DG.HomeMatic.CH_01.Off               DOIF_Notify                             67        9     109.56    12.17     0.00     0.00 18.11. 07:13:28 HASH(FBH.DG.HomeMatic.CH_01.Off); HASH(Modus_FBH)
DBLogging                                DbLog_Set                               65        3      67.74    22.58     0.00     0.00 18.11. 07:02:47 HASH(DBLogging); DBLogging; reopen
tmr-DbLog_execmemcache                   HASH(0x66a7540)                         65       22     627.33    28.52   169.07    15.09 18.11. 07:12:17 HASH(DBLogging)
myCUL_433                                CUL_Read                                62       37     424.01    11.46     0.00     0.00 18.11. 07:09:42 HASH(myCUL_433)
tmr-PRESENCE_StartLocalScan              HASH(0x5d16280)                         60       11     551.56    50.14   105.70    37.61 18.11. 07:05:06 HASH(Smartphone_Sven)
FBH.DG.HomeMatic.CH_02.Auto              DOIF_Notify                             60       19     449.55    23.66     0.00     0.00 18.11. 07:10:30 HASH(FBH.DG.HomeMatic.CH_02.Auto); HASH(AZ.LaCrosse)
tmr-PRESENCE_StartLocalScan              HASH(0x5d20a90)                         60       11     572.61    52.06    88.50    28.86 18.11. 07:10:07 HASH(Smartphone_Myriam)
tmr-PRESENCE_StartLocalScan              HASH(0x5cfd840)                         60       11     505.54    45.96   101.85    68.21 18.11. 07:03:05 HASH(iPhone.8.Wlan)
tmr-TSCUL_DispatchDelayed                DdlmyCUL                                52       22     704.91    32.04     0.00     0.00 18.11. 07:06:32 DdlmyCUL:myCUL:1605679592.55893 -53 A0E27800258270CF110340101000034::-53:myCUL:
tmr-Twilight_sunpos                      HASH(0x8f2af90)                         51        1      51.80    51.80     1.38     1.38 18.11. 07:05:01 HASH(twilight_sunpos)
BatteryStatus.Check                      notify_Exec                             50      689     649.35     0.94     0.00     0.00 18.11. 07:08:28 HASH(BatteryStatus.Check); HASH(Wetter_Pro)
tmr-FRITZBOX_Readout_Start               FritzBox.6490.Readout                   46       12     477.25    39.77   359.67   171.03 18.11. 07:10:45 FritzBox.6490.Readout
GZ.LaCrosse_statistic                    statistics_Notify                       45       20     435.49    21.77     0.00     0.00 18.11. 07:02:37 HASH(GZ.LaCrosse_statistic); HASH(GZ.LaCrosse)
tmr-FRITZBOX_Readout_Start               FritzBox.Repeater.310.Readout           45       12     500.40    41.70   343.72   170.37 18.11. 07:08:45 FritzBox.Repeater.310.Readout
tmr-FRITZBOX_Readout_Start               FritzBox.7490.Readout                   45       12     516.34    43.03   354.06   168.47 18.11. 07:08:44 FritzBox.7490.Readout
BZLueften                                notify_Exec                             44       25     539.73    21.59     0.00     0.00 18.11. 07:02:41 HASH(BZLueften); HASH(BZ.LaCrosse)
tmr-PRESENCE_StartLocalScan              HASH(0x46ff098)                         44        6     245.59    40.93   238.12   133.91 18.11. 07:03:44 HASH(devolo.dLAN.500.Wlan)
tmr-PRESENCE_StartLocalScan              HASH(0x4700de0)                         43        6     234.49    39.08   275.84   154.56 18.11. 07:09:45 HASH(devolo.dLAN.500.WiFi)
BZ.LaCrosse_statistic                    statistics_Notify                       43       19     352.51    18.55     0.00     0.00 18.11. 07:03:25 HASH(BZ.LaCrosse_statistic); HASH(SZ.LaCrosse)
FBH.DG.HomeMatic.CH_01.Auto              DOIF_Set                                42        2      64.44    32.22     0.00     0.00 18.11. 07:13:28 HASH(FBH.DG.HomeMatic.CH_01.Auto); FBH.DG.HomeMatic.CH_01.Auto; initialize
AZ.LaCrosse_statistic                    statistics_Notify                       41       17     325.31    19.14     0.00     0.00 18.11. 07:04:31 HASH(AZ.LaCrosse_statistic); HASH(AZ.LaCrosse)
FLKU.LaCrosse_statistic                  statistics_Notify                       40       20     393.36    19.67     0.00     0.00 18.11. 07:05:19 HASH(FLKU.LaCrosse_statistic); HASH(FLKU.LaCrosse)
tmr-DOIF_TimerTrigger                    REF(0x8e5ba38)                          40        1      40.44    40.44     0.90     0.90 18.11. 07:07:00 REF(0x8e5ba38)
tmr-RESIDENTStk_DurationTimer            HASH(0x78d5970)                         40        1      40.26    40.26   149.89   149.89 18.11. 07:02:43 HASH(residents_DurationTimer)
KZ.LaCrosse_statistic                    statistics_Notify                       39       24     528.00    22.00     0.00     0.00 18.11. 07:11:18 HASH(KZ.LaCrosse_statistic); HASH(KZ.LaCrosse)

[mumpitzstuff]

Nein gibt es nicht so wirklich meines Wissens. Es gibt nur eins das du machen kannst. Sichere deine Konfiguration. Lösche dann 5 Devices und starte FHEM mit shutdown restart neu und beobachte den Speicherverbrauch. Wenn er dann irgendwann nicht mehr steigt, dann ist es eins der 5 Devices die du davor gelöscht hast. Dann kannst du das auf dem gleichen Weg weiter eingrenzen.

[Wzut]

naja , indirekt und je nach Verursacher schon : Bsp das SIP Modul , die PID des Child Prozess findest du in den Internals des SIP Device unter LPID und auch in den eckigen Klammern bei der Log Ausgabe. Mit der PID kannst dann ja den Pozess in der htop Anzeige finden

[en-trust]

Hab mal diese Update. devices rausgeschmissen und Abfall auch. Nach restart erst bei 300 und dann der Sprung auf 500 MB innerhalb kürzester Zeit.
Zudem hab ich jetzt 4 Prozesse von fhem laufen...

in den Internals des mySIP fand ich dann die PID (LPID 25054) welche in htop als 4. fhem Prozess läuft.

Log

Code Auswählen Erweitern

2020.11.18 10:22:49.636 4: mySIP, Listen new PID : 25054
2020.11.18 10:22:49.652 4: mySIP[25054], my parent is 24988


Die anderen PID fand ich im Log jedoch nicht.

[Wernieman]

Du hast mehr als 1 FHEM-Prozess, da in htop jeder folk einzeln gezeigt wird. Du hast schließlich auch "nur" ein mysql aber in htop ..... schaue mal bei htop unter setup/Display Options/Hide userland process threads und aktiviere es .....

Für fhem und steigenden Verbraucht gibt es schon einen Thread dazu.

Persönliche Meinung:
Ich würde Dir aber auf einem PI keine mysql Datenbank empfehlen ...

[en-trust]

Für fhem und steigenden Verbraucht gibt es schon einen Thread dazu.

Hab in der Suche nichts brauchbares gefunden... kann es an der mySQL liegen, ob der Verbrauch am fhem Prozess hängt ?

[Wernieman]

Meistens liegt es an RegEX .. da hat perl einige Probleme ...

ABER ... Bei Dir: 5% des Speichers gehen aktuell für mysql "drauf". Dazu kommt noch apache (phpmysql) und schon hast Du einigen Verbrauche der "knappen" 1GByte. Zusätzlich ist mysql nicht gut für die SD, da es nicht optimal schreibt. Es ist eben für "Größere" Maschinen gedacht ....

Was hast Du eigentlich alles auf dem Pi?

[en-trust]

Auf dem Pi läuft nur fhem, mysql, phpmyadmin, perl 5.28 und dieses grafana.

[Wernieman]

Meine Meinung:
Ich würde FHEM und sonstige "großen" Programme beim Pi physikalisch trennen .... aber das ist nur meine persönliche Meinung ...

[en-trust]

Würde ein sog. Docker ggf. Abhilfe schaffen ?

https://blog.krannich.de/fhem-auf-rpi-mit-docker-und-hypriot/

[Wernieman]

Das vergrößert nicht Dein Arbeitsspeicher ...

[en-trust]

Also gestern lief der Speicher mir wieder voll und es ist immer nur ein fhem prozess lt. htop. Heute nach einem Neustart geht das Spielchen weiter...

Code Auswählen Erweitern


  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  768 fhem      20   0  274760 228776  12328 S   8,3  24,2  19:50.91 perl
1379 fhem      20   0  167312 113076   3764 S   0,0  11,9   0:12.29 perl
  595 mysql     20   0  723616  95296  15468 S   0,3  10,1   0:49.38 mysqld
1052 pi        20   0  307920  58248  44980 S   0,0   6,2   0:02.29 zenity


Es kann doch nicht sein, dass fhem keinen Speicher wieder freigibt oder gibt es da doch eine Möglichkeit. Am masql kannst nicht liegen, der Speicher bleibt konstant.

sagt das vielleicht noch etwas aus ?

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo pstree -tca | grep [f]hem
  |-perl fhem.pl fhem.cfg
  |   `-perl fhem.pl fhem.cfg
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66
  |-presence.sh /opt/fhem/FHEM/presence.sh 192.168.178.21 ac:af:b9:a6:5a:66


Hier mal der Code aus presence.sh (auch hier vom Forum).

Code Auswählen Erweitern

#!/bin/bash
# detect Iphone/Android by IP/HOSTNAME and MAC address.
# use MAC address too, to prevent false positives if IP might change
# returns 1 or 0
# number of retries, less is faster, but less accurate

PREMAXRETRIES=6
MAXRETRIES=6
# exit immediately if no parameters supplied
if [ $# -lt 2 ]
  then
    echo "UNDEF"
  exit 1
fi

# Set variables
IP=`echo $1 | grep -oP '([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}'`
#HOST=`host -4 $1 | grep -oP '([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}\.([0-9]){1,3}'`
MAC=$2
COUNT=0
PRECOUNT=0

if [ -z "$IP" ]; then
IP=${HOST}
if [ -z "$IP" ]; then
echo "0"
exit 0
fi
fi

while [ ${PRECOUNT} -lt ${PREMAXRETRIES} ];
do
PRECHECK=`arp -a | grep -o "${MAC}"`
if [ ${#PRECHECK} -eq ${#MAC} ]; then
   # exit when phone is detected
   echo "1"
   exit 0
fi
((PRECOUNT++))
done


while [ ${COUNT} -lt ${MAXRETRIES} ];
do
  # Change dev and eth0 if needed
  #   sudo ip neigh flush dev eth0 ${IP}
  ping  ${IP} >/dev/null 2>&1
  #sudo hping3 -q -2 -c 10 -p 5353 -i u1 ${IP}
  sleep .1
  # Only arp specific device, grep for a mac-address
  STATUS=`arp -a | grep -o "${MAC}"`

  if [ ${#STATUS} -eq ${#MAC} ]; then
     # exit when phone is detected
     echo "1"
    exit 0
  fi
  ((COUNT++))
  sleep .1
done
# consider away if reached max retries
echo "0"

[rudolfkoenig]

Es kann doch nicht sein, dass fhem keinen Speicher wieder freigibt ....

Doch, es kann sein. Ist nicht schoen, ist ein Fehler, und rauszukriegen, wo es herkommt, ist nicht trivial, wie man es an der Laenge dieser Diskussion sieht. Wir hatten als Schuldigen mal perl-Versionen ausgemacht, und ich habe auch bestimmte Betriebsystem-Bibliotheksversionen fuer ARM auch in Verdacht. Allerdings betrifft das Problem nur wenige, und definitiv nicht mich, sonst wuerde ich dem Problem auf dem Grund gehen.

Ich kenne z.Zt. nur zwei Methoden, um die Ursache zu identifizieren, das bereits erwaehnte Schrittweise entfernen der FHEM-Definitionen, und die in diesem Thread erwaehnte pmap Variante, was aber nur fuer Erfahrene und/oder Hartnaeckige zu empfehlen ist.

Die vielen presence.sh Prozesse in deinem Fall ist vermutlich auch nicht richtig, ich vermute es liegt an ping ohne Limitierung. Sollte aber nicht die Ursache des FHEM-Speicherverbrauchs sein.