Hallo Leute,
die hier soll mal eine Ideensammlung für das leidige Problem einer zu groß gewordenen DBLog Datei werden.
Hintergrund: Ich verwende 3 verschiedene Raspberry`s für meine Anwendungen. Auf 2 Maschinen läuft eine SQLite Datenbank.
Das "Hauptsystem" hat mittlerweile durch ewige Umbauten so einige Datenleichen, die die Datensammlung unnütz füllen.
Pro Jahr ergeben sich so ca. 10-12GB Daten, wovon gut die Hälfte oder auch sehr viel mehr überflüssig ist.
Mein Vorschlag (durchgeführt) dazu ist folgendes:
Erst einmal die Datenbank auf DbLogSelectionMode Exclude/Include einstellen.
DbLogType Current/History, asyncMode sowie eine DbRep Instanz anlegen setze ich voraus.
Dann natürlich erst einmal die üblichen "Verdächtigen" eliminieren:
Jeder Eintrag der irgendwas loggt erhält ein DbLogExclude .* und dann ggf. ein DbLogInclude <name>,<name>,<name>...
Damit wird erst mal nur noch das geloggt was man auch will. Das ist sehr aufwendig aber leider unumgänglich.
Auf dem Hauptsystem eine größere Veränderung der Datenbank zu machen ist gefährlich
und kostet unendlich Rechnerzeit die das ganze System ggf. zum Absturz bringt (ist passiert >:()
Also der neue Pi4 mit SSD musste herhalten mit einem leeren fhem zum Testen.
Die ganze Datenbank dort hineinkopiert und zum laufen gebracht.
Dann darin die Befehle repairSQLite(ggf.), delSecDoublets und dann vacuum ausführen.
Bei mir war das Teil dann auf weit unter 40% geschrumpft.
Ich hatte mit Heiko (DS_Starter) über dies Thema gesprochen und der Befehl delSecDoublets ist sicher der, der das beste Ergebnis bringt.
Es müssten eigentlich alle alten und überflüssigen Datensätze gelöscht werden, dies ist viel zu aufwendig.
Mit delSecDoublets werden bei langen gleichen Einträgen alle, bis auf den ersten und letzten Datensatz gelöscht.
Und genau das bringt die Verkleinerung. Sicher, es sind dann immer noch viele unnütze Daten drin, aber wesendlich weniger als vorher,
weil ja alle Wiederholungen mit den gleichen Daten gelöscht werden.
So - nun die kleinere Datenbank wieder Zurück - aber wie?
Lösungsvorschlag dazu:
Auf dem Hauptsystem die laufende Datenbank einfach neu Aufsetzen (Erstellen wie im Wiki beschrieben).
Die ist dann zwar leer, aber läuft sicher und fehlerfrei.
Auf dem Zweitsystem die Daten mit set myDbRep exportToFile /opt/fhem/log/exportdB.csv rauskopieren
und diese Datei ins Hauptsystem kopieren und dann mit set myDbRep importFromFile /opt/fhem/log/exportdB.csv einfügen.
Das dauert seine Zeit, ist aber nonblocking und auch recht sicher.
Tip: Wenn der erste Schritt - übertragen der Datenbank ins neue, leere System nicht funktioniert
einfach all diese Schritte andersherum machen. Dauert auch aber funktioniert absolut.
So - nun seid Ihr dran: Ist das ein gangbarer Weg, oder völliger Blödsinn?
Schreibt hier einfach mal Eure Meinung und Vorschläge dazu.
Grüße aus Peine, Niedersachen
Wolfdieter
Hallo Dieter ;)
bin mir nicht sicher, ob ich das Anliegen genau verstanden habe, aber ich versuchs mal:
Genau sowas ist mein Alptraum, wenn mein System so weiter wächst wie bisher, (was zu "befürchten" ist). Nämlich, dass irgendwelche Daten vollkommen unnutz mitgeloggtwerden. Erstmal vorab ein paar Fragen, (ob Du nun mutig bist, das dann auf dem Live System zu machen, oder dafür lieber das Testsystem nimmst und dann hin und her kopierst, sei ja dahin gestellt) :
- Was loggst Du alles, dass das Ding nach einem Jahr auf 10-12 GB anwachsen kann? (Ich frage, weil ich der Meinung bin, dass ich viele Temperaturen zu detailliert logge und dennoch grad mal bei 50 MB / 172665 Einträgen bin - seit ca. Juni letzten Jahres)
- Welche Daten (davon) sind Dir besonders wichtig, dass Du sie auf keinen Fall verlieren möchtest ?
- Was spricht gegen die Boardmittel von DBlog also "deleteOldDays" und "ReduceLog" ?
ZitatJeder Eintrag der irgendwas loggt erhält ein DbLogExclude .* und dann ggf. ein DbLogInclude <name>,<name>,<name>
Passiert das automatisch, oder kann es sein dass Du mal ein "DBLogExclude vergisst ?
Die Anweisungen von Dir klingen grundsätzlich super, weil ich glaube, dass man sich damit viele Sicherheiten schafft, falls unterwegs eben doch was schief geht.
Was ich für meinen Fall gemacht habe (noch ist die DB recht klein und das soll sie auch bleiben):
- Include / Exclude verwenden, wobei "DBLogExclude" automatisch angelegt wird, sobald ein Gerät angelegt wird
- (noch) Händisch und regelmäßig die alten Einträge löschen und ReduceLog laufen lassen
- Zusätzlich hat der gute Mann hier ( ja ich weiss, viele mögen die Seite nicht besonders, ich finde aber einige Tipps sehr gut) einige Beispiele gezeigt, wie man seine Device-Leichen loswerden kann
Meiner Meinung nach kann man nur früh genug drauf achten, was alles mitgeloggt wird und schnell genau (automatisch) aufräumen. Das ist die beste Veriante. Natürlich ist es gut zu wissen, wenn sich eine Temperatur / Zustand von etwas ändert. Aber muss ich diese Infos Monate / Jahre später noch genauso detailliert haben ? - Hier finde ich eben nein und daher ist ReduceLog eine Wunderwaffe gegen zu viele Leichen ;)
Grüße
Andreas
Nur mal dumm gefragt: Warum mit Exclude/Include loggen, wenn man dann sowieso erstmal alles ausschliesst? Ich logge seit Jahren nur im Include mode, Reduce log macht definitv Sinn. Man kann aber auch in regelmäßigen oder unregelmäßigen Abständen einfach eine neue DB machen, die alte irgendwohin archivieren und löschen oder in unterschiedliche Datenbanken loggen... Es gibt viele Wege... Einfach alles zu loggen und wachsen zu lassen, bis es knallt, ist aber definitiv der falsche :-)
Kurz, weil mobil
Zitat von: KernSani am 10 Januar 2020, 20:13:19
Nur mal dumm gefragt: Warum mit Exclude/Include loggen, wenn man dann sowieso erstmal alles ausschliesst? Ich logge seit Jahren nur im Include mode, Reduce log macht definitv Sinn.
Ja es klang halt schon sehr sinnvoll, aber hmmm jetzt wo Du es sagst *grübel* Ich stelle den Log um auf "nur" include ... und kann mir überall "exclude" .* sparen und ignorieren. Somit sicher auch 1/100000 Performence sparen. Aber Ich schau nach jemden Kleinteil, also macht das auch Sinn :)
Danke für den Hinweis..*thumbsup*.. Oder hab ich irgendeinen Nachteil von Incluce und weglassen von Exclude übersehen ?
Grüße
Andreas
Exclude/Include macht m.E. Sinn, wenn du auf globaler Ebene kräftig ausmistest. Das ist vermutlich auch bez. Performance der beste Weg.
Kurz, weil mobil
Na so langsam kommt ja Bewegung in die Angelegenheit.
Danke erst mal für die Antworten. :)
@flummy1978 : Ich logge viele Daten aus meiner Wetterstation, Poolsteuerung, Heizung mit Solarunterstützung usw.
Diese "Riesenmenge" ist sicher den Fehlern der Vergangenheit geschuldet.
Nachdem ich nun mal richtig aufgeräumt habe, wird die zukünftige Menge vermutlich erheblich kleiner (hoffentlich). :-[
@KernSani : Include Mode hab ich auch mal überlegt, aber alles neu Überarbeiten war mir dann doch zuviel Arbeit.
Das ist sicher der einfachste Weg nur ich hab anders angefangen und werde das wohl auch so weitermachen.
Bei welchem Mode ist denn die Performance am Besten?
Das ist eine Sache die ich überhaupt noch nicht so richtig durchblicke.
MySQL ist vermutlich auch nicht die schnellste Datenbank.
An dem Punkt fehlt mir Wissen, auch bez. eines Umzugs in eine neue, andere Version.
Die Sache mit dem ReduceLog ist bei mir noch offen. Nachdem ich eingie "Abstürze" mit dem Life-System hatte
bin ich zu meiner Variante mit dem Testsystem gewechselt.
Aber ist ist ein guter Gedanke dort einfach mal ReduceLog zu probieren - passiert ja nix weiter....
Gruß Wolfdieter
Holla,
Zitat von: dieter114 am 11 Januar 2020, 12:54:40
@flummy1978 : Ich logge viele Daten aus meiner Wetterstation, Poolsteuerung, Heizung mit Solarunterstützung usw.
Diese "Riesenmenge" ist sicher den Fehlern der Vergangenheit geschuldet.
Nachdem ich nun mal richtig aufgeräumt habe, wird die zukünftige Menge vermutlich erheblich kleiner (hoffentlich). :-[
Kann ich relativ gut mit der Antwort aus einem anderen Beitrag verbinden ( weil es im Prinzip der gleiche Sinn ist ):
.... irgendwann hat man die Kinderkrankheiten im Griff, so dass man das Meiste davon nicht mehr braucht und dennoch sind die Logs noch da. Und eben um DIESE Logs zu sparen, versucht man (so ging es mir zumindest) auf die Masse an Event zu unterbinden die man persönlich nicht benötigt.
Ich für meinen Teil mache das jetzt so, dass ich alle Tage (oder wenn ich wenig gebastelt habe Wochen) für 1-3 Tage ein .* Log erstelle und kontrolliere damit ob ich irgendwo Events hab, die vollkommen unnötig sind, diese aber aktiv sind. So kann ich den Teil dann den letzten Teil, den ich vielleicht übersehen hab dann ausmerzen.... Bisher fahre ich damit ganz gut Nachträglich vieles zu verändern macht natürlich sehr sehr sehr viel Arbeit .... ABER ein abgestürztes System, weil man vorher nicht die Lust dazu hat, macht sicher noch viel mehr ;)
Aber zu Deinem persönlichen Anliegen, Bitte nicht negativ auffassen - falls mal etwas "böse" klingt, aber ich versuche mal ein wenig aufzulisten worauf ich achten würdeund wie ich vorgehen würde:
- Da Du ja aufs Testsystem gegangen bist den Inhalt der DB komplett kopieren
- Je nachdem wie groß die DB wirklich ist mit ReduceLog von hinten nach vorn arbeiten. D.h.: (Angenommen deine DB ist 2,5 Jahre alt - was mir persönlich schon vieeeeeeeeeeeeeeel zu lang wäre ;) )
- Wetterdaten > Datum x löschen( ich denke mehr als 3 Monate brauchst Du nicht, wenn Du ein Jahr miteinander vergleichen willst, dann eben 13 Monate)
- Das Gleiche mit Pool und Heizungsdaten
- Alles andere älter Datum X rigoros löschen angenommen es bleiben 1,5 Jahre über
- Danach ALLES löschen was keine Statistikdaten hat und nicht benötigt wird (Lichtschalter, Lüfter, Mäh / Saugroboter usw) - Wobei man diese Sachen im Normalfall eh nicht im Log braucht
- (Alternativ auch Alles andere zeitpunkt xy) - Falls Du damit noch nicht viel gemacht hast, unbedingt die Doku zu ReduceLog lesen. Sehr geniales Teil, aber auch sehr mächtig wenn man was falsch eingestellt hat oder uneduldig bei der Ausführung ist ;)
- Dann Reduce Log: zunächst > 1,5 Jahre Dann noch mal > 1 Jahr und dann noch mal größer 6 Monate (um die Wetter und sonstigen Daten zu verarbeiten)
(Wenn es wirklich solche Datenmengen sind, wird selbst ein halbes Jahr schon ne Ewigkeit dauern)
- Hier bin ich mir sicher, bist Du bei einer Datenmenge die vielleicht nur noch 1/5 von der vorherigen hat, wenn überhaupt
- Die letzten 6 Monate blieben dann wiederum ohne Bearbeitung und hätten ALLE detaillierten Daten
- nach JEDEM Schritt ein Backup ist sicherlich nicht verkehrt .... DANACH dann den rest...
ZitatMySQL ist vermutlich auch nicht die schnellste Datenbank.
MySQL ist sicherlich nicht die allerschnellste DB der Welt (liegt ja auch in erster Linie von der verwendeten Hardware ab) aber ich würde hier nicht den Fehler machen und das Problem in der langsamen DB suchen. Das liegt hier ganz wo anders ;)
Wetterstation, Poolsteuerung, Heizung mit Solarunterstützung usw:OK mal angenommen Du filterst die Daten GAR NICHT, dann bekommst Du nur mit Wetterdaten schon eine Masse zusammen die nicht mehr feierlich ist. Wofür ? Was brauchst Du an Wetterdaten (Ganz wichtig IN DER DB - nicht generell) Temperatur, Luftfeuchte, Druck, Regen(wahrscheinlichkeit) / Menge vielleicht noch ein paar spezielle Auswertungen usw. und das wars. ABER für wie lange ? Interessiert Dich jetzt noch wie das Wetter vor 6 Monaten war ? Im Normalfall nicht, also kannst Du hier wiederum mit einem Notify oder sonst irgendwie automatisiert, alte Daten regelmäßig löschen. Die DB wird es Dir danken.
Das Gleiche betrifft Temperaturdaten: Musst Du wissen ob die Temperaturänderung in einem Zimmer nun 10 oder 10.5 Minuten gedauert hat ? Ich mache hierbei immer eine Beschränkung der Daten: Es wird immer nur ein Event erzeugt, WENN sich die Temperatur / Luftfeuchte um bsw: 0,2 °C geändert hat ODER wenn ein gewisser Zeitraum vergangen ist (z.B 90 Min) (Damit die Plots nicht abreissen)
Auch wenn ich nicht KernSani bin, just my2cent:
Wenn dir alles zu überarbeiten zu viel Arbeit wäre (Was je nachdem wieviel es ist verstänlich ist) würde ich persönlich einfach der Reihe nach vorgehen. Z.B. Raumweise, mit der größten Datenflut generell. Ich bin mir sicher, wenn Du die oberen Tipps berücksichtigst und vor allem bei den Wetter und Temperaturdaten etwas auf die Menge achtest, reduzierst Du die DB um sicherlich 60-70 %. Fang mit Include/Exclude an, beschränk erst die Sachen mit Exclude die Du auf KEINEN Fall brauchst, danach dann mit Include alles andere.
HIER wird Dir dann wiederum die Performence dafür danken ;)
Hoffe das hilft Dir ein wenig weiter. Ist nur ein Vorschlag und der Wille zu helfen...... ::)
Viele Grüße
Andreas
Hallo zusammen,
ich möchte euch nur eine kurze Anmerkung geben, dann will ich mich auch bewußt nicht weiter einmischen und eher die reine Usersicht wahrnehmen.
Thema ReduceLog:
ReduceLog gibt es sowhl (historisch) in DbLog, als auch im DbRep. Im DbLog gibt es eine blockierende und nicht-blockierende Variate. Im DbRep arbeitet die Funktion generell nicht blockierend. Im DbRep gibt es feinere Selektionsmöglichkeite über die verschiedenen Attribute. Die Funktion im DbLog wird nicht weiter gepflegt. Im DbRep erfolgt eine Weiterentwicklung sofern Bedarf entsteht.
Ganz allgemein soll sich DbLog auf das Loggen konzentrieren, DbRep auf die Auswertung und Pflege der Datenbankinhalte.
Hat auch was damit zu tun in einem eventuellen DbLog-Nachfolgemodul noSQL-DB's wie InfluxDB mit aufnehmen zu können.
Thema Performance:
Die Performance einer DB ist von sehr vielen Faktoren abhängig. Hardware, aber auch die Indexe und die Parametrisierung des DBMS (sofern möglich) spielen eine Rolle. Verbesserungspotenziale erschließen sich hier meist wenn die Datenbank spezifischen Hinweise im Netz oder der Literatur studiert. Da kann man aber auch allerhand verschlechtern wenn man nicht aufpasst.
Im DbLog/DbRep habt ihr die Attribute showproctime und im DbLog zusätzlich das Attribut showNotifyTime zur Verfügung.
showproctime zeigt euch wie schnell eure Datenbank arbeitet und ist ein recht guter Indikator für die Gesamtperformance.
Wenn ihr also euch miteinander vergleicht, könnt ihr diesen Wert nutzen.
showNotifyTime zeigt euch die Zeit wie schnell Events durch das Modul verarbeitet werden. Es zeigt deutliche Unterschiede wenn ihr den asynchMode ein- oder ausschaltet.
Ist er ausgeschaltet (Standard aus hist. Gründen) hat die Verarbeitungsgeschwindigkeit der DB direkten Einfluss auf euer FHEM und kann zu Freezes bis hin zum Stillstand führen, im asynchMode = 1 hingegen nicht.
Dann gibt es allerdings eine (einstellbare) Verzögerung bis Events in der DB landen.
Damit bin ich auch schon wieder weg. ;)
EDIT: Noch ein kurzer Hinweis. DBMS wie MySQL, PostgreSQL können sehr gut mit parallelen Schreib/Leseprozessen umgehen. Daher ist es bis auf Performancefragen kein Problem mit diesen DB's über DbLog zu loggen und über DbRep die diversen Pflegemaßnahmen durchzuführen.
Grüße,
Heiko
Danke Heiko für diese Klarstellung. :)
Ich glaube nun etwas mehr verstanden zu haben und werde es ausprobieren.
Da mein Life-System ja ohnehin mit einer z.Z. kleineren Datenbank arbeitet
kann ich ja all diese Dinge auf dem Testsystem probieren.
ReduceLog mit 270 Tagen ist gerade fertig geworden,
und hat wie erwartet das Teil um ca. 30-40% verkleinert.
Danke Andreas für die recht ausführliche Darlegung.
Genau so bin ich bereits vorgegangen.
Es ist für mich noch ein langer Weg ;)
Gruß Wolfdieter
Doch noch ein weiterer Hinweis. ;)
Weil man nach einer langen Betriebszeit eventuell wissen möchte, welche Devices und/oder Device/Reading-Kombinationen in der DB überhaupt vorhanden sind, gibt es im DbRep eingebaute Kommandos dafür.
Nähere Beschreibung für eine solche Fragestellung findet sich im Wiki hier:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Welche_Device.2FReading-Kombinationen_gibt_es_in_der_Datenbank_.3F
Grüße,
Heiko