UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Dr. Bakterius]

@apollon77 Ja, und doch frage ich mich warum das plötzlich so ist. Gäbe es eine Möglichkeit darzustellen wie oft und bei wie vielen Datenpunkten welcher Adapter aktualisiert (in Admin oder Info)?

[Marty56]

Bei mir läuft in 2-3 Wochen der Swap Speicher voll. Ganz langsam.

Promox PVE Webui öffnet sich dann immer langsamer und am Schluss muss ich die iobroker LVC neu starten.

Es hängt bei mir am History Adapter. Ähnliches Verhalten habe ich auch aber noch schneller beim SQL Adapter beobachtet.

Ich benutze json.l

[apollon77]

@dr-bakterius Also im Admin kann man an sich pro Adapter sehen wieviele Änderungen (States/Objects zusammen) gemacht werden ... müsste man im Expertenmodus in der Instanzansicht sehen

[apollon77]

@marty56 Ok laaaaangsam!!

Swap "läuft" nicht zu ... Swap wird genutzt wenn es nötig ist. Wenn das System Swap nutzt dann heisst das erstmal das es zeitpunkte gab wo der verfügbare RAM nicht gereicht hat und mehr gebraucht wurde und damit wurden Daten aus dem RAM ins Swap ausgelagert. AN sich nichts schlimmes, aber wenn es so ist wie Du beschreibst dann würde ich der VM/LXC mal mehr RAM geben und das Problem ist gelöst.

An sich mit "free -m" prüfen wie es der RAM Nutzung geht und ggf mit "top" schauen welcher Adapter es ist.
Bei History und SQL kann das daran liegen wenn oft Charts genutzt werden, dann muss der halt immer Daten im RAM haben (und je länger die Zeiträume sind desdo mehr).

Das gehört hier aber nicht hin

[Dr. Bakterius]

@apollon77 Meinst du die Ereignisse?

Die wirken sich merklich auf den Netzwerk-Traffic aus nicht auf den Disk-IO. Zumindest als ich die beiden Instanzen mit den meisten Ereignissen (hue und javascript) deaktiviert hatte, ging der Netzwerk-Traffic auf etwa die Hälfte zurück, doch die states.jsonl ist fast genauso schnell angewachsen wie zuvor.

Mittlerweile habe ich mehrfach alle Instanzen einzeln gestoppt und beobachtet - es ist an keinem Adapter festzumachen!

[apollon77]

@dr-bakterius interessant ist der zweite wert. Das sind „state changes“. der erste ist nur das was der Adapter von anderen subscribed hat. Und ja Admin bekommt halt am Ende viele Daten aber schreibt selbst wenig.

Du musst die suchen die alle zweite Zahl viel haben.

[JLeg]

@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:

'htop' zeigt:

bei htop kannst du übrigens mit "F2" das Setup aufrufen, und dort "disk reads" und "disk writes" (und einige andere i/o-counter) aktivieren, sodass diese im htop-Fenster mit angezeigt werden. Dann kann man z.B. auch danach sortieren...
("Spitzenreiter" bei mir sind übrigens Grafana und backitup)

[apollon77]

@jleg das ist für States.jsonl aber egal weil das nur der Controller Prozess schreibt …

[JLeg]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@jleg das ist für States.jsonl aber egal weil das nur der Controller Prozess schreibt …

..der dann aber in der htop-"Hitliste" oben entsprechend auftauchen müsste, oder nicht?

[Dr. Bakterius]

@jleg Richtig! Und das habe ich hier auch schon vor zwei Tagen so geschrieben. :wink:

[Dr. Bakterius]

@apollon77 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Du musst die suchen die alle zweite Zahl viel haben.

Danke für die Erklärung! :+1:

So sehen alle meine Instanzen aus:

So 900-1000 Ausgabeereignisse gesamt. Über welchen Zeitraum gesehen eigentlich? Ist das außergewöhnlich viel? Wenn ich die drei Instanzen mit den höchsten Werten beende, reduzieren sich die Ausgabeereignisse um knapp 50%. Und auch das Neuschreiben der states.jsonl erfolgt dann nur noch etwa halb so oft. Das ist soweit nachvollziehbar.

Was ich nicht nachvollziehen kann, dass das Volumen dann immer noch etwa 50x so hoch ist wie noch im Juli! Wurde da sicher nichts bei der Behandlung von jsonl geändert? Wird jetzt häufiger komprimiert?

[apollon77]

@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Über welchen Zeitraum gesehen eigentlich?

15s ist das Messinterval und auch aktualisierungsinterval. AN sich wird nicht häufiger komprimiert wenn ich recht entsinne @AlCalzone ... oder fällt Dir was ein?

[AlCalzone]

@apollon77 @Dr-Bakterius Geändert hat sich da nix.
Die jsonl-DB ist so voreingestellt, dass bei jeder Verdopplung der Datei (bei mind. 1000 Zeilen) komprimiert wird, d.h. alles neu geschrieben. In der Regel sollte das mit der Zeit immer seltener passieren.
Wenn deine Ereignisse viele Duplikate enthalten könnte ich mir vorstellen, dass recht häufig komprimiert wird, ohne dass sich an der Netto-Größe der Datei viel ändert und du ständig in diese Bedingung reinläufst.

[Dr. Bakterius]

@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:

In der Regel sollte das mit der Zeit immer seltener passieren.

