[Gelöst] FHEM Freeze wenn NAS langsam

[Nicees]

Hallo zusammen!

Folgendes Problem:
Seit einigen Tagen läuft auf meinem Synology NAS ein Full-Backup via Hyper-Backup, was in etwa 10 Tage dauern wird. Mein NAS wurde nach einigen Tagen sehr sehr langsam und reagierte auch via SMB/AFP nur schleppend auf Anfragen. Wie auch immer...
Auf besagtem NAS läuft eine MariaDB, wo mein FHEM mittels DBLog die Logdaten hinschreibt.

Als das NAS langsam wurde (aus welchem Grund auch immer), ist auch mein FHEM täglich eingefroren (sudo service fhem restart hat immer geholfen). Gestern war mein NAS gar nicht mehr erreichbar, und mein FHEM konnte weder über sudo reboot noch über sudo service fhem restart wieder über die :8083 GUI erreichbar gemacht werden (Service lief lt. sudo service fhem status, hat allerdings nichts wirklich getan).

Reboot des NAS, welches dann natürlich wieder flott läuft, hat sowohl dem NAS, als auch FHEM geholfen. Denn im Nachgang startete FHEM sofort und lief bislang tadellos.

Auf meinem RPi, wo auch FHEM läuft, ist kein gesonderter DB-Dienst am Laufen. Quasi "nur" FHEM, homebridge und ein Apache.

Ich steh total auf'm Schlauch, kann auch totaler Zufall sein. Aber wie kann die Performance meines NAS, wo ich ja "nur" Log-Daten reinschreibe, die Funktionalität von FHEM dermaßen beeinflussen?
Was übersehe ich?

Danke für euren Rat & Cheers!

Niclas

[DS_Starter]

Hallo Niclas,

wahrscheinlich betreibst du DbLog im synchronen Modus, was der Standard nach Definition ist.

Du musst unbedingt dafür sorgen, dass FHEM von der DB auf dem NAS entkoppelt wird. Das macht man mit dem Attribut asyncMode = 1 im DbLog.
Darüber hinaus führe bitte

set <> configCheck

aus und poste bitte was ausgegeben wird.

Grüße,
Heiko

[Nicees]

Hallo Heiko,

DbLog ist bei mir tatsächlich schon im async mode. asyncMode ist bereits =1.

set configCheck ergibt folgendes:

Code Auswählen Erweitern


Result of version checkUsed Perl version: 5.28.1 Used DBI (Database independent interface) version: 1.642 Used DBD (Database driver) version mysql: 4.050 Used DbLog version: 4.10.2.A new DbLog version is available (creation time: 2021-03-05_07:45:02, size: 451248 bytes) Recommendation: You should update FHEM to get the recent DbLog version from repository ! Your DBD version fulfills UTF8 support, no need to update DBD. Result of configuration read checkConnection parameter store type: file Connection parameter: Connection -> mysql:database=fhem;host=NASND;port=3307, User -> fhemdb, Password -> read o.k. Result of connection checkConnection to database fhem successfully done. Recommendation: settings o.k. Result of encoding checkEncoding used by Client (connection): LATIN1 Encoding used by DB fhem: UTF8 Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/contrib/dblog/db.conf' to the right value. Your DBD version fulfills UTF8 support, no need to update DBD. Result of logmode checkLogmode of DbLog-device DBLogging is: asynchronous Recommendation: settings o.k. Result of insert mode checkInsert mode of DbLog-device DBLogging is: Array Recommendation: Setting attribute "bulkInsert" to "1" may result a higher write performance in most cases. Feel free to try this mode. Result of plot generation method checkWARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set. WEB: plotfork=0 / plotEmbed=0Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax". Result of table 'history' checkColumn width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 255, 'UNIT' = 32 Column width used by DBLogging: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32 Recommendation: settings o.k. Result of table 'current' checkColumn width set in DB current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 255, 'UNIT' = 32 Column width used by DBLogging: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32 Recommendation: settings o.k. Result of check 'Search_Idx' availabilityThe index 'Search_Idx' is missing. Recommendation: You can create the index by executing statement 'CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP) USING BTREE;' Depending on your database size this command may running a long time. Please make sure the device 'DBLogging' is operating in asynchronous mode to avoid FHEM from blocking when creating the index. Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Search_Idx' as well ! Result of check 'Report_Idx' availability for DbRep-devicesNo DbRep-device assigned to DBLogging is used. Hence an index for DbRep isn't needed. Recommendation: settings o.k.

