Wichtiger Hinweis für Redis Installationen!
-
Hier mal zum Vergleich, ich habe ~ 30.000/30.000 und bis gestern Abend 21:30 die States in Redis / Objects in jsonl.
Hab das jetzt mal auf jsonl/jsonl migriert und nun schauts so aus:
Imho nicht wirklich relevant und ich werde die reduzierte Komplexität erstmal so belassen ;)
-
@apollon77 ich hatte den Hinweis mit der CPU-Auslastung schon vernommen. Ich hatte daraufhin aber gegoogelt und herausgelesen, dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden. Ist dem nicht mehr so?
-
@apollon77 ich hatte den Hinweis mit der CPU-Auslastung schon vernommen. Ich hatte daraufhin aber gegoogelt und herausgelesen, dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden. Ist dem nicht mehr so?
@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:
dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden. Ist dem nicht mehr so?
Ja, die DB läuft im RAM. Aber, je nach Konfiguration (Anzahl Änderungen + Zeit) wird dann die DB auch auf die SSD geschrieben. Das kann 1x am Tag, 5 mal am Tag oder 5 mal die Stunde sein. Das ist aber wie gesagt eine Sache der Konfiguration und wieviel im ioBroker läuft.
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
@hc-yami sagte in Wichtiger Hinweis für Redis Installationen!:
dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden. Ist dem nicht mehr so?
Ja, die DB läuft im RAM. Aber, je nach Konfiguration (Anzahl Änderungen + Zeit) wird dann die DB auch auf die SSD geschrieben. Das kann 1x am Tag, 5 mal am Tag oder 5 mal die Stunde sein. Das ist aber wie gesagt eine Sache der Konfiguration und wieviel im ioBroker läuft.
Ro75.
Die Zeit bis zur nächsten Speicherung ist das Risiko des Verlust der Informationen, falls der Prozess oder der Rechner abstürzt.
Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
Die Zeit bis zur nächsten Speicherung ist das Risiko des Verlust der Informationen, falls der Prozess oder der Rechner abstürzt.
-
@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.
-
@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. -
@ro75 sofern ich den Prozess via iob stop beende, werden die Daten aber sofort geschrieben, oder?
-
Hier mal zum Vergleich, ich habe ~ 30.000/30.000 und bis gestern Abend 21:30 die States in Redis / Objects in jsonl.
Hab das jetzt mal auf jsonl/jsonl migriert und nun schauts so aus:
Imho nicht wirklich relevant und ich werde die reduzierte Komplexität erstmal so belassen ;)
@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
-
@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!:
@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 -
@apollon77 ich hatte den Hinweis mit der CPU-Auslastung schon vernommen. Ich hatte daraufhin aber gegoogelt und herausgelesen, dass redis wohl im Arbeitsspeicher die States ablegt und dadurch die SSDs geschohnt werden. Ist dem nicht mehr so?
@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!
-
Die Zeit bis zur nächsten Speicherung ist das Risiko des Verlust der Informationen, falls der Prozess oder der Rechner abstürzt.
@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.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
@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
-
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.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
@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
-
@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.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
@oliverio Aber ich habe doch gar kein Problem mit Redis. Ich hatte doch nur auf eine "Hilfeanfrage" geantwortet.
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
573
Online32.7k
Users82.6k
Topics1.3m
Posts