HomeMatic-Forum / FHZ-Forum

Danke.
Ich habe hier
viewtopic.php?f=38&t=24115&start=520#p619493
weiter gefragt, da die DB zwar kleiner ist, grad mal noch 1/4, aber der Speicherplatz fehlt mir nach wie vor.

Hallo,

bei der angegebenen Größe:

Hoppla hat geschrieben: ↑

17.11.2020, 08:19

Im Ordner /volume1/@appstore/ccu-historian/data befindet sich eine Datei
history.mv.db mit der Größe 2.181.840.896...

würde mich interessieren wie lange der CCU-Historian schon läuft und wieviele DP der aufzeichnet?
Das ist ja schon ne heftige Menge für eine Datenbank.
Bei mir läuft der jetzt seit Januar 2017 und die DB ist 9 GB groß. Klar, die DP wuchsen mit der größe der Installation.
Ein Delta ist in der Zwischenzeit auch gesetzt und inaktive DP gibts bei mir auch genug.

Ich würde auch versuchen auf einem extra Rechner mit großer HDD die DB kleiner zu machen.
Hinweise gabs ja schon wie usw.

Grüße,
Slice

Moin

Es sind derzeit 54 Geräte im Einsatz und Historian läuft seit etwa 1 Jahr.
Da mir nicht klar war, welche Datenmengen abgespeichert werden habe ich auch nicht die Datenpunkte reduziert.
Ich war fest der Meinung, das der Parameter// logSystem.fileLimit=1000000 in der Config , deklariert als defaultwert die Größe begrenzt, war falsch, klar, db ist nicht syslogfile.

Nun habe ich das Problem, das zwar die Datenbank nur noch 500MB groß ist, ich kann sie auch problemlos bei gestoppter Historian kopieren, der Plattenplatz von 1,5 TB aber weiter blockiert ist, er wird einfach nicht freigegeben!

Und das ist ein echtes Problem und offensichtlich ein bug!

Moin,

Hoppla hat geschrieben: ↑

19.11.2020, 08:58

Es sind derzeit 54 Geräte im Einsatz und Historian läuft seit etwa 1 Jahr.
...
Nun habe ich das Problem, das zwar die Datenbank nur noch 500MB groß ist, ich kann sie auch problemlos bei gestoppter Historian kopieren, der Plattenplatz von 1,5 TB aber weiter blockiert ist, er wird einfach nicht freigegeben!

Interessant, weil das sind wirklich nicht so viele Geräte und der Zeitraum ist ja auch nicht lang.
Da würde ich vorschlagen, die Daten der Festplatte zu sichern und die Platte neu zu formatieren.
Dann solltest Du die richtige Größe wieder haben und kannst die Daten wieder zurück kopieren.
Das sieht für mich wie schon gesagt bei der DB Größe nach irgendeinem Fehler aus, welcher kann ich Dir leider nicht sagen.
Aber normal ist die DB Größe ja nicht..

Grüße,
Slice

Platte formatieren ist bei einem NAS nicht wirklich die Option, die man als erstes nimmt, wenn man nicht weis, ob das wieder passiert!
Letzten Endes ist die db nur Beiwerk, die das NAS als Goodi erledigen soll.

Hallo

wenn das Datenbankfile kleiner geworden ist und der Plattenplatz nicht mehr wird, dann muss das aber nicht zwangsläufig ein Historian Problem sein.
Ist das ein "gemeinsamer Ordner" in dem das ganze liegt? Ist dort ggf. die Funktion "Papierkorb" aktiv? Wenn ja, Papierkorb leeren.

Hast Du mal direkt den Entwickler angeschrieben?

BTW ich finde es sehr eigenartig, dass nach dem Löschen von Daten in Historian, "über Nacht" die DB von selbst kleiner geworden ist, obwohl Du keinen entsprechenden Befehl benutzt hast. Mir war bisher nicht bekannt, dass Historian eine automatische DB Wartung macht. Dazu müssten ja auch alle Zugriffe auf die DB gesperrt werden und es würde für diese Zeit nichts aufgezeichnet.

