[gelöst] History Adapter Speicherpfad keine Einträge
-
Ich wiederhole gern nochmal meine Frage von oben: Wie schnell kommen denn die Werte?
Die Entprellzeit muss KLEINER sein als die Liefergeschwindigkeit sonst gelten alle Werte als Instabil.
Also setzte die Entprellzeit mal auf 1 oder so und schau ob dann Werte ankommen.
-
Hallo apollon77,
ich hatte deinen Beitrag vorhin übersehen - sorry - was soll ich sagen ! HEUREKA ! dein Tip war Gold wert!
Jetzt habe ich Daten im RAM (was ist hier ein guter Wert?) und Entprellzeit auf 100 gestellt und er schreibt wieder alle Adapter.
Danke nochmal!!
-
und Entprellzeit auf 100 gestellt und er schreibt wieder alle Adapter. `
sollte das der Grund sein, müssen die Werte schneller als 1 Sekunde kommen. Bisher hattest du 1000 msec.Gruß
Rainer
-
sollte das der Grund sein, müssen die Werte schneller als 1 Sekunde kommen. Bisher hattest du 1000 msec. `
Das kann möglich sein, gerade die TX Sensoren über den Jeelink "spammen" ganz schön. Die sind sehr gesprächig. Daten aus Homematic sind sicher nicht so oft aktualisiert.
-
Guten morgen @ all,
jetzt habe ich mein Problem aus dem März wieder (History Adapter startet immer wieder neu). Der Adapter lief über Nacht keine 5 Minuten durch. Er startet dann immer neu und die Daten sind nur abgehackt. An welchen Schrauben könnte ich drehen? Andere lassen io Broker ja auf einem Pi mit SD laufen und hier geht das nicht :_(
-
Was sagt denn das log? Was sagt Debug Modus in den Logs? Mehr Infos wären schon hilfreich.
-
Guten Morgen apollon77,
du hast schon recht, es fehlen Daten und mehr Infos. Ich habe zuerst bei mir selbst gesucht. Und bin bei Peaks auf sehr hohe Latenzen in meiner VM gestoßen. Andererseits dauert das nur max 10 Sekunden an. Danach habe ich wieder sehr niedrige Latenzen.
Ich werde die VM erst einmal auf SSD verschieben und sehen wie es da läuft. Aktuell ist es ein NFS Share.
1443_2017-07-26_07_31_03-smarthub__192.168.200.27__-_remote_desktop_connection_manager_v2.7.png
1443_2017-07-26_07_27_28-smarthub__192.168.200.27__-_remote_desktop_connection_manager_v2.7.png -
Hallo apollon77,
es scheint nicht an der SSD zu liegen. Ich habe zwar nun durchweg Schreib Latenzen unter 50ms aber der Adapter startet trotzdem ständig neu. Aktuell bleibt er laut Log genau da hängen wo die Daten vom RAM (200) in die JSON Dateien geflusht werden sollen. Er ist dann auch auf Rot und unter Objekten wird bei alive "NULL" angezeigt.
EDIT: Es bleibt auch bei 10 Einträgen stehen. wo die Menge geringer aber die Dateien häufiger geschrieben werden müssen.
1443_2017-07-26_13_32_00-smarthub__192.168.200.27__-_remote_desktop_connection_manager_v2.7.png
1443_2017-07-26_13_35_01-iobroker.admin.png -
Und was kommt danach im Log?
Dann bitte mal den Adapter im Admin stoppen.
An die Kommandozeile und
node node_modules/iobroker.history/history.js –force --logs
und dann die Ausgabe mal schicken bitte.
Der Adapter wird somit an der Kommandozeile gestartet und es gibt teilweise nochmal mehr Ausgaben beim crash
-
Der Adapter hängt sich ca. 5min auf, danach geht es im Log normal weiter. Ich habe jetzt deine "Crash" Log Version mal angeschoben, weiss aber nicht wo das Log erstellt wird.
Oder bleibt das nur im Command Fenster?
-
Auf jeden Fall im command Fenster und das ist das interessante.
-
Hallo und guten Morgen,
der Adapter hat sich gestern zweimal "normal" beendet. Beim ersten mal dachte ich, ich habe aus versehen noch mal Stg+C gedrückt. Beim zweiten mal war es definitiv als ich schon im Bett war.
Heute morgen zeigte die Konsole einfach nur ein gewohntes Ende an. Keine Fehler. Die JSON Dateien wurden aber nur bis 21:29 Uhr geschrieben. Kann es sein je größer diese werden umso größer wird auch die Schreibzeit weil immer ALLES neu rein geschrieben wird statt nur angehängt?
1443_2017-07-27_06_52_42-smarthub__192.168.200.27__-_remote_desktop_connection_manager_v2.7.png -
Sehr interessant … Hätte wenigstens irgendwas erwartet.
Kannst Du irgendwie den "Speicherverbrauch" checken wenn das passiert? NIcht das er gegen irgendwelche Prozess-Limits in deiner VM oder so läuft?
Aber so oder so: bei deinen Datennmengen würde ich eh von History abraten und ne InfluxDB oder SQL-DB nehmen.
-
Habe leider aktuell nur einen VMware Sensor (Monitoring also von außen).
Bis auf das die CPU hochgeht - wahrscheinlich wegen den viele Schreiboperationen, ist nichts auffälliges zu sehen.
Die VM hat 2 vCPUs mit jeweils 2,40Ghz, 2GB RAM, 50GB HDD (50% voll), jetzt auf SSD (vorher NFS), Server 2016, 64Bit.
Wenn ich auf Influx umsteige geht das dann trotzdem mit visualisieren in Float oder Rickshaw?
Den Influx Adapter habe ich schon einmal installiert. Das DB Backend fehlt noch.
1443_2017-07-27_10_11_37-smarthub___bericht___prtg_network_monitor__prtg_.png -
Habe leider aktuell nur einen VMware Sensor (Monitoring also von außen).
Bis auf das die CPU hochgeht - wahrscheinlich wegen den viele Schreiboperationen, ist nichts auffälliges zu sehen.
Die VM hat 2 vCPUs mit jeweils 2,40Ghz, 2GB RAM, 50GB HDD (50% voll), jetzt auf SSD (vorher NFS), Server 2016, 64Bit. `
Dann bin ich mit meinem Latein am Ende warum das bei Dir ohne Fehlermeldung abkachelt … komisch komisch.Einzige Idee wäre nochmal der Start per Kommandozeile aber mit "history.0 debug" als erste Parameter (die anderen nach hinten schieben)
Wenn ich auf Influx umsteige geht das dann trotzdem mit visualisieren in Float oder Rickshaw?
Den Influx Adapter habe ich schon einmal installiert. Das DB Backend fehlt noch. `
Ja das tut. History, SQL und InfluxDB haben eine kompatible/gleiche Schnittstelle zur Datenabfrage und die verwenden die Flot/Rickshaw-Adapter, damit sollte das tun. Einzig den Aggragator-Typ "minmax" hast Du ggf. nicht immer da. Bei InfluxDB hab ich den nachgebaut, SQL glaube nicht. Aber "average" geht da auch
