[Gelöst]Fehler Out of Memory - Can't use an undefined value as an ARRAY....DbRep

[Rewe2000]

Hallo,

seit dem Update vor 2 Tagen, startet mein Fhem auf dem Raspi3 nachts automatisch neu, mit der Meldung "Out of Memory".

Mit meinen begrenzten Systemkenntnissen vermute ich hier "93_DbRep.pm" als Verursacher, es könnte aber auch sein, dass diese Meldung nur die logische Ursache ist, weil der Speicher zu Ende geht.

Code Auswählen Erweitern

2020.11.22 02:03:33 2: DbLog DBLogging: Connection closed until 03:03:33 (3600 seconds).
2020.11.22 02:03:33 1: ERROR evaluating {DbRep_getInitDataDone('DBReport|MjAxOS0xMS0xNiAwNDo1OTo1NQ==|0.004664,0.008951|0|reduceLog||DbRep_Main|SW5kZXggUmVwb3J0X0lkeCBleGlzdHM=|VVBEQVRFLFNFTEVDVCxGSUxFLERFTEVURSxJTlNFUlQ=')}: Can't use an undefined value as an ARRAY reference at ./FHEM/93_DbRep.pm line 8825.

Out of memory!
2020.11.22 02:04:01 1: HMCCU: [CCU2 : 28897] Graceful shutdown in 8 seconds

Genau wenn der Fehler auftritt, starte ich über ein at "DBReport reduceLog", um meine Datenbank vor dem Dump zu verdichten.

Code Auswählen Erweitern

Internals:
   COMMAND    set DBReport reduceLog average
   DEF        *02:03:33 set DBReport reduceLog average
   FUUID      5c47772e-f33f-7df9-9dbe-8f6f4cd19babdac8
   NAME       at_DBLog_verdichten
   NR         146
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 02:03:33
   TIMESPEC   02:03:33
   TRIGGERTIME 1606093413
   TRIGGERTIME_FMT 2020-11-23 02:03:33
   TYPE       at
   READINGS:
     2020-11-22 02:04:18   state           Next: 02:03:33
Attributes:
   DbLogExclude .*
   comment    Dieses at startet das verdichten der SQL-Datenbank, diese wurde in der Vergangenheit mit DbLog erledigt.
Der bisherige Befehl dazu lautete: *02:03:33 set DBLogging reduceLogNbl 30 average
   group      Hardware
   icon       system_backup
   room       Logging

Der Fehler ist erstmals nach dem letzen Update aufgetreten (Updates ca. alle 2 Wochen), geändert habe ich an DbRep meines Wissens in den letzen Wochen nichts.
Wenn es helfen sollte, bei mir läuft Sysymon mit, deshalb die beiden Charts RAM und SWAP im Anhang für den besagten Zeitraum.
Bitte sagt mir, was ich noch liefern muss, damit ihr mir helfen könnt.

Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

da ist mir beim letzten Featureeinbau wohl ein Fehler unterlaufen.
Ich habe dir in meinem contrib eine Korrektur bereitgestellt. Bitte downloaden, restarten und neu testen

Zum Download in der FHEMWEB Kommandozeile inklusive der Ausführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern


"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"


LG,
Heiko

[Rewe2000]

Hallo Heiko,

so wie es aussieht passt es jetzt bei mir, der Fehler kommt nicht mehr, wenn ich "reduceLog average" ausführe.

Code Auswählen Erweitern

2020.11.22 12:37:22 2: DbLog DBLogging: Connection closed until 13:37:22 (3600 seconds).
2020.11.22 12:38:42 2: DbRep DBReport - command message after reduceLog: "Reopen executed."


Hast du in der contrib-Version den Header noch nicht geändert?
Wenn ich nach dem Download und Shutdown Restart, mir die "Version" von DbRep anzeigen lasse, kann ich da keine Änderung feststellen.
Aber Fhem verabschiedet sich jetzt nicht mehr und läuft weiter.

Vielen Dank für deine schnelle Hilfe.
Noch einen schönen Sonntag

Gruß Reinhard

[betateilchen]

Hast du in der contrib-Version den Header noch nicht geändert?
Wenn ich nach dem Download und Shutdown Restart, mir die "Version" von DbRep anzeigen lasse, kann ich da keine Änderung feststellen.

