Wichtiger Hinweis für Redis Installationen!
-
@ro75 sofern ich den Prozess via iob stop beende, werden die Daten aber sofort geschrieben, oder?
-
@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. -
-
@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:
geschrieben, oder?
Konsole:
redis-cli bgsaveRo75.
-
@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
-
@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 geschriebenWenn 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 -
@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!
-
@oliverio sagte in Wichtiger Hinweis für Redis Installationen!:
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.
-
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
-
@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.
-
@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
-
@oliverio Aber ich habe doch gar kein Problem mit Redis. Ich hatte doch nur auf eine "Hilfeanfrage" geantwortet.
Ro75.
-
Du hattest gefragt, wie ich darauf komme
-
@oliverio mir ging es m @Dr-Bakterius
Ro75.
-
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
-
@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.
-
@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
-
@darkiop Naja ok,ich hab pro Host 2+Sentinel ... aber jupp
-
Kurzer Hinweis: Das Ganze geht auch über die normale Redis-Konfiguration (
sudo nano /etc/redis/redis.conf)Standard-Abschnitt unter "GLOBAL":
# Set the local environment which is used for string comparison operations, and # also affect the performance of Lua scripts. Empty String indicates the locale # is derived from the environment variables. locale-collate ""Angepasst zu:
locale-collate "C"Funktioniert (und spart den Weg über die Environment-Variables). Getestet mit Redis 7.2.4
-
ich bekomme wieder den Redis Fehler obwohl die locale stimmt und beim Test Nil im Redis Client wie im Forum beschrieben als Ergebnis rauskommt
Die Objects werden offenbar normal verarbeitet, der raspi hat sich aber bereits mehrmals aufgehängt wobei ich ziemlich sicher bin, dass das ioBroker auslöst.
Hat wer eine Idee?
Dankeschön
