NEWS
ioBroker: 25GB pro Tag wg states.json + states.json.bak
-
Kann auch sein, dass es daran liegt, dass die Wetter-Adapter alle in der Schedule-Gruppe sind. Das heißt die Adapter laufen nur kurz und beenden sich dann wieder, statt einfach zu schlafen.
Getestet habe ich das "zu Fuß" anhand des Zeitstempels der Objects.json. Hat sich der geändert, habe ich ins Log geschaut, was zu der Zeit passiert ist.
github-Nutzer bin ich. Allerdings noch relativ "frisch". Ich sehe mir gerade den SourceCode vom Adapter "DasWetter" an. Besser wäre, wenn man die Aktualisierungsrate im Admin einstellen könnte und die Adapter durchlaufen.
@peterfido sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
Getestet habe ich das "zu Fuß" anhand des Zeitstempels der Objects.json. Hat sich der geändert, habe ich ins Log geschaut, was zu der Zeit passiert ist.
Vielen Dank, mühselig, aber man kommt dennoch voran.
-
Kann auch sein, dass es daran liegt, dass die Wetter-Adapter alle in der Schedule-Gruppe sind. Das heißt die Adapter laufen nur kurz und beenden sich dann wieder, statt einfach zu schlafen.
Getestet habe ich das "zu Fuß" anhand des Zeitstempels der Objects.json. Hat sich der geändert, habe ich ins Log geschaut, was zu der Zeit passiert ist.
github-Nutzer bin ich. Allerdings noch relativ "frisch". Ich sehe mir gerade den SourceCode vom Adapter "DasWetter" an. Besser wäre, wenn man die Aktualisierungsrate im Admin einstellen könnte und die Adapter durchlaufen.
@peterfido das sieht man doch
alles was vorne keine Ampel hat ist per crontab einstellbar..
ok ausser die Zusatzklamotten für die VIS
-
@paul53 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
@klassisch sagte:
wäre ein einen issue auf github wert.
Ich bin verwirrt. Denn ich Interpretiere das
Apollon77 moved this from Backlog to Done in Next Version (3.0.x/3.1) Elena/Francescaso, daß ab JS-Controller 3.0 das feature schon drin sein sollte.
Mein Rechner sagt mir
Typ: js-controller Verfügbar: 3.1.6 Titel: JS controller Installiert: 3.1.6 OS: win32Dann müßte das Feature doch schon eingebaut sein?
@klassisch sagte:
Dann müßte das Feature doch schon eingebaut sein?
Müsste, aber
@paul53 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
Ich hatte es erst mit der Config-Datei conf/iobroker-dist.json versucht, was allerdings nicht funktioniert hat.
-
@peterfido das sieht man doch
alles was vorne keine Ampel hat ist per crontab einstellbar..
ok ausser die Zusatzklamotten für die VIS
@arteck
Ich hab´s ja gesehen :wink: Nur, warum werden dann bei jedem Start die Objekte neu geschrieben? Als der Javascript-Adapter die Objekte alle unter 0_userdatat.0 bei jedem Skript-Start neu initialisiert und die Werte dadurch gelöscht hatte, habe ich mir eine CreateObject selbst erstellt, welche vorher prüft, ob das Objekt schon existiert.Sowas sollte hier dann auch rein. Oder @apollon77 (ist er dafür zuständig?) berücksichtigt das in zukünftigen Versionen.
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
@klassisch sagte:
Dann müßte das Feature doch schon eingebaut sein?
Müsste, aber
@paul53 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
Ich hatte es erst mit der Config-Datei conf/iobroker-dist.json versucht, was allerdings nicht funktioniert hat.
@paul53 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
@paul53 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
Ich hatte es erst mit der Config-Datei conf/iobroker-dist.json versucht, was allerdings nicht funktioniert hat.
Danke. Ah, drin aber defekt. Wäre dann auch einen neuen github issue wert: Einstelloption funktioniert nicht.
-
@arteck
Ich hab´s ja gesehen :wink: Nur, warum werden dann bei jedem Start die Objekte neu geschrieben? Als der Javascript-Adapter die Objekte alle unter 0_userdatat.0 bei jedem Skript-Start neu initialisiert und die Werte dadurch gelöscht hatte, habe ich mir eine CreateObject selbst erstellt, welche vorher prüft, ob das Objekt schon existiert.Sowas sollte hier dann auch rein. Oder @apollon77 (ist er dafür zuständig?) berücksichtigt das in zukünftigen Versionen.
@peterfido Woher soll denn der JS Adapter wissen ob das Javascript das Objekt geändert hat? Von daher kann er es nur so neu schreiben das es passt.
Ich verstehe noch nicht ganz wo das Problem liegt? Die meisten Adapter nutzen bereits "setObjectNotExists" und ja das objects.json ist vllt am größten wird aber eher selten wirklich geändert. Die states.json die den aktuellen State-Status enthält wird da viel öfter geschrieben.
Am Ende kann die Schreibfrequenz angepasst werden, unter dem Risiko das bei einem Crash die Werte veraltet sind.
Redis hilft da auch nicht, da auch her geschrieben wird - anders konfiguriert.
Das Problem besteht etwas mehr für SD-Karten User.
Ingo
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@peterfido Woher soll denn der JS Adapter wissen ob das Javascript das Objekt geändert hat? Von daher kann er es nur so neu schreiben das es passt.
Ich verstehe noch nicht ganz wo das Problem liegt? Die meisten Adapter nutzen bereits "setObjectNotExists" und ja das objects.json ist vllt am größten wird aber eher selten wirklich geändert. Die states.json die den aktuellen State-Status enthält wird da viel öfter geschrieben.
Am Ende kann die Schreibfrequenz angepasst werden, unter dem Risiko das bei einem Crash die Werte veraltet sind.
Redis hilft da auch nicht, da auch her geschrieben wird - anders konfiguriert.
Das Problem besteht etwas mehr für SD-Karten User.
Ingo
@apollon77 sagte in ioBroker: 25GB pro Tag wg states.json + states.json.bak:
Redis hilft da auch nicht, da auch her geschrieben wird - anders konfiguriert.
na ja redis kann dir hier helfer wenn du es auf eine andere Maschien auslagerst
-
@peterfido Woher soll denn der JS Adapter wissen ob das Javascript das Objekt geändert hat? Von daher kann er es nur so neu schreiben das es passt.
Ich verstehe noch nicht ganz wo das Problem liegt? Die meisten Adapter nutzen bereits "setObjectNotExists" und ja das objects.json ist vllt am größten wird aber eher selten wirklich geändert. Die states.json die den aktuellen State-Status enthält wird da viel öfter geschrieben.
Am Ende kann die Schreibfrequenz angepasst werden, unter dem Risiko das bei einem Crash die Werte veraltet sind.
Redis hilft da auch nicht, da auch her geschrieben wird - anders konfiguriert.
Das Problem besteht etwas mehr für SD-Karten User.
Ingo
@apollon77
Moin,vielleicht vor dem Schreiben prüfen, ob da überhaupt was anderes steht. Aktuell sieht es so aus, dass die Objekte die bereits vorhandenen Namen bekommen und dann die Datei geschrieben wird. Meine objects.json ist mit ihren 10 MB etwa fünf Mal größer als die Staates.json. Die TBW der SSD werden so schneller aufgebraucht. Okay, die Samsung 860 EVO 500 hält bissel was aus, trotzdem würde ich gern unnötige Schreibvorgänge reduzieren.
Einen Wetteradapter hatte ich im 5 Minutentakt, die anderen beiden im 15 Minutentakt. Also wurde 20 Mal die Stunde die objects.json geschrieben. Jetzt habe ich zwei deaktiviert und nehme alle 30 Minuten nur noch DasWetter. Die anderen waren für spezielle Dinge wie die Warnungen und paar tiefere Details.
Redis hatte ich kurz aktiviert, da ging mir der RAM-Verbrauch zu hoch. Vielleicht aktiviere ich das später wieder, wenn mehr RAM vorhanden ist.
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
@apollon77
Moin,vielleicht vor dem Schreiben prüfen, ob da überhaupt was anderes steht. Aktuell sieht es so aus, dass die Objekte die bereits vorhandenen Namen bekommen und dann die Datei geschrieben wird. Meine objects.json ist mit ihren 10 MB etwa fünf Mal größer als die Staates.json. Die TBW der SSD werden so schneller aufgebraucht. Okay, die Samsung 860 EVO 500 hält bissel was aus, trotzdem würde ich gern unnötige Schreibvorgänge reduzieren.
Einen Wetteradapter hatte ich im 5 Minutentakt, die anderen beiden im 15 Minutentakt. Also wurde 20 Mal die Stunde die objects.json geschrieben. Jetzt habe ich zwei deaktiviert und nehme alle 30 Minuten nur noch DasWetter. Die anderen waren für spezielle Dinge wie die Warnungen und paar tiefere Details.
Redis hatte ich kurz aktiviert, da ging mir der RAM-Verbrauch zu hoch. Vielleicht aktiviere ich das später wieder, wenn mehr RAM vorhanden ist.
@peterfido Für die Idee beim schreiben eines Objekts zu schauen was vorher drin stand und nur wenn gleich eine Änderung zu vermerken ist vllt nicht mal so schlecht ... mach mal ein js.controller isssue bitte auf
-
@peterfido Für die Idee beim schreiben eines Objekts zu schauen was vorher drin stand und nur wenn gleich eine Änderung zu vermerken ist vllt nicht mal so schlecht ... mach mal ein js.controller isssue bitte auf
erledigt
-
Post war uninformiert und irreführend. Habe ihn deshalb entfernt. Siehe Richtigstellung von @apollon77 im nächsten Post zum Vorgehen bei js-controller 3.2
Edit: ab js-controller 3.2: siehe https://forum.iobroker.net/topic/41128/iobroker-sehr-hohe-diskwrites-in-proxmox/122
(geht auch unter Windows) -
Post war uninformiert und irreführend. Habe ihn deshalb entfernt. Siehe Richtigstellung von @apollon77 im nächsten Post zum Vorgehen bei js-controller 3.2
Edit: ab js-controller 3.2: siehe https://forum.iobroker.net/topic/41128/iobroker-sehr-hohe-diskwrites-in-proxmox/122
(geht auch unter Windows)@klassisch NEIN!!!!! Bitte nicht den Code anpassen, das ist jetzt konfigurierbar in der iobroker-data/iobroker.json bei den DB einstellungen namens "writeFileInterval" - siehe https://forum.iobroker.net/topic/41029/js-controller-3-2-jetzt-im-latest/114?_=1611124614146
840
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge