UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Dr. Bakterius]

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]

@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 ls

raus. Aber ich bin, was QNAP angeht, völlig ahnungslos und weiß nicht, wie das unter der Haube verdrahtet ist.

[Marc Berg]

@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 10000

Auß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.

[peterfido]

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.tankerkoenig

Die 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)

[Ro75]

@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.

[Wildbill]

@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]

@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.

[Ro75]

@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]

@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.

[tschinkes]

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.

[Thomas Braun]

@tschinkes

Wie genau bist du da unterwegs?

sudo apt update

zeigen.
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.

[tschinkes]

@thomas-braun sagte in Redis in ioBroker - Überblick:

@tschinkes

Wie genau bist du da unterwegs?

sudo apt update

zeigen.

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]

@tschinkes sagte in Redis in ioBroker - Überblick:

sudo apt update

sagt?

apt policy redis

sagt?

[tschinkes]

@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 redis

sagt?

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/status

Ich werde mal deine Repo ausprobieren ;-) und die andere mal raus löschen

[Thomas Braun]

@tschinkes

Und hampel da NICHT als root herum. Auch wenn du den Eintrag versuchst zu verstecken...

[tschinkes]

@thomas-braun

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.

[Thomas Braun]

@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.

[tschinkes]

@thomas-braun sagte in Redis in ioBroker - Überblick:

@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.

Du hast recht, ist es nicht! :-)

[Ein ehemaliger Benutzer]

@tschinkes sagte in Redis in ioBroker - Überblick:

@thomas-braun

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.

Mein Lieber.... du bist dir da sicher, dass du mit Sicherheit Mist machst.
Aber sowas hier, noch die Community veräppeln indem man den Eintrag fuers Forum aendert..
dabei sieht man an den Fehlermeldungen, dass du mit Root das eingegeben hättest, sonst wäre die Ausgabe eine ganz andere..

Standrechtlich erschossen, gefedert und geteert, und gesteinigt.. ok.. an der Reihenfolge kann man arbeiten.. :)

[apollon77]

Das Problem ist ein anderes ... Das Repo von chris-lea is deprecated weil es jetzt ein offizielles gibt (zumindestens noch). Die neueren Versionen gibts nur im aktuelles Repo.

deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb jammy main

Man muss aber die Keys importieren ... hab ich grad nicht mehr parat

Danach (braucht man ab Redis 7) noch in der redis config ein

user default on nopass sanitize-payload ~* &* +@AlLaut2024
acl-pubsub-default allchannels

rein