ioBroker sehr hohe Diskwrites in Proxmox
-
@fredf sagte in ioBroker sehr hohe Diskwrites in Proxmox:
iobroker setup custom
hab auch mal gerade geschaut, hab auch jsonl bei beidem drin seit langem. Disk io sieht bei mir unauffällig aus:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
-
@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:
PS: wie komme ich aus dem setup custom wieder raus? ^^ will nichts ändern...
Einfach alles mit Enter bestätigen
Edit: Bzw. mit Strg + c abbrechen
-
@fredf war in der Proxmox Konsole, da geht kein STRG + C. Hab einfach alles bestätigt
-
@kueppert sagte in ioBroker sehr hohe Diskwrites in Proxmox:
Disk io sieht bei mir unauffällig aus
Also ich war vor dem Anstieg noch wesentlich weiter unten als du - jetzt habe ich mehr als das doppelte von dir.
Und wie gesagt, alle drei Minuten der Zugriff:
Wird jetzt sicher nicht gleich meine SSD schrotten, aber interessieren würde mich doch was das ist...
-
Dann wiederhole ich was ich oben geschrieben habe: da müsste ein Adapter „schuld“ sein. Finde raus welcher.
Alternativ schau was die jsonl files in iobroker-data machen. Sie müssten ja dann zu dem genannten Zeitpunkt neu komprimiert werden - ergo kleiner werden. Dann schau welches file es ist.
-
@apollon77 Ich habe jetzt über eine Stunde gesucht. Alle Instanzen beendet und dann der Reihe nach gestartet. Irgendwann sind die Schreibzugriffe angestiegen und häufiger geworden. Einen speziellen Adapter konnte ich dabei nicht ausmachen.
Die 'states.jsonl' steigt laufend in der Größe an, und wird wenn sie ungefähr die doppelte Größe erreicht hat neu geschrieben. Ich steh an...
-
@dr-bakterius Ok, also states.jsonl ... und passt das zu "alle 3 Minuten"? Dann hast DU einfach viele state updates ...
-
@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)?
-
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
-
@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
-
@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
-
@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!
-
@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.
-
@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) -
@jleg das ist für States.jsonl aber egal weil das nur der Controller Prozess schreibt …
-
@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?
-
@jleg Richtig! Und das habe ich hier auch schon vor zwei Tagen so geschrieben.
-
@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!
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?
-
@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?
-
@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.
