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

[saeft_2003]

@homoran

Alles klar dann warten wir mal würde mich sehr interessieren...

[Meister Mopper]

Okay, ich habe meinen Übeltäter gefunden:

Es ist die InfluxDB, die von Proxmox direkt als Metric Server befüllt wird. Hat jemand eine Idee, wie man die Schreibvorgänge etwas verlangsamen kann?

[Master67]

@meister-mopper ist bei mir auch als "Metric Server" Eingerichte, sieht bei mir so aus

Kommt wohl auch darauf an was man mit der InfluxDB so macht, bei mir ist das recht überschaubar.

[Master67]

@unclesam sagte in ioBroker sehr hohe Diskwrites in Proxmox:

@robbsen sagte in ioBroker sehr hohe Diskwrites in Proxmox:

kleiner Nachtrag da ich den beitrag nicht löschen konnte. bin nicht sicher ob ich die Zahlen richtig interpretiere.. hier noch mal die Zahlen Woche/Durchschnitt
.... die Umstellung scheint nen positiven Effekt zu haben.

Der Rückgang ist ja noch massiver als ich das erwartet hätte! ioBroker läuft schon noch, oder? ;-)

Ist bei mir ähnlich, siehe Bild (1,33MB) man kann auch schön sehen wie der Spitzenwert fällt wenn die Alarmanlage um 22:30 Uhr in den Nachtmodus geht (keine Überprüfung der Anwesenheit mehr).

[Homoran]

@master67 Sorry, aber ist der "Absturz" nicht genau um Mitternacht?
Ich kann die X-Achsenbezeichnungen nicht genau zuordnen

[Meister Mopper]

@master67 Nee, sehe gerade es war die falsche Deutung. Es ist ioBroker, der die hohe Schreiblast verursacht. Ich weiß nicht, wo es da klemmt.

[Homoran]

@meister-mopper sagte in ioBroker sehr hohe Diskwrites in Proxmox:

Nee, sehe gerade es war die falsche Deutung. Es ist ioBroker, der die hohe Schreiblast verursacht. Ich weiß nicht, wo es da klemmt.

das passt besser, denn influx hatte eine Max von 151, die Kurve lag aber zwischen 30000 und 60000 kB/s

[Master67]

@homoran.... Adlerauge ;-)
Hab es nochmal Geprüft Beginnt um 23:30 Uhr und unten angekommen ist es genau um 0:00 Uhr, aber in wie weit das auch Zeitlich korrekt aufgezeichnet wird weiß ich nicht.
Ich kann nur sagen das die Anwesenheitsprüfung um 22:30 Uhr deaktiviert wird!

[Homoran]

@master67 Dann dürfte, genau wie bei @robbsen redis nicht wirklich den Rückgang bewirken

[Master67]

@homoran... nicht den Rückgang aber das gleichmäßige Schreiben, der fall von 2,94MB auf 1,33MB, könnte sich aber mit der Deaktivierten Anwesenheitserkennung erklären lassen.. oder nicht? ;-)

[Homoran]

@master67 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

der fall von 2,94MB auf 1,33MB, könnte sich aber mit der Deaktivierten Anwesenheitserkennung erklären lassen.. oder nicht?

oder!
Warum erst nach 60-90 Minuten?

@master67 sagte in ioBroker sehr hohe Diskwrites in Proxmox:

aber das gleichmäßige Schreiben

du meinst die etwas weniger vorkommenden Spitz(ch)en?
Das eigentlich eher nicht, da Redis ja IMHO genau das Gegenteil macht. Erst sammeln, dann gemeinsam schreiben, um die Schreibzugriffe zu minimieren

[paul53]

@meister-mopper sagte:

Es ist ioBroker, der die hohe Schreiblast verursacht.

Wie groß sind die Log-Dateien unter /opt/iobroker/log?
Wird Redis für die states verwendet?

[Meister Mopper]

@paul53 Ja, redis nur für die states.

[paul53]

@meister-mopper
Die Log-Dateien sind auch nicht zu groß.
Wie sieht es mit History aus ?

[Master67]

@homoran sagte in ioBroker sehr hohe Diskwrites in Proxmox:

oder!
Warum erst nach 60-90 Minuten?

Trägheit der Aufzeichnung die geht sowieso nur 4 Stunden Takt... aber was weiß ich schon davon, das ist nur stochern im Trüben Wasser.

Und wenn Redis erst sammelt und dann schreibt kommt doch die gleichmäßige Schreibkurve zusammen oder verstehe ich das falsch? :-)

[Dr. Bakterius]

Wenn ich in die Grafik der letzten Stunde schaue, gibt es regelmäßige Spitzen. Diese stammen von zwei Adaptern. Nämlich netatmo (gelb) und daswetter (grün).

Bei Netatmo habe ich das Abfrageintervall von 5 auf 10 Minuten erhöht. Das hat eine Reduktion von knapp 20% gebracht. Die Frage ist ob man diese Schreibwerte senken kann (ohne die Intervalle weiter zu erhöhen), bzw. ob Redis hier etwas signifikant verbessern würde?

[crunchip]

Jetzt hab ich mir meins auch mal angesehen, seltsamerweise auch die Änderung ab dem 15.01. Jedoch eher negativ.
Was war die große Veränderung ab diesem Tag? Updates der Adapter und Js-Controller 3.2.x und folgende.
Das ist ein Screen von einer Woche, wenn ich da meine Werte anschau, fall ich ja total aus dem Rahmen, bin bei knapp über 9G Spitze,
vor dem Anstieg lag ich im Schnitt bei knapp 3M

diese von der letzten Stunde, auch da sieht man die spitzen im Detail

das deckt sich auch mit solchen Meldungen

influxdb.0	2021-01-20 18:15:33.302	warn	/ "{\"error\":\"timeout\"}\n"
influxdb.0	2021-01-20 18:15:33.302	warn	(925) Error on writePoint("{"value":22,"time":"2021-01-20T17:05:00.988Z","from":"system.adapter.sonoff.0","q":0,"ack":true}): Error: {"error":"timeout"}
influxdb.0	2021-01-20 18:15:21.085	warn	/ "{\"error\":\"timeout\"}\n"
influxdb.0	2021-01-20 18:15:21.085	warn	(925) Error on writePoint("{"value":4,"time":"2021-01-20T17:04:50.516Z","from":"system.adapter.sonoff.0","q":0,"ack":true}): Error: {"error":"timeout"}
broadlink2.0	2021-01-20 18:15:18.409	info	

[Meister Mopper]

@crunchip Ich bin gerade dabei, geduldig Adapter zu starten, wenn der Vorgänger ruhig wird. Bin mal gespannt welcher es ist ...

[Meister Mopper]

Weiss es noch nicht, aber hier die Reaktion, wenn der synology startet.

Wenn sich das bestätigt, mach ich ein issue auf.

[Meister Mopper]

Jetzt ist es klar. Bei mir ist es der Synology-Adapter. Hier wurde er gerade
ausgeschaltet: