Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[rallef]

ok funktioniert jetzt super. Allerdings geht mein Synology NAS jetzt in die Knie. Mein iobroker belegt mehr als 44% RAM und es werden jede menge Warnings und errors in die influxdb geschrieben. schaukelt sich also hoch. da muss ich noch was optimieren

[rallef]

[crunchip]

@rallef sagte:

ede menge Warnings und errors in die influxdb geschrieben

die da wären?

@rallef sagte:

muss ich noch was optimieren

sollte eigentlich von haus aus so passen, mit den vorgegebenen Werten

[sigi234]

@crunchip sagte:

@sigi234 ist drin, siehe ersten Beitrag

DANKE!

[rallef]

habe jetzt 350 warnings /h in der influxdb.0 und ich sehe das die instanz neugestartet wird. Mein Host Ram ist auch zeitweise kritisch nur 13% und mein iobroker Ram belegt mehr als 54% zeitweise
hab eine synology Nas DS918+ mit 12 GB ram

[rallef]

werde die mal auf 16GB aufrüsten

[crunchip]

@rallef das der RAM oder die CPU mal schwankt ist normal, meine Frage lag eher darin:
Hattest du diese Probleme schon vorher oder wolltest du mir mitteilen, erst seit Scriptinstallation

[rallef]

kann ich nicht sagen, aber es werden ja viele Änderungen in die influxdb geschrieben seitdem ich das Skript gestartetd habe

[rallef]

hab halt viele Warnungen die in der influxdb geschrieben werden
ich werde die mal posten

[crunchip]

crunchip sagte:

Grundprinzip je Datenpunkttyp

Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse):
Nur Änderungen aufzeichnen: an
Entprellzeit: 300–1000 ms
Blockzeit: 0
„Trotzdem gleiche Werte aufzeichnen“: 600–3600 s (je nach gewünschter History‑Auflösung)
Minimale Differenz: 0 (bei Booleans/Zahlen mit kleinem Bereich)
Ergebnis: sehr wenige Punkte, aber alle Zustandswechsel sauber im Grafana‑Dashboard.
Kontinuierliche Messwerte mit Trend (CPU‑Last, RAM‑MB, Host‑Disk‑FreeMB, Health‑Score):

Nur Änderungen aufzeichnen: an
Entprellzeit: 500 ms wie im Screenshot ist ok
„Trotzdem gleiche Werte“: auf deinen Script‑Zyklus bzw. Host‑Intervalle ausrichten, z. B. 180–300 s, damit Influx wenigstens alle paar Minuten einen Punkt bekommt, selbst wenn sich nichts ändert.
Minimale Differenz: z. B. 1 % bei CPU‑Werten, 5–10 MB bei RAM, 1 Punkt beim Health‑Score.
Ignoriere 0/Nullwerte: an, falls der DP beim Start kurz 0/NULL ist und das im Dashboard nicht stören soll.
Pulse‑Werte für Events (RestartEventPulse, FlakyEventPulse, Deadlock‑Alarm‑Pulse etc.):

Nur Änderungen: an
Trotzdem gleiche Werte: 0 s (nicht nötig, der Pulse ist ein kurzer Wechsel 0→1→0)
Entprellzeit: klein (100–200 ms), damit jeder Pulse als eigener Punkt landet.
0/Null ignorieren: aus, sonst siehst du nur die 1, aber keinen „Rückfall“ im Graphen.

@rallef hast du aber schon beachtet? und auch Punkt4 im ersten Beitrag?

[rallef]

muss ich nachschauen

[rallef]

muss ich das für alle datenpunkte unter prozesse ändern ?

[rallef]

ok aber was ist was
Langsam ändernde Zustände (Booleans, Modus, Error‑Flags, Health‑Scores, Event‑Pulse): welche dp's sind das?

[rallef]

super vielen dank das habe ich noch nie berücksichtigt bei den anderen Datenpunkten meiner anderen Anwendungen. Vielleicht habe ich das problem schon vorher gehabt. aber das die Influxdb Instanz mehrmals täglich sich restartet ist neu. Werde alle Datenpunkte unter Prozesse heute abend mir anschauen und ggfls ändern. Hoffe das reicht dann damit Influxdb nicht mehr sich restartet

[crunchip]

@rallef sagte:

ok aber was ist was

ich habs oben im ersten Beitrag ergänzt