NEWS
Redis in ioBroker - Überblick
-
@bert-0 sagte in Redis in ioBroker - Überblick:
Ich habe nun mit :
docker run -d --name redis-qnap --restart=always -p 6379:6379 -v /share/CE_CACHEDEV1_DATA/Container/redis-data:/data -v /share/CE_CACHEDEV1_DATA/Container/redis-data/conf/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.confeinen redis Container als Host auf meinem QNAP installiert.
Was meinst du mit "Host"? Host-Netzwerk kann nicht gemeint sein mit diesem run Befehl.
Nun habe ich Master ( 192.168.2.xxx) im Container als Bridge und zusätzlich noch einen Raspy im gleichen Netzwerkadressraum.
?? Du hast einem Bridge-Netzwerk den gleichen Adressraum zugewiesen wie dem physischen Netzwerk?
Ich weiss das ich in einem anderen Adressraum bin, aber gibt es da eine Lösung?
Oder kann ich den iobroker Master von Bridge in Host netzwerkmäßig ändern, und wie kann ich dann auf diesen zugreifen ausserhalb des Containers?Bitte nochmal detailliert beschreiben, wie die Adressbereiche aussehen, welcher Container mit welcher IP läuft und was der Raspi da für eine Rolle spielen soll.
@marc-berg sagte in Redis in ioBroker - Überblick:
Ich habe nun mit :
docker run -d --name redis-qnap --restart=always -p 6379:6379 -v /share/CE_CACHEDEV1_DATA/Container/redis-data:/data -v /share/CE_CACHEDEV1_DATA/Container/redis-data/conf/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.confeinen redis Container als Host auf meinem QNAP installiert.
Was meinst du mit "Host"? Host-Netzwerk kann nicht gemeint sein mit diesem run Befehl.
Hast du Recht, ist nur Standard ( NAT ) . Sorry
@marc-berg sagte in Redis in ioBroker - Überblick:
?? Du hast einem Bridge-Netzwerk den gleichen Adressraum zugewiesen wie dem physischen Netzwerk?
ja, das ist der Adressraum meiner Fritzbox und wird über die Bridge auf den virtuellen Switch des QNAPS geleitet. Grund ist, ich habe einen Raspy als Slave/Multihost und virtueller CCU und der liegt im gleichen Adressraum ( Iobroker Master : 192.168.2.30 und Slave Raspberry 192.168.2.40).
Wenn du hier einen anderen Konfigurationsvorschlag hast dann gerne. Der Redis Server liegt auf: 10.0.3.2. Der wir aber wahrscheinlich gekapselt vom Netzwerk.
Danke
-
@marc-berg sagte in Redis in ioBroker - Überblick:
Ich habe nun mit :
docker run -d --name redis-qnap --restart=always -p 6379:6379 -v /share/CE_CACHEDEV1_DATA/Container/redis-data:/data -v /share/CE_CACHEDEV1_DATA/Container/redis-data/conf/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.confeinen redis Container als Host auf meinem QNAP installiert.
Was meinst du mit "Host"? Host-Netzwerk kann nicht gemeint sein mit diesem run Befehl.
Hast du Recht, ist nur Standard ( NAT ) . Sorry
@marc-berg sagte in Redis in ioBroker - Überblick:
?? Du hast einem Bridge-Netzwerk den gleichen Adressraum zugewiesen wie dem physischen Netzwerk?
ja, das ist der Adressraum meiner Fritzbox und wird über die Bridge auf den virtuellen Switch des QNAPS geleitet. Grund ist, ich habe einen Raspy als Slave/Multihost und virtueller CCU und der liegt im gleichen Adressraum ( Iobroker Master : 192.168.2.30 und Slave Raspberry 192.168.2.40).
Wenn du hier einen anderen Konfigurationsvorschlag hast dann gerne. Der Redis Server liegt auf: 10.0.3.2. Der wir aber wahrscheinlich gekapselt vom Netzwerk.
Danke
@bert-0 sagte in Redis in ioBroker - Überblick:
ja, das ist der Adressraum meiner Fritzbox und wird über die Bridge auf den virtuellen Switch des QNAPS geleitet.
Das ist dann aber kein Bridge-Netzwerk, sondern ein MACVLAN (in Docker Sprech), auch wenn das QNAP hier nicht so nennt.
Wenn du hier einen anderen Konfigurationsvorschlag hast dann gerne. Der Redis Server liegt auf: 10.0.3.2. Der wir aber wahrscheinlich gekapselt vom Netzwerk.
Ja genau, auf diese IPs hast du (ohne Verbiegungen an den Routen) von außen keinen Zugriff. Darum gibt es ja das Portmapping, um über diese Ports des Hosts zuzugreifen. ABER von einem Container im MACVLAN darf nicht auf den Host zugegriffen werden. :man-shrugging:
Aus meiner Sicht hast du zwei Möglichkeiten
-
den Redis Container mit ins MACVLAN setzen (an den Virt. Switch 3) oder
-
der ioBroker Container zusätzlich an dein Bridge-Netzwerk (lxcbr0) anbinden
Im zweiten Fall kannst du vom ioB dann direkt auf den redis-Container zugreifen.
-
-
@bert-0 sagte in Redis in ioBroker - Überblick:
ja, das ist der Adressraum meiner Fritzbox und wird über die Bridge auf den virtuellen Switch des QNAPS geleitet.
Das ist dann aber kein Bridge-Netzwerk, sondern ein MACVLAN (in Docker Sprech), auch wenn das QNAP hier nicht so nennt.
Wenn du hier einen anderen Konfigurationsvorschlag hast dann gerne. Der Redis Server liegt auf: 10.0.3.2. Der wir aber wahrscheinlich gekapselt vom Netzwerk.
Ja genau, auf diese IPs hast du (ohne Verbiegungen an den Routen) von außen keinen Zugriff. Darum gibt es ja das Portmapping, um über diese Ports des Hosts zuzugreifen. ABER von einem Container im MACVLAN darf nicht auf den Host zugegriffen werden. :man-shrugging:
Aus meiner Sicht hast du zwei Möglichkeiten
-
den Redis Container mit ins MACVLAN setzen (an den Virt. Switch 3) oder
-
der ioBroker Container zusätzlich an dein Bridge-Netzwerk (lxcbr0) anbinden
Im zweiten Fall kannst du vom ioB dann direkt auf den redis-Container zugreifen.
@marc-berg sagte in Redis in ioBroker - Überblick:
Aus meiner Sicht hast du zwei Möglichkeiten
den Redis Container mit ins MACVLAN setzen (an den Virt. Switch 3) oder
der ioBroker Container zusätzlich an dein Bridge-Netzwerk (lxcbr0) anbinden
Danke für deine Geduld. Der 1. Fall ( (an den Virt. Switch 3) ) ist aus meiner Sicht der beste.
jetzt scheitert das aber daran, wie ich das per Dockerbefehl bei Austausch mit einbinden kann. Das ist übrigens auch das gleiche problem bei meinem iobroker. Ich kann den über Docker installieren, aber muss danach manuell auf Bridge mit der gewünschten IP setzen.
@bert-0 sagte in Redis in ioBroker - Überblick:
docker run -d --name redis-qnap --restart=always -p 6379:6379 -v /share/CE_CACHEDEV1_DATA/Container/redis-data:/data -v /share/CE_CACHEDEV1_DATA/Container/redis-data/conf/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.conf
Hast du eine Idee, wie ich das per Docker so konfigurieren kann, dass die im gleichen Netzwerk sind?
Danke
Bert
-
-
Ich habe auch mal wieder redis probiert. Die CPU-Last sinkt von 9% auf 6%. Aber die Disk IO schnellt stark nach oben. Damit wird die SSD viel stärker gefordert und deren Lebensdauer sinkt. Ist das normal?
Da wo man nur einen Strich nähe 0 sieht ist jsonl im Einsatz. Die fast 3,5 M sind mit redis.Wegen der 3% CPU-Last hat es wenig Sinn redis zu verwenden - vor allem wenn die SSD so übermäßig belastet wird. Deswegen wieder auf jsonl umgestiegen. Der Wechsel geht ja schnell.
-
@marc-berg sagte in Redis in ioBroker - Überblick:
Aus meiner Sicht hast du zwei Möglichkeiten
den Redis Container mit ins MACVLAN setzen (an den Virt. Switch 3) oder
der ioBroker Container zusätzlich an dein Bridge-Netzwerk (lxcbr0) anbinden
Danke für deine Geduld. Der 1. Fall ( (an den Virt. Switch 3) ) ist aus meiner Sicht der beste.
jetzt scheitert das aber daran, wie ich das per Dockerbefehl bei Austausch mit einbinden kann. Das ist übrigens auch das gleiche problem bei meinem iobroker. Ich kann den über Docker installieren, aber muss danach manuell auf Bridge mit der gewünschten IP setzen.
@bert-0 sagte in Redis in ioBroker - Überblick:
docker run -d --name redis-qnap --restart=always -p 6379:6379 -v /share/CE_CACHEDEV1_DATA/Container/redis-data:/data -v /share/CE_CACHEDEV1_DATA/Container/redis-data/conf/redis.conf:/usr/local/etc/redis/redis.conf redis redis-server /usr/local/etc/redis/redis.conf
Hast du eine Idee, wie ich das per Docker so konfigurieren kann, dass die im gleichen Netzwerk sind?
Danke
Bert
@bert-0 sagte in Redis in ioBroker - Überblick:
Hast du eine Idee, wie ich das per Docker so konfigurieren kann, dass die im gleichen Netzwerk sind?
Da gibt es doch so eine schicke Oberfläche in der Container Station, geht das damit nicht?
Unter Docker musst du dein run Befehl um den "network" Parameter ergänzen:
docker run --network=mein_macvlan_netzwerk --ip=192.168.2.x ....Wie das Netzwerk heißt bekommst du mit
docker network lsraus. Aber ich bin, was QNAP angeht, völlig ahnungslos und weiß nicht, wie das unter der Haube verdrahtet ist.
-
Ich habe auch mal wieder redis probiert. Die CPU-Last sinkt von 9% auf 6%. Aber die Disk IO schnellt stark nach oben. Damit wird die SSD viel stärker gefordert und deren Lebensdauer sinkt. Ist das normal?
Da wo man nur einen Strich nähe 0 sieht ist jsonl im Einsatz. Die fast 3,5 M sind mit redis.Wegen der 3% CPU-Last hat es wenig Sinn redis zu verwenden - vor allem wenn die SSD so übermäßig belastet wird. Deswegen wieder auf jsonl umgestiegen. Der Wechsel geht ja schnell.
@dr-bakterius sagte in Redis in ioBroker - Überblick:
Ist das normal?
Das hängt im Wesentlichen davon ab, wie die DB parametriert wurde und wieviel Datenänderungen du an den States hast. Über den "save" Parameter kann man ja sehr genau vorgeben, wie oft gespeichert werden soll.
# Unless specified otherwise, by default Redis will save the DB: # * After 3600 seconds (an hour) if at least 1 change was performed # * After 300 seconds (5 minutes) if at least 100 changes were performed # * After 60 seconds if at least 10000 changes were performed # # You can set these explicitly by uncommenting the following line. # # save 3600 1 600 100 60 10000Außerdem könnte man auch noch auf "AOF" umstellen. Damit werden alle Änderungen an den Daten immer als kleine Häppchen an die .aof Datei angehängt. In regelmäßigen Abständen (je nach Konfiguration) erfolgt dann ein Umkopieren in die *.rdb Datei. Ob dabei die Schreiblast sinkt, habe ich aber nicht ausprobiert. Ich fand' es charmant, dass die Daten praktisch in Echtzeit weggeschrieben werden, ohne dass jedesmal die rdb-Datei komplett neu erstellt wird.
-
@dr-bakterius sagte in Redis in ioBroker - Überblick:
Ist das normal?
Das hängt im Wesentlichen davon ab, wie die DB parametriert wurde und wieviel Datenänderungen du an den States hast. Über den "save" Parameter kann man ja sehr genau vorgeben, wie oft gespeichert werden soll.
# Unless specified otherwise, by default Redis will save the DB: # * After 3600 seconds (an hour) if at least 1 change was performed # * After 300 seconds (5 minutes) if at least 100 changes were performed # * After 60 seconds if at least 10000 changes were performed # # You can set these explicitly by uncommenting the following line. # # save 3600 1 600 100 60 10000Außerdem könnte man auch noch auf "AOF" umstellen. Damit werden alle Änderungen an den Daten immer als kleine Häppchen an die .aof Datei angehängt. In regelmäßigen Abständen (je nach Konfiguration) erfolgt dann ein Umkopieren in die *.rdb Datei. Ob dabei die Schreiblast sinkt, habe ich aber nicht ausprobiert. Ich fand' es charmant, dass die Daten praktisch in Echtzeit weggeschrieben werden, ohne dass jedesmal die rdb-Datei komplett neu erstellt wird.
Moin,
vor einiger Zeit hatte ich States und Objects auf Redis umgestellt. Jedesmal, wenn die VM neu starten oder einfach nur herunterfahren sollte, hat das etwa 1:40 Minuten gedauert. Heute habe ich mich mal auf die Suche gemacht, auch, weil ich die Warnung bekam, dass die Locale wieder umgestellt werden muss. Da wurde also gestern Abend bei den Updates die Config überschrieben.
Das Ergebnis der Suche war, dass ioBroker zu lange brauchte und dann abgeschossen wurde. Also mal die Logs von ioBroker angesehen und herausgefunden, dass dort schon die Verbindung zur Datenbank fehlte. Demnach wurde Redis zu früh beendet, oder ioBroker zu spät.
Also habe ich erstmal beides auf JSONL umgestellt. Nun fährt die VM wieder ruck-zuck herunter und startet dementsprechend flott neu.
Mit JSONL gibt top folgendes aus:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 601 iobroker 20 0 11.2g 482936 45336 S 21.6 5.9 5:59.37 iobroker.js-con 701 iobroker 20 0 11.2g 428816 46196 S 15.6 5.3 4:48.49 io.javascript.0 679 iobroker 20 0 21.1g 278612 48672 S 4.7 3.4 1:37.32 node-red 2004 iobroker 20 0 693180 107708 43808 S 4.3 1.3 1:14.40 io.statistics.0 647 iobroker 20 0 775992 136060 37920 S 4.0 1.7 1:14.89 io.influxdb.0 801 iobroker 20 0 10.7g 134092 40248 S 3.3 1.6 0:44.06 io.hue.0 2161 iobroker 20 0 886904 90892 38384 S 0.7 1.1 0:08.82 io.ws.0 916 iobroker 20 0 691744 89264 38744 S 0.3 1.1 0:03.31 io.hm-rpc.2 931 iobroker 20 0 685204 83752 39288 S 0.3 1.0 0:03.53 io.s7.0 946 iobroker 20 0 686820 81716 39624 S 0.3 1.0 0:02.20 io.chromecast.0 1701 iobroker 20 0 749024 77496 38700 S 0.3 1.0 0:04.54 io.jeelink.0 2039 iobroker 20 0 966580 109288 39884 S 0.3 1.3 0:07.40 io.web.0 2236 iobroker 20 0 883100 85336 39796 S 0.3 1.0 0:03.28 io.tankerkoenigDie CPU Auslastung der VM hat sich etwas erhöht:
Disk IO ist ok:
RAM passt auch:
Daher lasse ich es erstmal auf JSONL. Wenn mir Probleme auffallen, werde ich eine eigene VM oder einen Container für Redis anlegen, welcher durchläuft, wenn ioBroker neu startet oder herunterfährt. Allerdings könnte da dann noch das Netzwerk reingrätschen, wenn die VM von ioBroker das Netzwerk kappt, bevor ioBroker fertig zum herunterfahren ist. - Irgendwas ist ja immer :grin:
Ach ja die Konfig der VM:
und vom Proxmox Host: (Intel NUC 12, NUC12WSHi5 Wall Street Canyon Mini-PC Desktop)
Gruß
Peterfido
Proxmox auf Intel NUC12WSHi5
ioBroker: Debian (VM)
CCU: Debmatic (VM)
Influx: Debian (VM)
Grafana: Debian (VM)
eBus: Debian (VM)
Zigbee: Debian (VM) mit zigbee2mqtt -
Moin,
vor einiger Zeit hatte ich States und Objects auf Redis umgestellt. Jedesmal, wenn die VM neu starten oder einfach nur herunterfahren sollte, hat das etwa 1:40 Minuten gedauert. Heute habe ich mich mal auf die Suche gemacht, auch, weil ich die Warnung bekam, dass die Locale wieder umgestellt werden muss. Da wurde also gestern Abend bei den Updates die Config überschrieben.
Das Ergebnis der Suche war, dass ioBroker zu lange brauchte und dann abgeschossen wurde. Also mal die Logs von ioBroker angesehen und herausgefunden, dass dort schon die Verbindung zur Datenbank fehlte. Demnach wurde Redis zu früh beendet, oder ioBroker zu spät.
Also habe ich erstmal beides auf JSONL umgestellt. Nun fährt die VM wieder ruck-zuck herunter und startet dementsprechend flott neu.
Mit JSONL gibt top folgendes aus:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 601 iobroker 20 0 11.2g 482936 45336 S 21.6 5.9 5:59.37 iobroker.js-con 701 iobroker 20 0 11.2g 428816 46196 S 15.6 5.3 4:48.49 io.javascript.0 679 iobroker 20 0 21.1g 278612 48672 S 4.7 3.4 1:37.32 node-red 2004 iobroker 20 0 693180 107708 43808 S 4.3 1.3 1:14.40 io.statistics.0 647 iobroker 20 0 775992 136060 37920 S 4.0 1.7 1:14.89 io.influxdb.0 801 iobroker 20 0 10.7g 134092 40248 S 3.3 1.6 0:44.06 io.hue.0 2161 iobroker 20 0 886904 90892 38384 S 0.7 1.1 0:08.82 io.ws.0 916 iobroker 20 0 691744 89264 38744 S 0.3 1.1 0:03.31 io.hm-rpc.2 931 iobroker 20 0 685204 83752 39288 S 0.3 1.0 0:03.53 io.s7.0 946 iobroker 20 0 686820 81716 39624 S 0.3 1.0 0:02.20 io.chromecast.0 1701 iobroker 20 0 749024 77496 38700 S 0.3 1.0 0:04.54 io.jeelink.0 2039 iobroker 20 0 966580 109288 39884 S 0.3 1.3 0:07.40 io.web.0 2236 iobroker 20 0 883100 85336 39796 S 0.3 1.0 0:03.28 io.tankerkoenigDie CPU Auslastung der VM hat sich etwas erhöht:
Disk IO ist ok:
RAM passt auch:
Daher lasse ich es erstmal auf JSONL. Wenn mir Probleme auffallen, werde ich eine eigene VM oder einen Container für Redis anlegen, welcher durchläuft, wenn ioBroker neu startet oder herunterfährt. Allerdings könnte da dann noch das Netzwerk reingrätschen, wenn die VM von ioBroker das Netzwerk kappt, bevor ioBroker fertig zum herunterfahren ist. - Irgendwas ist ja immer :grin:
Ach ja die Konfig der VM:
und vom Proxmox Host: (Intel NUC 12, NUC12WSHi5 Wall Street Canyon Mini-PC Desktop)
@peterfido ich habe keine VM, aber ich habe den Reboot oder Shutdown meines Server anders gelöst. Via Skript beende ich zunächst den ioBroker, danach speichere ich die Redis-DB zwangsweise und danach der eigentliche Shutdown oder Reboot.
Das funktioniert ohne Probleme, ohne Datenverlust und geht richtig schnell.
Ro75.
-
Moin,
vor einiger Zeit hatte ich States und Objects auf Redis umgestellt. Jedesmal, wenn die VM neu starten oder einfach nur herunterfahren sollte, hat das etwa 1:40 Minuten gedauert. Heute habe ich mich mal auf die Suche gemacht, auch, weil ich die Warnung bekam, dass die Locale wieder umgestellt werden muss. Da wurde also gestern Abend bei den Updates die Config überschrieben.
Das Ergebnis der Suche war, dass ioBroker zu lange brauchte und dann abgeschossen wurde. Also mal die Logs von ioBroker angesehen und herausgefunden, dass dort schon die Verbindung zur Datenbank fehlte. Demnach wurde Redis zu früh beendet, oder ioBroker zu spät.
Also habe ich erstmal beides auf JSONL umgestellt. Nun fährt die VM wieder ruck-zuck herunter und startet dementsprechend flott neu.
Mit JSONL gibt top folgendes aus:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 601 iobroker 20 0 11.2g 482936 45336 S 21.6 5.9 5:59.37 iobroker.js-con 701 iobroker 20 0 11.2g 428816 46196 S 15.6 5.3 4:48.49 io.javascript.0 679 iobroker 20 0 21.1g 278612 48672 S 4.7 3.4 1:37.32 node-red 2004 iobroker 20 0 693180 107708 43808 S 4.3 1.3 1:14.40 io.statistics.0 647 iobroker 20 0 775992 136060 37920 S 4.0 1.7 1:14.89 io.influxdb.0 801 iobroker 20 0 10.7g 134092 40248 S 3.3 1.6 0:44.06 io.hue.0 2161 iobroker 20 0 886904 90892 38384 S 0.7 1.1 0:08.82 io.ws.0 916 iobroker 20 0 691744 89264 38744 S 0.3 1.1 0:03.31 io.hm-rpc.2 931 iobroker 20 0 685204 83752 39288 S 0.3 1.0 0:03.53 io.s7.0 946 iobroker 20 0 686820 81716 39624 S 0.3 1.0 0:02.20 io.chromecast.0 1701 iobroker 20 0 749024 77496 38700 S 0.3 1.0 0:04.54 io.jeelink.0 2039 iobroker 20 0 966580 109288 39884 S 0.3 1.3 0:07.40 io.web.0 2236 iobroker 20 0 883100 85336 39796 S 0.3 1.0 0:03.28 io.tankerkoenigDie CPU Auslastung der VM hat sich etwas erhöht:
Disk IO ist ok:
RAM passt auch:
Daher lasse ich es erstmal auf JSONL. Wenn mir Probleme auffallen, werde ich eine eigene VM oder einen Container für Redis anlegen, welcher durchläuft, wenn ioBroker neu startet oder herunterfährt. Allerdings könnte da dann noch das Netzwerk reingrätschen, wenn die VM von ioBroker das Netzwerk kappt, bevor ioBroker fertig zum herunterfahren ist. - Irgendwas ist ja immer :grin:
Ach ja die Konfig der VM:
und vom Proxmox Host: (Intel NUC 12, NUC12WSHi5 Wall Street Canyon Mini-PC Desktop)
@peterfido Hast/Hattest Du iobroker und redis in separaten VMs/LXCs? Falls ja, dann kannst Du in Proxmox ja die Reihenfolge (inklusive Verzögerung) einstellen, in der sie gestartet/gestoppt werden. Bei mir läuft es problemlos. Es wird erst die iobroker gestoppt, bevor dann redis runterfährt. Beim Start dann genau andersrum.
Aber natürlich, weil die Dienste in separaten VMs/Containern laufen. Wenn beide in einem laufen (was etwas der Sinnhaftigkeit von virtualisierten Systemen widerspricht), dann musst Du das direkt im System einstellen, dass der iobroker-Dienst eben erst startet, wenn redis gestartet ist.Gruss, Jürgen
-
@peterfido Hast/Hattest Du iobroker und redis in separaten VMs/LXCs? Falls ja, dann kannst Du in Proxmox ja die Reihenfolge (inklusive Verzögerung) einstellen, in der sie gestartet/gestoppt werden. Bei mir läuft es problemlos. Es wird erst die iobroker gestoppt, bevor dann redis runterfährt. Beim Start dann genau andersrum.
Aber natürlich, weil die Dienste in separaten VMs/Containern laufen. Wenn beide in einem laufen (was etwas der Sinnhaftigkeit von virtualisierten Systemen widerspricht), dann musst Du das direkt im System einstellen, dass der iobroker-Dienst eben erst startet, wenn redis gestartet ist.Gruss, Jürgen
@wildbill Danach hatte ich (kurz) gesucht. Also wie man die Reihenfolge der Dienste bei systemd vorgeben kann und dass er wartet. Also beim Start muss er auf Redis warten und beim Beenden auf ioBroker.
Beides in einer VM. Eigentlich alles drei, da ich zwei Redis Instanzen, jeweils für States und Objects, eingerichtet hatte. Die zusätzlich VM für Redis habe ich oben ja als Plan B erwähnt. Jetzt lass ich es erstmal so und vergleiche in ein paar Tagen per Diagramme im Proxmox.
Die CPU-Last ist gestern nach den Updates zurückgegangen. Heute bei der Umstellung auf JSONL wieder etwas hoch.
-
@peterfido sagte in Redis in ioBroker - Überblick:
Die CPU-Last ist gestern nach den Updates zurückgegangen. Heute bei der Umstellung auf JSONL wieder etwas hoch.
Gerade deswegen habe ich auf Redis umgestellt. Deutlich weniger CPU-Last und alles im ioBroker (speziell Objektbaum und VIS) laden deutlich schneller.
Ro75.
-
@wildbill Danach hatte ich (kurz) gesucht. Also wie man die Reihenfolge der Dienste bei systemd vorgeben kann und dass er wartet. Also beim Start muss er auf Redis warten und beim Beenden auf ioBroker.
Beides in einer VM. Eigentlich alles drei, da ich zwei Redis Instanzen, jeweils für States und Objects, eingerichtet hatte. Die zusätzlich VM für Redis habe ich oben ja als Plan B erwähnt. Jetzt lass ich es erstmal so und vergleiche in ein paar Tagen per Diagramme im Proxmox.
Die CPU-Last ist gestern nach den Updates zurückgegangen. Heute bei der Umstellung auf JSONL wieder etwas hoch.
@peterfido Bei der jeweiligen VM/LXC unter Options->Start/Shutdown order. Da kannst Du für die jeweilige VM/LXC eine Nummer eintragen. Je größer, desto später wird dann gestartet. Wenn Du bei redis beispielsweise 1 einträgst und bei iobroker 2, wird zuerst redis gestartet und danach iobroker. Damit iobroker mit dem Start wartet bis redis läuft, bei redis unter Startup delay dann eben noch eine Zahl, das entspricht dann der Verzögerung in Sekunden. Bei mir habe ich 5 drin, da nach redis noch einiges anderes startet bis iobroker an der Reihe ist. Wenn beide direkt danach starten sollen, dann musst Du halt mal nur redis starten und mitstoppen, wie lange es braucht, bis redis läuft. Noch 2-3 Sekunden als Reserve oben drauf und gut.
Beim Runterfahren wird dann alles in umgekehrter Reihenfolge beendet. Zuerst die höchsten Nummen, in dem Fall also iobroker vor redis. Auch dazu kann man Verzögerungen eintragen, dann aber eben bei iobroker. Also beispielsweise 10, wenn redis mit dem Runterfahren 10 Sekunden warten soll, nachdem iobroker beendet wird.Gruss, Jürgen
EDIT: Ach so, Du hattest beides in einer VM? Dann bringt das Einstellen in Proxmox natürlich nix. Da würde ich Dir aber dennoch empfehlen, das auf separate LXC auszulagern, dafür hast Du Proxmox ja laufen. Dann kannst Du alles getrennt backuppen, usw.
-
Moin zusammen,
hab nach dieser Anleitung auf REDIS umgestellt, lief auch ganz gut, nun hab ich das Problem, das mein Debian nicht mehr updaten will und ich ne Fehlmeldung bekomme zwecks Quellenunsicherheit von chris-lea:
E: Das Depot »http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release« enthält keine Release-Datei. N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert. N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).Da ich mich mit Paketsicherheit und den Keys bei den Repositories und Linux nicht so gut auskenne, bräuchte ich diesbezüglich etwas Hilfe, wie ich wieder an meine Updates komme.
-
Moin zusammen,
hab nach dieser Anleitung auf REDIS umgestellt, lief auch ganz gut, nun hab ich das Problem, das mein Debian nicht mehr updaten will und ich ne Fehlmeldung bekomme zwecks Quellenunsicherheit von chris-lea:
E: Das Depot »http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release« enthält keine Release-Datei. N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert. N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).Da ich mich mit Paketsicherheit und den Keys bei den Repositories und Linux nicht so gut auskenne, bräuchte ich diesbezüglich etwas Hilfe, wie ich wieder an meine Updates komme.
Wie genau bist du da unterwegs?
sudo apt updatezeigen.
Du solltest kein schnubbibuntu-Repo einfach in dein Debian klatschen. Das passt nicht.
Schmeiß den Sums wieder raus und verwende das offizielle Redis-Repo vom Hersteller.
(Oder vielleicht am Besten da gar nix fummeln und einfach die Version aus dem hauseigenen Repo nehmen).https://forum.iobroker.net/topic/59231/phantastische-repositories-und-wo-sie-zu-finden-sind
Noch am Rande die Info, das redis nicht mehr als OpenSource-Sorftware eingestuft wird. Kann in Zukunft zu Problemen führen. Ich würde heute jedenfalls nicht mehr darauf setzen.
-
@thomas-braun sagte in Redis in ioBroker - Überblick:
Wie genau bist du da unterwegs?
sudo apt updatezeigen.
Yep, klassisch über apt update
@thomas-braun sagte in Redis in ioBroker - Überblick:
Du solltest kein schnubbibuntu-Repo einfach in dein Debian klatschen. Das passt nicht.
Schmeiß den Sums wieder raus und verwende das offizielle Redis-Repo vom Hersteller.
(Oder vielleicht am Besten da gar nix fummeln und einfach die Version aus dem hauseigenen Repo nehmen).https://forum.iobroker.net/topic/59231/phantastische-repositories-und-wo-sie-zu-finden-sind
Noch am Rande die Info, das redis nicht mehr als OpenSource-Sorftware eingestuft wird. Kann in Zukunft zu Problemen führen. Ich würde heute jedenfalls nicht mehr darauf setzen.
Danke für den Tipp :grimacing: ich habe die Schnubbibuntu Repo wie in der Aleitung eingefügt... mehr nicht. Im Gegenteil, anstattan den sources zu "fummeln" hab ich se mal aufgeräumt, weil Debian jedesmal nen neuen List Eintrag generiert hat.
Ich dachte die Offizielle Version ist zu alt?
Also einfach über apt installieren.. okay ;-) -
@thomas-braun sagte in Redis in ioBroker - Überblick:
Wie genau bist du da unterwegs?
sudo apt updatezeigen.
Yep, klassisch über apt update
@thomas-braun sagte in Redis in ioBroker - Überblick:
Du solltest kein schnubbibuntu-Repo einfach in dein Debian klatschen. Das passt nicht.
Schmeiß den Sums wieder raus und verwende das offizielle Redis-Repo vom Hersteller.
(Oder vielleicht am Besten da gar nix fummeln und einfach die Version aus dem hauseigenen Repo nehmen).https://forum.iobroker.net/topic/59231/phantastische-repositories-und-wo-sie-zu-finden-sind
Noch am Rande die Info, das redis nicht mehr als OpenSource-Sorftware eingestuft wird. Kann in Zukunft zu Problemen führen. Ich würde heute jedenfalls nicht mehr darauf setzen.
Danke für den Tipp :grimacing: ich habe die Schnubbibuntu Repo wie in der Aleitung eingefügt... mehr nicht. Im Gegenteil, anstattan den sources zu "fummeln" hab ich se mal aufgeräumt, weil Debian jedesmal nen neuen List Eintrag generiert hat.
Ich dachte die Offizielle Version ist zu alt?
Also einfach über apt installieren.. okay ;-) -
@thomas-braun sagte in Redis in ioBroker - Überblick:
@tschinkes sagte in Redis in ioBroker - Überblick:
sudo apt update
sagt?
user@iobroker:~# apt update OK:1 http://ftp.debian.org/debian bullseye InRelease OK:2 http://ftp.debian.org/debian bullseye-updates InRelease OK:3 http://security.debian.org bullseye-security InRelease Ign:4 http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular InRelease Fehl:5 http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release 404 Not Found [IP: 185.125.190.80 80] Holen:6 https://deb.nodesource.com/node_16.x bullseye InRelease [4.586 B] Paketlisten werden gelesen… Fertig E: Das Depot »http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release« enthält keine Release-Datei. N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert. N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).@thomas-braun sagte in Redis in ioBroker - Überblick:
apt policy redissagt?
user@iobroker:~# apt policy redis redis: Installiert: 5:6.0.16-1+deb11u2 Installationskandidat: 5:6.0.16-1+deb11u2 Versionstabelle: *** 5:6.0.16-1+deb11u2 500 500 http://ftp.debian.org/debian bullseye/main amd64 Packages 500 http://security.debian.org bullseye-security/main amd64 Packages 100 /var/lib/dpkg/statusIch werde mal deine Repo ausprobieren ;-) und die andere mal raus löschen
-
@thomas-braun sagte in Redis in ioBroker - Überblick:
@tschinkes sagte in Redis in ioBroker - Überblick:
sudo apt update
sagt?
user@iobroker:~# apt update OK:1 http://ftp.debian.org/debian bullseye InRelease OK:2 http://ftp.debian.org/debian bullseye-updates InRelease OK:3 http://security.debian.org bullseye-security InRelease Ign:4 http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular InRelease Fehl:5 http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release 404 Not Found [IP: 185.125.190.80 80] Holen:6 https://deb.nodesource.com/node_16.x bullseye InRelease [4.586 B] Paketlisten werden gelesen… Fertig E: Das Depot »http://ppa.launchpad.net/chris-lea/redis-server/ubuntu oracular Release« enthält keine Release-Datei. N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert. N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).@thomas-braun sagte in Redis in ioBroker - Überblick:
apt policy redissagt?
user@iobroker:~# apt policy redis redis: Installiert: 5:6.0.16-1+deb11u2 Installationskandidat: 5:6.0.16-1+deb11u2 Versionstabelle: *** 5:6.0.16-1+deb11u2 500 500 http://ftp.debian.org/debian bullseye/main amd64 Packages 500 http://security.debian.org bullseye-security/main amd64 Packages 100 /var/lib/dpkg/statusIch werde mal deine Repo ausprobieren ;-) und die andere mal raus löschen
Und hampel da NICHT als root herum. Auch wenn du den Eintrag versuchst zu verstecken...
-
Und hampel da NICHT als root herum. Auch wenn du den Eintrag versuchst zu verstecken...
ich habs nur fürs Forum geändert aber egal, ist eh lokal aufm Proxmox, ich denke ich kann einschätzen das ich als root (mit ssh key und zugewiesener IP) da schon sicher bin :-) dennoch, danke für den Tipp mit den Repos, mit deinem hats funktioniert.
-
ich habs nur fürs Forum geändert aber egal, ist eh lokal aufm Proxmox, ich denke ich kann einschätzen das ich als root (mit ssh key und zugewiesener IP) da schon sicher bin :-) dennoch, danke für den Tipp mit den Repos, mit deinem hats funktioniert.
@tschinkes sagte in Redis in ioBroker - Überblick:
ich habs nur fürs Forum geändert aber egal, ist eh lokal aufm Proxmox,
Nein, ist auch in einem Container nicht egal.
277
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge