Weihnachtsangebot 2025! 🎄

[OliverIO]

@ro75

Die Zeit bis zur nächsten Speicherung ist das Risiko des Verlust der Informationen, falls der Prozess oder der Rechner abstürzt.

[Ro75]

@oliverio "... isr doch Linux - da stürzt nix ab". Spaß. Also ich nutze Redis DB komplett seit 2 Jahren. Kein Absturz etc. - Aber korrekt deine Aussage. Muss letztlich jeder selber mitsich ausmachen.

Ro75.

[Hc-Yami]

@ro75 sofern ich den Prozess via iob stop beende, werden die Daten aber sofort geschrieben, oder?

[Thomas Braun]

@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:

sofern ich den Prozess via iob stop beende, werden die Daten aber sofort geschrieben, oder?

Ja, das ist das übliche Verhalten von ordentlich gestoppten Prozessen.
Deswegen ist es ja so gefährlich einen Rechner (egal welches OS da läuft) einfach abruppt vom Strom zu ziehen. Da hat das System nämlich keine Chance noch offene Dateien wieder zu schreiben.

[apollon77]

@hc-yami Bitte hier lesen https://forum.iobroker.net/topic/26327/redis-in-iobroker-überblick

[Ro75]

@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:

geschrieben, oder?

Konsole:

redis-cli bgsave

Ro75.

[apollon77]

@darkiop Am Ende hängt es von der Hardware und dem System und der Festplatte/SSD/SD ab. Auf einem System mit Proxmox hat man denke ich eine HDD oder SSD und damit ists irrelevant nochmal mehr.

Auf Systemen mit einer SD Karte kann das schon ganz anders aussehen.

Daher auch der Hinweis zu schauen wie es dem System geht.

Ingo

[OliverIO]

@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:

@ro75 sofern ich den Prozess via iob stop beende, werden die Daten aber sofort geschrieben, oder?

Welchen Prozess?
Wenn du Iobroker stoppst dann nicht. Für den sind die Daten schon geschrieben

Wenn du Redis ordentlich stoppst per Befehl oder Signal sigterm dann schon.

Sollte ich noch erwähnen, das es da noch einen weiteren Cache auf Systemebene für lese/schreiboperationen auf Platte gibt? Dort gibt es auch Medium spezifische Unterschiede .
Aber ich glaube dann wird es zu kompliziert
https://medium.com/marionete/linux-disk-cache-was-always-there-741bef097e7f
Der normale Anwender sollte sich damit nicht beschäftigen. Solange ordentlich gestoppt und heruntergefahren wird funktioniert das alles ordentlich

[Dr. Bakterius]

@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:

dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden.

Also ich habe das getestet. Mit der Standard-Einstellung sind die Schreibraten mit redis bei mir etwa um den Faktor 55 höher als bei jsonl!

[Ro75]

@oliverio sagte in Wichtiger Hinweis für Redis Installationen!:

@ro75

Die Zeit bis zur nächsten Speicherung ist das Risiko des Verlust der Informationen, falls der Prozess oder der Rechner abstürzt.

Da ich mir des Risikos bewusst bin, habe ich das bei mir so konfiguriert, dass nur 2 mal pro Tag etwa auf die SSD geschrieben wird. Wie gesagt, nutzte das System mit der Redis DB so seit 2 Jahren und mit meiner Konfig noch kein Datenverlust gehabt.

Ro75.

[OliverIO]

@ro75

Dann hast du syslog und die anderen logausgaben auch ins RAM verlegt?
https://linuxblog.io/increase-performance-lifespan-ssds-sd-cards/

Da liegt das größte Risiko für viele schreiboperationen

[Ro75]

@oliverio sagte in Wichtiger Hinweis für Redis Installationen!:

Dann hast du syslog und die anderen logausgaben auch ins RAM verlegt?

Nein.

Da liegt das größte Risiko für viele schreiboperationen

Wie kommst du darauf?

Ro75.

[OliverIO]

@ro75
Hm, ich schaue in meine syslogs?
Ich sehe wie oft da log Einträge drin stehen?
Gehen wir mal davon aus, das linux maximal 1000ms cached, dann ist das vernachlässigbar und du kannst direkt am timestamp ablesen wie oft am Tag in die Datei geschrieben wird. Dazu dann auch immer in den gleichen Speicherblock.
Jeder Block hat aber nur eine maximale Anzahl wie oft geschrieben werden darf. Wahrscheinlich hat die Hardware auch noch ein caching die versucht das zu optimieren, aber immer hinsichtlich der ausfallsicherheit nicht sehr lange.
Wenn dann eine gewisse Anzahl an schreiboperationen erreicht ist, verschiebt der sd Controller den Block auf einen weniger benutzten (wear leveling)
Daher gehört es zu einer der Optimierungen bei sd Karten (hilft auch bei ssd Platten, aber da gibt mehr Reserve Blöcke) die Bereiche mit hohen schreiboperationen in das RAM zu verlagern.

Das Thema mit sterbenden sd Karten kannst du häufig, im speziellen in Verbindung mit dem raspberry, auf vielen Seiten finden.

Nachtrag
Hab den Wert gefunden. Er ist bei 30 Sekunden
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/4/html/reference_guide/s3-proc-sys-vm#

dirty_expire_centisecs

[Ro75]

@oliverio Aber ich habe doch gar kein Problem mit Redis. Ich hatte doch nur auf eine "Hilfeanfrage" geantwortet.

Ro75.

[OliverIO]

@ro75

Du hattest gefragt, wie ich darauf komme

[Ro75]

@oliverio mir ging es m @Dr-Bakterius

Ro75.

[apollon77]

Das ideale Setup in meinen Augen sind zwei Redis ... einen für States und einen für Objekts ... hier kann man dann viel besser die Schreiblast austarieren das "Objects" SEEHRR gross ist aber sich seltener ändert und States klein ist und sich viel öfter ändert

[darkiop]

@apollon77 sagte in Wichtiger Hinweis für Redis Installationen!:

@darkiop Am Ende hängt es von der Hardware und dem System und der Festplatte/SSD/SD ab.

Ja. Hatte bei dem Versuch auch nichts anderes erwartet. 😂

[darkiop]

@apollon77 sagte in Wichtiger Hinweis für Redis Installationen!:

Das ideale Setup in meinen Augen sind zwei Redis ... einen für States und einen für Objekts ... hier kann man dann viel besser die Schreiblast austarieren das "Objects" SEEHRR gross ist aber sich seltener ändert und States klein ist und sich viel öfter ändert

dann also 6 redis‘e im sentinel betrieb 😳😂

[apollon77]

@darkiop Naja ok,ich hab pro Host 2+Sentinel ... aber jupp