Wie das? Die Adapter schreiben Werte in die Datenpunkte bzw. aktualisieren diese. Dabei wird der Wert (plus Zeitstempel?) in die states.jsonl geschrieben, oder? Das wird doch nicht weniger mit der Zeit.

Gut, ich habe ein oder zwei Steckdosen in den sonoff-Adapter hinzugefügt, sonst aber nur Updates der Adapter gemacht. Also wieso dann plötzlich die schnelle Verdoppelung der Dateigröße? Wenn die Diskwrites faktisch alleine von dieser Datei abhängen, dann hat sich das von etwa 5 Stunden auf 3 Minuten reduziert! Fällt dir etwas auf bei der Anzahl der Ausgabeereignisse (in meinem Bild oben)?

Das einzige was ich mir noch vorstellen könnte: Proxmox hat das bisher völlig falsch angezeigt (gab auch da Updates zu diesem Zeitpunkt). Kann ich mir aber eigentlich nicht vorstellen...

[AlCalzone]

@dr-bakterius Die Datei ist erstmal append-only bis zum erneuten Schreiben nach Erreichen einer Schwelle. Jede Änderung eines States entspricht einer neuen Zeile, die angefügt wird. Wenn durch dieses Anfügen die Datei auf die doppelte Länge des letzten Kompressionsvorgangs angewachsen ist, wird ein neuer ausgelöst. Je mehr States du hast, desto länger dauert es, bis sich die Größe verdoppelt hat, weil die Baseline auch höher ist.

Wie viele States hast du denn insgesamt?

Und bist du ganz sicher, dass es an states.jsonl liegt und nicht objects.jsonl? Nicht dass einer der Adapter seit dem Update ständig seine Objekte neu schreibt. Da ist die Schwelle deutlich geringer und die Datenmenge wesentlich höher.

[Dr. Bakterius]

@alcalzone Ich habe jetzt mal zum Testen wieder auf file|file umgestellt. Da wurden 11.836 states und 10.960 objects konvertiert. Danach den Container neu gestartet und 10 Minuten beobachtet. In diesen 10 Minuten wurden deutlich weniger Schreibzugriffe lt. Proxmox durchgeführt.

Dann wieder zurück auf jsonl|jsonl und ich bin wieder da wo ich vorher war.

In den letzten 15 Minuten wurde die states.jsonl 5x neu geschrieben weil sich die Größe verdoppelt hatte. Die objects.jsonl ist anfangs um 15% angewachsen und bleibt seit 10 Minuten stabil auf ihrer Größe. Ich glaube also nicht, dass ein Adapter ständig seine Objekte neu schreibt.

Anfang des Jahres waren die Schreibzugriffe exorbitant höher als ich noch auf file|file war. Bei redis gingen diese deutlich zurück und dann mit jsonl sanken sie faktisch auf null. Und seit ende Juli sind sie plötzlich so hoch - höher als bei file! Ich verstehe es nicht...

[Kueppert]

Hmmm, ich meine mich zu erinnern, dass ich damals bei der Umstellung auf JSONL irgendwas in einer Datei angepasst hab dafür...aber das wars auch schon, woran ich mich meine zu erinnern...man konnte doch das Verhalten bei JSONL selber etwas manipulieren/seinen Bedürfnissen anpassen? Ggf wurde da was überschrieben?

[apollon77]

@dr-bakterius Naja Du hast zwei Adapter die recht viel ausgehende States hatten ... ggf hat sich ja da was geändert ... bzw @AlCalzone hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt? ;-)

[AlCalzone]

@dr-bakterius sagte in ioBroker sehr hohe Diskwrites in Proxmox:

11.836 states

Lass mal rechnen.
1000 Ausgabeereignisse alle 15 Sekunden, macht etwa 12.000 Schreibvorgänge in 3 Minuten.
Das deckt sich ziemlich genau mit deiner Beobachtung, dass alle 3 Minuten komprimiert wird, weil sich dann die DB-Größe verdoppelt hat.

@apollon77

hatten wir nicht den Bug das ggf gar nicht compressed wurde und deswegen das eine setting im code hinzugefügt?

Möglich. Ich weiß nicht genau, welche Version @Dr-Bakterius vorher im Einsatz hatte.

Anyways - hier kann man sicher noch Feintuning betreiben, genau dafür machen wir solche Tests ja. An sich ist die Auto-Kompression dafür gedacht, dass die Dateien größentechnisch nicht komplett aus dem Ruder laufen und das Laden etwas schneller geht.

Für Objects haben wir Größenfaktor 2, mind. 1000 Zeilen als Bedingung für Neu-Schreiben. Die 1000 sind hier die Anzahl der teils redundanten Zeilen in der DB, nicht die einzigartigen Objekte.
Für States ist die Einstellung aktuell identisch. Ich hab nur etwa halb so viele States und meine states.jsonl dümpelt irgendwo zwischen 2-3 MB herum. Also Größentechnisch nix wildes.

Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)

Das wird dafür sorgen, dass die DBs deutlich seltener komprimiert werden - bei kleineren Installationen so gut wie nie. Ist jetzt vermutlich nicht schlimm, aber ggf. muss man es dann zeitgesteuert ab und an machen.

[apollon77]

@alcalzone sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Vorschlag: wir heben die Schwellen deutlich an.
Objects: Faktor 2, bei mind. 25k Zeilen
States: Faktor 2, bei mind. 50k Zeilen (oder gar Faktor 10?)

Macht sinn und ja States Faktor 10

@Dr-Bakterius machst du uns bitte im js-controller ein issue dazu?