[DS_Starter]

Oh das kann man nicht lesen. Füge diesen Ausgabetext bitte nochmal in Code-Tags (die Taste "#" im Menü) ein.

[Nicees]

Done - s.o.

Ob das so besser ist, weiß ich nicht. Spuckt mir FHEM leider als Fließtext so aus. 

[DS_Starter]

Einfach neu aus dem Browser kopieren und in den Codetags einfügen.
Sieht dann so aus:

Code Auswählen Erweitern


Result of version check

Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version mysql: 4.050
Used DbLog version: 4.11.0.
Your local DbLog module is up to date.
Recommendation: No update of DbLog is needed. Your DBD version fulfills UTF8 support, no need to update DBD.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.2.10;port=3306, User -> fhem, Password -> read o.k.

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): UTF8
Encoding used by DB fhem: UTF8
Recommendation: settings o.k. Your DBD version fulfills UTF8 support, no need to update DBD.

Result of logmode check

Logmode of DbLog-device LogDB is: asynchronous
Recommendation: WARNING - you are running asynchronous mode that is recommended, but the value of global device attribute "blockingCallMax" is set quite small.
This may cause problems in operation. It is recommended to increase the global blockingCallMax attribute.

Result of insert mode check

Insert mode of DbLog-device LogDB is: Bulk
Recommendation: settings o.k.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.

WEB: plotfork=1 / plotEmbed=2
WEB.BLACK: plotfork=1 / plotEmbed=1
WEBSSChatBot: plotfork=1 / plotEmbed=2
WEBphone: plotfork=1 / plotEmbed=2
WEBtablet: plotfork=1 / plotEmbed=2

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices. If these attributes are not set, blocking situations may occure when creating plots. Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".


Result of table 'history' check

Column width set in DB history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by LogDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by LogDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to LogDB is used, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP,READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'LogDB' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !


[DS_Starter]

Wenn DbLog auf Asynchron steht passt das.
Aber ich habe deine Ausgabe gelesen.

Wahrscheinlich sind es Plots die deine FHEM ausbremsen:

Code Auswählen Erweitern


Result of plot generation method check
WARNING - at least one of your FHEMWEB devices has attribute "plotfork = 1" and/or attribute "plotEmbed = 2" not set.
WEB: plotfork=0 / plotEmbed=0

Recommendation: You should set attribute "plotfork = 1" and "plotEmbed = 2" in relevant devices.
If these attributes are not set, blocking situations may occure when creating plots.

Note: Your system must have sufficient memory to handle parallel running Perl processes. See also global attribute "blockingCallMax".


Das solltest du mal checken.

[Nicees]

Danke für die Info mit dem "erneut kopieren", ups 

Ich habe ein Plot - Verbrauchsverlauf meiner Fritz DECT Steckdose. Habe das damals nur zwecks Übung angelegt und habe es soeben entfernt.

Kann das der Grund dafür sein, dass FHEM gar nicht erst erreichbar ist wenn die MariaDB auf dem NAS nicht verfügbar ist? Oder sollten Plots FHEM nur spürbar "verlangsamen" wenn die DB nicht da ist?

[DS_Starter]

Kann das der Grund dafür sein, dass FHEM gar nicht erst erreichbar ist wenn die MariaDB auf dem NAS nicht verfügbar ist? Oder sollten Plots FHEM nur spürbar "verlangsamen" wenn die DB nicht da ist?

FHEM Blockierungen in diesem Umfeld entstehen nur wenn man bestimmte Zusammnehänge nicht beachtet. Auf der einen Seite das Loggen = schreiben in die DB, andererseits das Lesen via SVG Plots und ähnliche Zugriffe.
Wenn die DB nicht (zügig) reagiert, bremst sie FHEM aus bis zum Stillstand im schlimmsten Fall weil die Anwendung (FHEM) wartet bis eine Antwort von der DB kommt.