Die Datei hat im contrib Verzeichnis die Property "ID" nicht, deshalb wird das beim Einchecken nicht aktualisiert.
Wenn das Modul wieder im normalen FHEM Zweig landet, wird auch die ID aktualisiert.

[Rewe2000]

Danke betateilchen für die Erklärung,

war mir nur nicht sicher, ob das Update auch geklappt hatte. Der neue Zeitstempel der Datei und der verschwundene Fehler stimmte mich aber zuversichtlich.

Gruß Reinhard

[DS_Starter]

Danke für die Rückmeldung Reinhard. Ich checke die Version heute noch ein. Dann ist sie morgen früh im Regelupdate enthalten und hat dann auch eine neue FHEM Versionsnummer. 

[hugo.crank]

Hallo seit 2 Wochen läuft Reducelog nicht mehr bei mir und Fhem stürzt einfach ab. nachdem ich auf dein Modul umgestiegen bin DBREP / ging ein reduce wieder! komme ich allerdings auf eine sehr große Datenmenge / stürzt auch hier Fhem ab mit dem Eintrag im log: "out of memory" / Teilweise steht auch im modul unter status noch mysql client run out of memory..

ich logge sehr viel und reduzieren das anschliessend, ich weiß nicht weiter woher nun das problem kommt. PEARL? oder doch mysql?

Basissystem ist Windows mmit activepearl und XAMPP mit mysql. läuft seit 2017 (mit Updates)

----

DBD::mysql::st execute failed: MySQL client ran out of memory a

-----

wird fhem neugestartet funktioniert der Befehl wieder!

[DS_Starter]

Dein RAM ist einfach alle.
Du müsstest die Tage die du behandelst eingrenzen, z.B. mit

 attr <name> timeDiffToNow d:10 FullDay

um jedesmal nur die 10 letzten Tage zu behandeln.
Wenn reducelog jeden Sonntag läuft, gibt es immer genug Überlappung um die DB zu reduzieren.

[hugo.crank]

1x läuft der Befehl durch, danach kommt der fehler, nach einem neustart von fhem geht wieder 1x. ich grenze schon nur noch einen Tag ein... und 32gb ram bekommt er nicht voll. Systemauslastung von perl liegt bei 1,4gb.

[DS_Starter]

Da bin ich leider etwas überfragt.
Unter Windows betreibe ich auch kein System und kann damit keine Versuche anstellen.

Wie du es beschreibst ist es tatsächlich eher unwahrscheinlich der Speicher voll zu bekommen, aber die Mitteilung ""out of memory" bzw. "mysql client run out of memory" ist schon eindeutig in meinen Augen.

Möglicherweise stößt MySQL intern an Grenzen. Es könnte der Parameter MySQL Serevrparameter innodb_buffer_pool_size sein. Im MySQL Configfile findest du ihn.

Code Auswählen Erweitern

innodb_buffer_pool_size – Defaults to 128M. This is the main setting you want to change, since it sets how much memory InnoDB will use for data+indexes loaded into memory. For a dedicated MySQL server, the recommended size is 50-80% of installed memory. So for example, a server with 64G of RAM should have around a 50G buffer pool.

The danger of setting this value too high is that there will be no memory left for the operating system and some MySQL-subsystems that rely on filesystem cache such as binary logs, and InnoDB's transaction logs.

Ich denke hier hilft nur googeln und lesen und sich so der Lösung nähern.

[hugo.crank]

Guten Morgen,
hab es schon auf 3 GB hoch gesaetzt trotzdem bricht er weg.. leider... seltsam ist nur das es scheinbar am activeperl liegt am Plugin für dbd-mysql der an seine grenze kommt. nach reboot fhem geht es ja 1x wieder.
macht mich wahnsinnig... ohne änderung von einem auf den andren tag macht er das spiel..

errortext
DBD::mysql::st execute failed: MySQL client ran out of memory at ./FHEM/93_DbRep.pm line 11618

[hugo.crank]

Problem lokalisiert beim durchforsten der Datenbankeinträge. DB Connect mysql Pearlmodul hat trotzdem eine Macke und kommt mit dem Speicher nicht klar wenn der SQL mal ins straucheln kommt. Läuft aber nun da ich die Datenbank manuell mit dem phpmyadmin bereinigt habe.