Monatsrückblick Januar/Februar 2026 ist online!

[photographix]

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

[apollon77]

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

[photographix]

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?

[apollon77]

Auf jeden Fall im command Fenster und das ist das interessante.

[photographix]

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

[apollon77]

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.

[photographix]

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

[apollon77]

@photographix:

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)

@photographix:

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