Deswegen gibt es diverse Attribute die das verhindern. Das DbLog configCheck prüft grundlegende Einstellungen und gibt Empfehlungen. Die commandref zu diesen Attributen lohnt es sich mal zu studieren und zu verstehen was im Hintergrund passiert.

[Nicees]

OK, macht Sinn. Besten Dank - ohne den Plot wird sich dieses Problem hoffentlich erübrigen dann. 

[DS_Starter]

Musst du schauen ... aber es ist nicht der Sinn Plots deswegen zu löschen, sondern die Attribute nutzen 
Plots benutzt man üblicherweise sehr häufig.
Es gibt aber u.U. noch andere blockierende Anwendungen. Mit dem Modul freezemon bekommst du das dann evtl. heraus.

[Nicees]

Schön, mein FHEM hat sich nach ungefähr 24h erneut aufgehängt. sudo service fhem restart hat geholfen, läuft wieder.

Freezemon richte ich gleich mal ein.

FHEMWEB device "WEB" hat keins der genannten Attribute gesetzt. Ich korrigiere das mal.

Mir ist auch aufgefallen, dass mein DbLogReduce in etwa immer zur gleichen Zeit ist. Eventuell blockiert der sich damit, dass der auf den DbLogReduce wartet während das NAS 100%ig ausgelastet ist.

[DS_Starter]

FHEMWEB device "WEB" hat keins der genannten Attribute gesetzt. Doofe Frage: Was genau tun diese technisch?

Vereinfacht gesagt werden in diesen Fällen potentiell blockierende Aufrufe in nebenläufige/parallele Prozesse verlagert die dadurch den FHEM Hauptprozess (Single-Thread) nicht ausbremsen.
FHEM stellt dafür verschiedene Verfahren zur Verfügung.

Wenn du im Forum suchst findest du viele Themen die sich damit beschäftigen.
Aber solche Blockierungen können vielfältige Ursachen haben. Man muß sie "nur" finden.

Mir ist auch aufgefallen, dass mein DbLogReduce in etwa immer zur gleichen Zeit ist. Eventuell blockiert der sich damit, dass der auf den DbLogReduce wartet während das NAS 100%ig ausgelastet ist.

Das ist 100%ig so. Es gibt dafür die nicht blockierende Version im DbRep bzw. im DbLog reduceLogNbl.

[Nicees]

Danke für den Hinweis!

Ich habe nun Freezemon konfiguriert und das DbLogReduce auf reduceLogNbl abgeändert.

Ich warte nun einmal ab wie es sich verhält. Aktuell erhalte ich vom Freezemon sehr häufig "possible freeze" meiner HUEDevice Sensoren:

Code Auswählen Erweitern

[Freezemon] myFreezemon: possible freeze starting at 11:41:18, delay is 3.624 possibly caused by: tmr-HUEDevice_GetUpdate(WZ.Temperature) tmr-HUEDevice_GetUpdate(WZ.Bewegungsmelder) tmr-HUEDevice_GetUpdate(HUE.DaylightSensor) tmr-HUEDevice_GetUpdate(FL.Bewegungsmelder) tmr-SYSSTAT_GetUpdate(BUE.NASStat) tmr-HUEDevice_GetUpdate(FL.Bewegungsmelder2) tmr-HUEDevice_GetUpdate(WZ.Bewegungsmelder2) tmr-HUEDevice_GetUpdate(WZ.DimmSwitch) tmr-HUEDevice_GetUpdate(SZ.Bewegungsmelder) tmr-HUEDevice_GetUpdate(SZ.DaylightSensor) tmr-HUEDevice_GetUpdate(SZ.Temperature)


Beeinträchtigt aber nicht wirklich die Nutzung meines Systems, weshalb ich das mal als "ist halt so, war wohl schon immer" abstempel.

[Nicees]

Kleines Update:
Nach dem Setzen der Nbl-Variante von reduceLog ist FHEM nicht mehr eingefroren bisher - trotz ausgelastetem NAS. Auch zur Laufzeit des reduceLog selbst ist alles noch weiterhin flott erreichbar. 

Da das Problem sonst im Regelfall alle 24h auftrat würde ich es ganz optimistisch als "gelöst" betiteln.

Vielen Dank!