Hallo,
nachdem meine DBlog Datenbank, auf dem Raspi3 in der letzten Zeit gewachsen ist, bemerke ich beim nächtlichen Backup sporadisch viele Fhem Hänger, während das Backup läuft. Eigentlich sollten doch, wenn ich keine Einstellungsfehler gemacht habe, die Datenbankzugriffe nichtblockierend ausgeführt werden.
Kann ich da noch etwas optimieren, oder muss ich mich ggf. mit einer anderen Hardware, bei der Datenbankgröße beschäftigen?
Oder könnten die Hänger doch von etwas Anderem verursacht werden, während das Backup läuft.
DBLog ConfigCheck jedenfalls erkennt bei mir keine Mängel.
Datenbankgröße derzeit ca. 350 MB, 1,9 Mio. Datensätze
Auszug aus dem Log:
2020.05.03 03:11:36 1: Perfmon: possible freeze starting at 03:11:33, delay is 3.505
2020.05.03 03:13:07 1: Perfmon: possible freeze starting at 03:13:03, delay is 4.798
2020.05.03 03:14:00 1: Perfmon: possible freeze starting at 03:13:52, delay is 8.494
2020.05.03 03:14:43 1: Perfmon: possible freeze starting at 03:14:37, delay is 6.977
2020.05.03 03:15:00 1: Perfmon: possible freeze starting at 03:14:57, delay is 3.333
2020.05.03 03:15:43 1: Perfmon: possible freeze starting at 03:15:39, delay is 4.825
2020.05.03 03:15:43 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 DC 00 00 00 06] 00 01 42 DC 00 08
2020.05.03 03:16:00 1: Perfmon: possible freeze starting at 03:15:48, delay is 12.58
2020.05.03 03:16:07 1: Perfmon: possible freeze starting at 03:16:01, delay is 6.563
2020.05.03 03:16:10 1: Perfmon: possible freeze starting at 03:16:08, delay is 2.618
2020.05.03 03:16:44 1: Perfmon: possible freeze starting at 03:16:43, delay is 1.408
2020.05.03 03:17:31 1: Perfmon: possible freeze starting at 03:17:29, delay is 2.54
2020.05.03 03:17:31 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 CC 00 00 00 06] 00 01 42 CC 00 08
2020.05.03 03:18:00 1: Perfmon: possible freeze starting at 03:17:59, delay is 1.303
2020.05.03 03:18:18 1: Perfmon: possible freeze starting at 03:18:16, delay is 2.765
2020.05.03 03:18:22 1: Perfmon: possible freeze starting at 03:18:19, delay is 3.105
2020.05.03 03:19:05 1: Perfmon: possible freeze starting at 03:19:02, delay is 3.183
2020.05.03 03:19:19 1: Perfmon: possible freeze starting at 03:19:17, delay is 2.298
2020.05.03 03:20:29 1: Perfmon: possible freeze starting at 03:20:25, delay is 4.017
2020.05.03 03:22:17 1: Perfmon: possible freeze starting at 03:22:07, delay is 10.82
2020.05.03 03:22:31 1: Perfmon: possible freeze starting at 03:22:18, delay is 13.364
Mein at Aufruf von DBRep:
defmod at_DBLog_Backup at *03:05:55 set DBReport dumpMySQL clientSide
attr at_DBLog_Backup DbLogExclude .*
attr at_DBLog_Backup comment Dieses at startet täglich in der Nacht ein Backup der SQL Datenbank (Dump).
attr at_DBLog_Backup group Hardware
attr at_DBLog_Backup icon system_backup
attr at_DBLog_Backup room Logging
Das DBRep Device:
defmod DBReport DbRep DBLogging
attr DBReport DbLogExclude .*
attr DBReport DbLogInclude INFO_history.data_index_length_MB.*,INFO_history.number_of_rows.*
attr DBReport comment Dies ist das aktuelle Reportdevice der aktuellen DbLog SQL-Datenbank, mit diesem Devise können Datenbankbefehle und Reports ausgeführt werden.
attr DBReport devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBReport dumpDirLocal /opt/fhem/backup
attr DBReport dumpFilesKeep 8
attr DBReport group Hardware
attr DBReport icon system_backup
attr DBReport optimizeTablesBeforeDump 1
attr DBReport room Logging
attr DBReport showTableInfo %history%,%current%
attr DBReport showproctime 1
attr DBReport timeDiffToNow d:32
attr DBReport timeOlderThan d:30
attr DBReport verbose 2
DBlog selbst:
defmod DBLogging DbLog /opt/fhem/contrib/dblog/db.conf .*:.*
attr DBLogging DbLogExclude .*
attr DBLogging DbLogSelectionMode Exclude/Include
attr DBLogging DbLogType History
attr DBLogging asyncMode 1
attr DBLogging bulkInsert 1
attr DBLogging comment Dieses ist das aktuelle Logdevice, welches die Daten in die SQL-Datenbank schreibt.
attr DBLogging devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBLogging group Hardware
attr DBLogging icon system_backup
attr DBLogging room Logging
attr DBLogging verbose 2
Die vielen Hänger treten nicht täglich auf, sondern ich beobachte diese nur an einigen Tagen pro Monat.
Über Hinweise und Anregungen wäre ich dankbar.
Gruß Reinhard
Hallo Reinhard,
das verwendete dumpMySQL clientSide ist relativ speicherintentensiv.
Es könnte sein, dass unter ungünstigen Umständen bei dir der Speicher aufgebraucht ist und die Maschine beginnt zu swappen was zu den Hängern führen könnte.
Du kannst mit den Attributen "dumpMemlimit" und "dumpSpeed" das Speicher- und auch Laufzeitverhalten beeinflussen.
Musst du versuchen damit zu experimenrieren.
Andere Varainte wäre auf dumpMySQL serverSide umzustellen. Das Verfahren nutzt eine andere Technologie und braucht weniger Speicher.
Meistens reicht dieses Backup aus, wir braucehn üblicherweise die SQLs nicht um die Tabellen zu erstellen. Das können wir vorher manuell machen im Bedarfsfall.
Weitere Variante wäre zu schauen was zu der Zeit noch läuft und den Speicher in Summe zu sehr auslastet.
Die Datenbankprozesse an sich sind non-blocking.
Grüße,
Heiko
Hallo Heiko,
vielen Dank für die schnelle Antwort.
Da bin ich schon beruhigt, ich hatte schon befürchtet, ich hätte da in den Konfiguration etwas übersehen.
Das was du vermutest wird es wahrscheinlich sein, ich hatte mal verbose 4 eingestellt, da war aber auch nicht viel mehr zu erkennen. Swappen ist ja für Linux und Fhem kein Fehler.
So wie ich die Commandref interpretiere sind als Standard für dumpMemlimit 100000 Zeichen und für dumpSpeed 10000 Zeilen voreingestellt. Mit welchen Einstellungen würdest du anfangen zu experimentieren?
Wenn ich nun jeweils die Werte halbiere, wirkt sich dies wahrscheinlich auf die Ausführungszeit des Backups aus, das wäre aber nicht so tragisch, wenn dadurch die Hänger verschwinden. Ich beginne mal mit dumpSpeed 5000 und beobachte auf Hänger.
Zum Thema Umstellen auf dumpMySQL serverSide:
Dies würde ich eventuell angehen, wenn mit den beiden Attributen keine Verbesserung erreicht wird.
Gruß Reinhard
Ich würde dumpMemlimit erstmal auf 10000 reduzieren. Halbieren wäre vermutlich zuviel des Guten.
Die Attribute haben Abhängigkeit voneinander. Aber das wird vom Modul geprüft.
LG,
Heiko
Hallo Heiko,
mein Problem mit den Hängern lässt sich mit den Attributen dumpMemlimit und dumpSpeed nicht lösen. Ich habe nun beide Werte auf bis zu 25% reduziert, der Dump dauert nun mehrere Stunden, aber die Hänger treten unverändert, nur während des Dumps auf. Bin jetzt wieder auf die Standardeinstellungen zurück.
ZitatAndere Varainte wäre auf dumpMySQL serverSide umzustellen. Das Verfahren nutzt eine andere Technologie und braucht weniger Speicher.
Meistens reicht dieses Backup aus, wir braucehn üblicherweise die SQLs nicht um die Tabellen zu erstellen. Das können wir vorher manuell machen im Bedarfsfall.
Ich würde nun den Versuch machen wollen und mein dump auf "serverSide" umstellen. Dabei ändert sich aber vermutlich die Widerherstellungsprodzedur der gesicherten Datenbank grundlegend. Die Wiederherstellung vom "clientSide" Dump hatte ich schon mehrmals erfolgreich durchgeführt.
Bei mir läuft Fhem und MariaDB auf dem gleichen Raspi3 auf einer SD-Card (tausche ich regelmäßig und Backups werden auf anderen Rechner ausgelagert).
So wie ich es in der Commandref verstanden habe, muss ich nur unter
dumpMySQL clientSide gegen
serverSide tauschen. Das eingestellte Verzeichnis unter
dumpDirLocal sollte immer noch gültig bleiben. Habe ich da noch etwas überlesen, was ich bei der Umstellung beachten muss?
In jedem Fall möchte ich das Restore vor einem echten Problem mal durchführen, hast du da einen Link wo die Vorgehensweise auch für nicht geübte SQL-Profis beschrieben ist.
Gruß Reinhard
Hallo Reinhard,
ZitatSo wie ich es in der Commandref verstanden habe, muss ich nur unter dumpMySQL clientSide gegen serverSide tauschen. Das eingestellte Verzeichnis unter dumpDirLocal sollte immer noch gültig bleiben. Habe ich da noch etwas überlesen, was ich bei der Umstellung beachten muss?
Soweit richtig, nur das Attr
dumpDirRemote musst du noch setzen, auch wenn der MySQL Server eigentlich lokal läuft. Die Angabe teilt dem Server mit wohin er das File schreiben soll.
Ich erstelle im Wiki eine Anleitung für Backup / Restore mit dieser Option. Das verdeutlicht vieles denke ich.
LG,
Heiko
Hallo Reinhard,
ich habe eine Anleitung für die serverSide Option im Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Backup.2FRestore_einer_MySQL.2FMariaDB_Datenbank_im_laufenden_Betrieb) hinterlegt.
Grüße,Heiko
Hallo Heiko,
vielen dank für die ausführliche Anleitung im WIKI.
Obwohl du die Anleitung sehr umfangreich erstellt hast, wird es dazu von meiner Seite noch die eine oder andere Frage geben.
Das Ziel sollte nicht nur sein Backups zu erstellen, sondern auch das Restore zu testen, damit im Fehlerfall die Hektik nicht um sich greift ;)
Nochmals Danke für dein Arbeit (und deine unermüdliche Geduld mit uns Usern).
Gruß Reinhard
Moin Reinhard,
gerne doch. :)
ZitatObwohl du die Anleitung sehr umfangreich erstellt hast, wird es dazu von meiner Seite noch die eine oder andere Frage geben.
Kein Problem, einfach fragen. Ggf. wird der Wiki-Beitrag noch ergänzt.
ZitatDas Ziel sollte nicht nur sein Backups zu erstellen, sondern auch das Restore zu testen, damit im Fehlerfall die Hektik nicht um sich greift
Vollkommen richtig. Man sollte restore auch mal geübt haben. Restore ist ja auch mit beschrieben.Wenn du Lust hast, erstellst du dir einfach eine neue DB zum Üben, mit einem DbLog und DbRep. Dort kannst du nach Belieben dumpen und restoren. Du kannst dir auch ein serverSide-Backup deiner produktiven DB reinladen.Wie das geht, sage ich dir falls du mal an diesen Punkt kommen solltest.
LG,Heiko
Hallo Reinhard,
eine Bitte ... kannst du mal bei Gelegenheit den Threadtitel ändern zum Beispiel in
"DBRep-MySQL Backup produziert viele Fhem Hänger"
Ich möchte nicht, dass unbedarfte Anfänger glauben das DbRep-Modul arbeitet blockierend, produziert per se freezes und bei der nächsten Gelegenheit wird auf diesen Thread verwiesen und ich muß es wieder gerade rücken ;)
Danke und LG,
Heiko
Herzlichen Dank Reinhard ... das hat mich wirklich sehr gefreut !!! :D :D
Ich versuche weiterhin wo es geht zu helfen wenn ich kann und auch die Module weiter zu verbessern/auszubauen.
Im Sommer geht FHEM ein bisschen auf Sparflamme wegen der Gartenarbeit und den Naturerlebnissen. ;)
schönen Tag !
LG,
Heiko
Hallo Heiko,
ich habe das Dump bei mir nun auf serverSide umgestellt.
Ich beobachte nun aber viele Hänger während der Tabellenoptimierung (war aber auch die vergangenen Tage unter "clientSide" so:
2020.05.17 10:10:32 3: DbRep DBReport - ################################################################
2020.05.17 10:10:32 3: DbRep DBReport - ### New database serverSide dump ###
2020.05.17 10:10:32 3: DbRep DBReport - ################################################################
2020.05.17 10:10:32 3: DbRep DBReport - execute command before dump: 'set DBLogging reopen 3600'
2020.05.17 10:10:32 2: DbLog DBLogging: Connection closed until 11:10:32 (3600 seconds).
2020.05.17 10:10:32 3: DbRep DBReport - Searching for tables inside database fhem....
2020.05.17 10:10:32 3: DbRep DBReport - Size of database fhem before optimize (MB): 348.33
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing tables
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing table `current` (INNODB). It will take a while.
2020.05.17 10:10:32 3: DbRep DBReport - Table 1 `current` optimized successfully.
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing table `history` (INNODB). It will take a while.
2020.05.17 10:11:30 1: Perfmon: possible freeze starting at 10:11:29, delay is 1.974
2020.05.17 10:11:36 1: Perfmon: possible freeze starting at 10:11:31, delay is 5.404
2020.05.17 10:13:45 1: Perfmon: possible freeze starting at 10:13:44, delay is 1.004
2020.05.17 10:15:14 1: Perfmon: possible freeze starting at 10:15:13, delay is 1.335
2020.05.17 10:15:31 1: Perfmon: possible freeze starting at 10:15:29, delay is 2.569
2020.05.17 10:17:13 1: Perfmon: possible freeze starting at 10:17:08, delay is 5.886
2020.05.17 10:18:08 1: Perfmon: possible freeze starting at 10:17:57, delay is 11.26
2020.05.17 10:18:14 1: Perfmon: possible freeze starting at 10:18:09, delay is 4.968
2020.05.17 10:21:28 1: Perfmon: possible freeze starting at 10:21:13, delay is 15.831
2020.05.17 10:23:21 1: Perfmon: possible freeze starting at 10:23:04, delay is 17.435
2020.05.17 10:24:28 1: Perfmon: possible freeze starting at 10:24:23, delay is 5.067
2020.05.17 10:24:28 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 D9 00 00 00 06] 00 01 42 D9 00 08
2020.05.17 10:25:35 3: DbRep DBReport - Table 2 `history` optimized successfully.
2020.05.17 10:25:35 3: DbRep DBReport - 2 tables have been optimized.
2020.05.17 10:25:35 3: DbRep DBReport - Size of database fhem after optimize (MB): 351.33 Ich denke irgendwann muss ich mich mal mit anderer Hardware als einem Raspi beschäftigen.
Wenn man einen 10 Meter Wohnwagen besitzt, zieht diesen auch nicht ein 500'er Fiat :)
Irgendwie fehlt mir da komplett das Gefühl, sollte denn eine Datenbankgröße von ca. 350 MB, mit unter 2 Mio. Datensätzen mit SQL auf einem Raspi3 noch zu betreiben sein oder platzt der da aus allen Nähten?
Ich habe auch schon daran gedacht meine SD Speicherkarte zu erneuern (mache ich jährlich).
Ich bin fest der Überzeugung, dass meine Hardware an die Grenzen stößt. Alleine mit Logdateien (ohne DBLog) wäre diese Datenflut sicherlich nicht mehr zu bändigen.
Jetz habe ich aber noch ein Rechteproblem, dazu brächte ich noch deine Hilfe:
2020.05.17 10:25:35 2: DbRep DBReport - DBD::mysql::st execute failed: Access denied for user 'NAME'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 7730.Habe mich eben in meine MariaDB über die Konsole eingeloggt, hier kann ich mich mit dem User "NAME" und dem Kennwort "PASSWORT" problemlos anmelden. Ich habe hier die gleichen Zugangsdaten wie für Fhem auch verwendet, deshalb kann ich mir nicht ganz erklären, was hier noch fehlt. Sollte dies die Schreibrechte für das Backup Verzeichnis betreffen? Wenn ich hier nachsehe, so sind diese auf "fhem dialout" mit allen Rechten eingestellt.
Anbei die RAW Definition meines DBRep Device, welches über ein at mit ServerSide aufgerufen wird:
defmod DBReport DbRep DBLogging
attr DBReport DbLogExclude .*
attr DBReport DbLogInclude INFO_history.data_index_length_MB.*,INFO_history.number_of_rows.*
attr DBReport comment Dies ist das aktuelle Reportdevice der aktuellen DbLog SQL-Datenbank, mit diesem Devise können Datenbankbefehle und Reports ausgeführt werden.
attr DBReport devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBReport dumpDirLocal /opt/fhem/backup
attr DBReport dumpDirRemote /opt/fhem/backup
attr DBReport dumpFilesKeep 8
attr DBReport executeAfterProc set DBLogging reopen
attr DBReport executeBeforeProc set DBLogging reopen 3600
attr DBReport group Hardware
attr DBReport icon system_backup
attr DBReport optimizeTablesBeforeDump 1
attr DBReport room Logging
attr DBReport showTableInfo %history%,%current%
attr DBReport showproctime 1
attr DBReport timeDiffToNow d:32
attr DBReport timeOlderThan d:30
attr DBReport verbose 3
Ich habe im DBRep device wie von dir im WIKI unter "Restore" beschrieben:
Zitatset <Name> adminCredentials <Name> <Passwort>
attr <Name> useAdminCredentials 1
versucht, aber leider hier nicht mit dem gewünschten Erfolg.
SqlResultRow_1 GRANTS FOR USER@% 2020-05-17 11:51:34
SqlResultRow_2 GRANT USAGE ON *.* TO 'USER'@'%' IDENTIFIED BY PASSWORD '*...............................' 2020-05-17 11:51:34
SqlResultRow_3 GRANT SELECT, INSERT, UPDATE, DELETE ON `fhem`.* TO 'USER'@'%' 2020-05-17 11:51:34
SqlResultRow_4 GRANT SELECT, INSERT, UPDATE, DELETE ON `old-fhem`.* TO 'USER'@'%' 2020-05-17 11:51:34
aftersqlCmd_message Reopen executed. 2020-05-17 11:51:34
background_processing_time 0.0235 2020-05-17 11:51:34
sqlCmd show grants; 2020-05-17 11:51:34
sqlResultNumRows 3 2020-05-17 11:51:34
sql_processing_time 0.0153 2020-05-17 11:51:34
state Warning - sqlCmd finished, but command message after sqlCmd appeared 2020-05-17 11:51:34hab noch ein wenig gesucht, in meinem db.conf File steht:
#
# database configuration file
#
#
## for MySQL
################################################################
%dbconfig= (
connection => "mysql:database=fhem;host=localhost;port=3306",
user => "NAME",
password => "PASSWORD",
utf8 => 1
);
.........Wobei hier unter user der gleiche user, wie in der DBRep Fehlermeldung und unter "show grants" eingetragen ist.
Gruß Reinhard
Moin Reinhard,
ZitatIch denke irgendwann muss ich mich mal mit anderer Hardware als einem Raspi beschäftigen.
Wenn man einen 10 Meter Wohnwagen besitzt, zieht diesen auch nicht ein 500'er Fiat :)
Irgendwie fehlt mir da komplett das Gefühl, sollte denn eine Datenbankgröße von ca. 350 MB, mit unter 2 Mio. Datensätzen mit SQL auf einem Raspi3 noch zu betreiben sein oder platzt der da aus allen Nähten?
Ein Raspi ist ganz allgemein keine ideale Hardware für eine MySQL. Aber trotzdem ist die DB-Größe an sich nicht das Problem. Letztendlich ist es erstmal nur eine oder mehrere große Files solange sie sich auf dem Datenträger befinden.
Nur die Verarbeitung der Daten kann Engpässe in CPU-Leistung und RAM verursachen, was man aber versuchen kann zu optimieren. Meine (Test)DB's sind teilweise 5 GB oder auch 8 GB groß und laufen rund. Allerdings auf einer Synology muss ich gestehen.
Man kann den für den MySQL Server allokierten Speicher generell beschränken. Das passiert in den Parametern des MySQL-Servers, i.A. in der Datei /etc/mysql/my.cnf.
Ein wesentlicher Parameter ist
innodb_buffer_pool_size Vielleicht ist der bei dir generell zu groß eingestellt (innodb_buffer_pool_size = 300 M) ?
Alternativ schaltest du die Tabellenoptimierung einfach mal ab für das Backup (optimizeTablesBeforeDump = 0).
ZitatHabe mich eben in meine MariaDB über die Konsole eingeloggt, hier kann ich mich mit dem User "NAME" und dem Kennwort "PASSWORT" problemlos anmelden. Ich habe hier die gleichen Zugangsdaten wie für Fhem auch verwendet, deshalb kann ich mir nicht ganz erklären, was hier noch fehlt. Sollte dies die Schreibrechte für das Backup Verzeichnis betreffen? Wenn ich hier nachsehe, so sind diese auf "fhem dialout" mit allen Rechten eingestellt.
Mit den Rechten für das Filesystem hat das nichts zu tun.
Aber in dem "show grants" (super Info :) ) sehe ich dass dem User das globale Recht "FILE" fehlt. Das müsstest du ihm geben über deine Userverwaltung) und dann nochmal probieren.
Ich ergänze es noch im Wiki, in der CommandRef steht es drin.
ZitatIch habe im DBRep device wie von dir im WIKI unter "Restore" beschrieben:
set <Name> adminCredentials <Name> <Passwort>
attr <Name> useAdminCredentials 1
versucht, aber leider hier nicht mit dem gewünschten Erfolg.
Die adminCredentials werden nur für die Abarbeitung von "sqlCmd" verwendet. In dem Wiki Beispiel für den truncate Befehl.
Ich denke mal drüber nach ob es auch Sinn macht diese Möglichkeit für den restore mit vorzusehen. Dadurch könnte man wahrscheinlich das "FILE"-Rechteproblem umgehen.
LG,
Heiko
Hallo Heiko,
ich denke ich habe den Fehler bei mir gefunden.
In der Commandref steht:
ZitatDas Zielverzeichnis kann mit dem Attribut "dumpDirRemote" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.
Nach dem SQL-Befehl "
GRANT FILE ON *.* TO 'BENUTZER'@'%'; " unter mySQL als user "root" hat der Dump geklappt.
Der Dump ohne "optimizeTablesBeforeDump" läuft nun in weniger als 2 Minuten, ohne einen einzigen Hänger:
2020.05.17 12:47:07 3: DbRep DBReport - ################################################################
2020.05.17 12:47:07 3: DbRep DBReport - ### New database serverSide dump ###
2020.05.17 12:47:07 3: DbRep DBReport - ################################################################
2020.05.17 12:47:07 3: DbRep DBReport - execute command before dump: 'set DBLogging reopen 3600'
2020.05.17 12:47:07 2: DbLog DBLogging: Connection closed until 13:47:07 (3600 seconds).
2020.05.17 12:47:07 3: DbRep DBReport - Searching for tables inside database fhem....
2020.05.17 12:47:07 3: DbRep DBReport - Starting dump of database 'fhem', table 'history'
2020.05.17 12:48:40 3: DbRep DBReport - Number of exported datasets: 1895104
2020.05.17 12:48:40 3: DbRep DBReport - Size of backupfile: 168.74 MB
2020.05.17 12:48:40 3: DbRep DBReport - Finished backup of database fhem - total time used (hh:mm:ss): 00:01:32
2020.05.17 12:48:40 2: DbRep DBReport - command message after dump: "Reopen executed."
2020.05.17 12:48:40 3: DbRep DBReport - Database dump finished successfully. Gruß Reinhard
Super Reinhard :)
Wiki ergänze ich noch bzgl. FILE Privileg und baue vlt. useAdminCredentials auch für das Restore ein.
Mal schauen.
LG,
Heiko
Das Wiki (https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#3._Backup_durchf.C3.BChren_2) ist jetzt um den Part FILE Privileg ergänzt. Kannst ja mal schauen ob es auch Anwendersicht auch klar verständlich ist.
LG,
Heiko
Hallo Heiko,
ich denke die Doku im Wiki ist verständlich gehalten. Selbst ich würde es mit dieser Anleitung schaffen. :)
Ich habe mein "FILE Privileg" über die Console, unter MariaDB gesetzt, habe garnicht daran gedacht, dass ich es auch mit "sqlCmd" über DBRep erledigen konnte.
Heiko noch eine Frage drängt sich mir auf, in Zusammenhang mit DBRep.
Ich verwende DBRep derzeit intensiv zur Auswertung meines neuen E3DC Stromspeichers und habe dazu einige DbRep Devices angelegt, welche mir unterschiedliche Ergebnisse aus den Readings berechnen. Da sich aber alle DbRep Device aktiv mit der SQL-Datenbank verbinden, gibt es da deiner Erfahrung nach eine Grenze, wo es bezüglich des Speicherverbrauchs (Raspi3) kritisch wird?
Bei mir sind aktuell 20 DbRep Device mit der Datenbank verbunden, welche ich nur äußerst "sparsam" über at Devices starte.
Jedes Device belegt ja vermutlich Speicher, egal ob dieses aktuell läuft oder nur "wartet".
Ich habe jedenfalls noch keine Möglichkeit gefunden die Attribute dynamisch (über Variablen) an das DbRep Device zu übergeben, dann würden man ja mit deutlich weniger auskommen.
Gerne mach ich dazu auch einen neuen Forenbeitrag auf, wenn das hier viel OT wird
Gruß Reinhard
Hallo Reinhard,
ZitatDa sich aber alle DbRep Device aktiv mit der SQL-Datenbank verbinden, gibt es da deiner Erfahrung nach eine Grenze, wo es bezüglich des Speicherverbrauchs (Raspi3) kritisch wird?
bei mir laufen 127 produktive DbReps. Grenze nach oben theoretisch offen.
Das aktive Verbinden ist nur temporär solange das Device auf der DB werkelt. Wenn die Aufgabe fertig ist, wird die Verbindung zur DB abgebaut. Ich habe bei allen DbReps das Attribut "fastStart = 1" gesetzt. Dadurch verbinden sich die Devices beim Start von FHEM nicht gleichzeitig alle, sondern erst wenn sie eine Aufgabe abarbeiten müssen.
Ich überlege diese Einstellung zum Default zu machen.
Einstellung geht für alle in einem Rutsch leicht:
attr TYPE=DbRep fastStart 1Wirklich Speicher wird nur während der Arbeit in den Nebenprozessen (BlockingCall) verbraucht. Es gibt aber ein globales Attribut
blockingCallMax mit dem man einer zu hohen System RAM-Auslastung vorbeugen kann:
blockingCallMax
Begrenzt die Anzahl der parallel laufenden Prozesse, die von der BlockingCall FHEM Hilfsroutine gestartet wurden. Sinnvoll auf weniger leistungsfaehigen Hardware, die Voreinstellung ist 32. Nach erreichen dieser Grenze werden weitere Aufrufe verzögert. Das wirkt dann für alle, denn nicht nur DbRep verwendet BlockingCall um nebenlaufende Prozesse zu starten.
Richtig eingestellt, kannst du m.M. nach dein System vor Überlastung schützen. Mit Verzögerungen beim Start einer Aufgabe kann man sicherlich leben.
Ansonsten wird Speicher im Prinzip nur durch die entstehenden Readings verbraucht. Also wenn man z.B. eine Ergebnismenge von 1000 / 2000 Readings hat (fetchrows), wird natürlich Speicher verbraucht.
Aber auch das kann man wieder beseitigen. Wenn du diese Daten nur temporär brauchst, kannst du die Readings mit dem Setter "eraseReadings" wieder loswerden und der durch die Readings belegte Speicher wird an Perl zurück gegeben.
Das sind eigentlich die "Highlights" zu diesen Überlegungen. :)
LG,
Heiko
Hallo Heiko,
danke für die vielen Tipps, ich setze diese in meiner Konfiguration um.
Ich will nur aktuell nicht mehr viel an den Einstellungen ändern, da mein Fhem in nächsten Wochen ohne Aufsicht laufen soll (Urlaub wird in DE wieder möglich :).
Nichts schlimmer als wenn man vorher noch Änderungen tätigt oder Updates fährt, welche an anderer Stelle dann zu Problemen führen.
Nachdem die Hänger nun, durch die Umstellung des Dumps auf serverSide verschwunden sind, ist bei mir (derzeit) alles im grünen Bereich.
Aber ich wende die Tipps in jeden Fall bei meiner Konfiguration an, "fastStart" habe ich bei allen DbReps schon gesetzt.
Gruß Reinhard