Nein, es ist kein "normales" Verzeichnis. Die Daten liegen unter @appstore/ccu-historian/data
Zugriff nur über SCP. Da gibt es keinen Papierkorb.
Den Entwickler habe ich nicht angeschrieben, ich hatte "nebenan" im Thread auf eine Reaktion gehofft.
Inzwischen ist wächst die Datenbank wieder und benutzt dafür den verbleibenden Speicher, der fehlende bleibt weg.
Ich habe den Dienst erst mal gestoppt, der ist offensichtlich fehlerhaft.
Ich muss sehen, ob es ein Image für den rpi gibt, vielleicht gibts morgen beim black friday einen rpi 4 billiger, dort kann das erst mal keinen Schaden anrichten wenn sowas wieder passiert.
Ich muss jetzt erst mal sehen, das ich mein NAS wieder mit voller Kapazität zum laufen bekomme!

NickHM hat geschrieben: ↑

18.11.2020, 12:15

Auf der Kommandozeile der DS warst Du schon mal ?

Ohne Konsole wüsste ich gar nicht wo der Fehler liegt.
Ich hatte geschrieben, das die mit "du" angezeigte Dateigröße von 2,1 TB auf 500MB geschrumpft ist, gleiche Anzeige mit WinSCP.
laut "df" ist der speicher jedoch nicht freigegeben.
Das war das, was man nicht verstehen muss!


ps: was ich auch nicht verstehe ist die versteckte Installation auf der DS !

java -jar ccu-historian.jar -recalc
2020-11-19 15:01:31|INFO |CCU-Historian V2.2.0
2020-11-19 15:01:31|INFO |(C)MDZ (info@ccu-historian.de)
2020-11-19 15:01:32|SEVERE |Exception: ./ccu-historian-0.log.lck
2020-11-19 15:01:32|SEVERE |Detail: java.nio.file.AccessDeniedException: ./ccu-historian-0.log.lck
at mdz.ccuhistorian.LogSystem.restart(LogSystem.groovy:109)
at mdz.ccuhistorian.Main.start(Main.groovy:88)
at mdz.ccuhistorian.Main$_run_closure4.doCall(Main.groovy:77)
at mdz.ccuhistorian.Main$_run_closure4.doCall(Main.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.ccuhistorian.Main.run(Main.groovy:77)
at mdz.ccuhistorian.Main.main(Main.groovy:45)
2020-11-19 15:02:02|SEVERE |Exception: ./ccu-historian-0.log.lck
2020-11-19 15:02:02|SEVERE |Detail: java.nio.file.AccessDeniedException: ./ccu-historian-0.log.lck
at mdz.ccuhistorian.LogSystem.restart(LogSystem.groovy:109)
at mdz.ccuhistorian.Main.start(Main.groovy:88)
at mdz.ccuhistorian.Main$_run_closure4.doCall(Main.groovy:77)
at mdz.ccuhistorian.Main$_run_closure4.doCall(Main.groovy)
at mdz.Exceptions.lambda$0(Exceptions.java:84)
at mdz.Exceptions.catchToLog(Exceptions.java:74)
at mdz.Exceptions.catchToLog(Exceptions.java:84)
at mdz.ccuhistorian.Main.run(Main.groovy:77)
at mdz.ccuhistorian.Main.main(Main.groovy:45)
2020-11-19 15:02:33|SEVERE |Exception: ./ccu-historian-0.log.lck


die Ausgabe auf recalc
ich hab erst mal abgebrochen.

Hast du den historian während des recalc gestoppt?
Die Fehlermeldung sieht so aus als könnte er ccu-historian-0.log.lck (ein Lock für die Log-Datei?) nicht lesen/schreiben.

Alternativ könntest du ignorieren dass das Log nicht benutzt werden kann und ihn erstmal laufen lassen.