Weihnachtsangebot 2025! 🎄

[init5]

@thomas-braun said in sql Instanz wird immer beendet:

@init5 sagte in sql Instanz wird immer beendet:

Das Ding läuft seit Jahren.

Dann ist es ja ein guter Zeitpunkt für eine General-Sanierung.
Ich würde dann aber noch ein paar Wochen abwarten, bis Raspberry OS 12 ' Bookworm' offiziell veröffentlicht wurde.

Wird das dann automatisch von iobroker empfohlen, oder sollte man nach dem release dann erst noch warten, bis entsprechende Anpassungen erfolgt sind?

[Thomas Braun]

@init5

ioBroker läuft auf 'Bookworm' ohne weiteres, weil ioBroker nur 'nodeJS' als Laufzeitumgebung braucht.
Hier z. B. mein derzeitiges System:

Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.1.21-v8+
    Architecture: arm64

Installation:           native
Kernel:                 aarch64
Userland:               arm64

[init5]

Ich habe mich nun endlich mal dazu durchgerungen, den ioBroker neu zu installieren. Also System einmal komplett platt gemacht, Raspian mit 64Bit drauf und ioBroker neu installiert. Leider hat das absolut nichts am Verhalten des SQL Adapters geändert. Irgendetwas sorgt um täglich um 2:02Uhr dafür, dass der SQL Adapter gestoppt und nicht mehr gestartet wird.

[Thomas Braun]

@init5

Dann schau zu dem Zeitpunkt in das journal.

[init5]

@thomas-braun Meinst du das Protokoll? Da stehen wieder nur die selben Einträge drin, wie schon vor der Neuinstallation.

2023-07-22 02:02:03.281 - info: host.IoT-raspi-iobroker-master instance "system.adapter.sql.0" disabled via .alive
2023-07-22 02:02:03.325 - info: host.IoT-raspi-iobroker-master "system.adapter.sql.0" disabled
2023-07-22 02:02:03.327 - info: host.IoT-raspi-iobroker-master stopInstance system.adapter.sql.0 (force=false, process=true)
2023-07-22 02:02:03.311 - info: sql.0 (1795) Adapter is disabled => stop
2023-07-22 02:02:03.366 - info: host.IoT-raspi-iobroker-master stopInstance system.adapter.sql.0 (force=false, process=true)
2023-07-22 02:02:03.369 - info: sql.0 (1795) Adapter is disabled => stop
2023-07-22 02:02:03.890 - info: sql.0 (1795) terminating
2023-07-22 02:02:03.892 - info: sql.0 (1795) Terminated (NO_ERROR): Without reason
2023-07-22 02:02:04.616 - info: host.IoT-raspi-iobroker-master instance system.adapter.sql.0 terminated with code 0 (NO_ERROR)
2023-07-22 02:02:04.617 - info: host.IoT-raspi-iobroker-master Do not restart adapter system.adapter.sql.0 because disabled or deleted

Der Zeit nach zu urteilen, habe ich noch immer den BackItUp Adapter im Verdacht. Ich vermute, der beendet alle laufenden Instanzen und vergisst dann den SQL wieder zu starten. Ich weiß aber nicht, was ich dagegen tun kann

[Thomas Braun]

@init5

Dann schalte den Backitup mal testhalber aus oder leg den auf eine andere Zeit. Wenn sql dann immer noch rumspinnt liegt es nicht am Backitup... :-)

[init5]

@thomas-braun ok, wie vermutet. Ich habe das Backup wie vorgeschlagen um 2h nach hinten versschoben und nun stürzt auch der SQL Adapter 2h später ab. Also scheinen sich die beiden bei mir einfach nicht zu vertragen. Leider will ich auf keinen der Beiden so wirklich verzichten :face_with_rolling_eyes:

[Supermicha]

Läuft deine SQL-Datenbank auch auf dem Raspi?
kann es sein, das sich die Datenbank beim Backup aufhängt wegen zuwenig RAM oder weil die Spannung zusammenbricht?

[init5]

@supermicha Das mit der Spannung kann ich mir nicht vorstellen. Der Raspi ist in meinem Verteilerschrank für TV und Netzwerk verbaut und hängt da an einem Meanwell Netzteil. Also kein billig Netzteil zum Handy laden. RAM könnte schon eher sein. Die SQL DB läuft mit auf dem Raspi. Dann werde ich die wohl umziehen müssen. Ich war davon ausgegangen, dass der Raspi4 mit 4GB das verkraftet.

[Thomas Braun]

@init5 sagte in sql Instanz wird immer beendet:

Ich war davon ausgegangen, dass der Raspi4 mit 4GB das verkraftet.

Kann man so generell nicht bewerten. Hängt halt vom jeweiligen Umfang der Installation ab.

[ticaki]

@init5

du könntest wohl auch dir den Speicher rum die Zeit herum in eine Datei schreiben lassen

nano /home/pi/getfree.sh

#!/bin/bash
i=180
while [ $i -ge 1 ]
do
  ((i--))
  /bin/free >> /home/pi/speicher.txt
  sleep 1
done

chmod 0770 /home/pi/getfree.sh

crontab -e

0 2 * * * /bin/free >> /home/pi/speicher.txt

// speichern 

Das sollte dir um 2 Uhr für 3 Minuten jede sekunde den freien Speicher in die Datei speicher.txt schreiben. Keine Ahnung ob man dafür sudo oder root braucht. Und will keine Mecker von Thomas bekommen das ich jemanden rum rooten lasse :)

EDIT: wenn du keinen Swap willst must das Skript so aussehen

#!/bin/bash
i=180
while [ $i -ge 1 ]
do
  ((i--))
  /bin/free | /bin/grep Mem: >> /home/pi/speicher.txt
  sleep 1
done

[Thomas Braun]

@ticaki

Warum sollte es root Rechte brauchen? free kann jeder aufrufen.

[ticaki]

@thomas-braun sagte in sql Instanz wird immer beendet:

@ticaki

Warum sollte es root Rechte brauchen? free kann jeder aufrufen.

Weiß ich nicht deshalb hab ichs geschrieben, und weil ich gerade mit free nicht klar komme. Das sagt 90% Auslastung davon 10% buffer/caches - htop sagt 50%... könnte ja an Rechten liegen. Ist aber auch nicht so wichtig.

[init5]

@ticaki Ich versuche es jetzt noch einmal im Guten. Ich habe ein paar nicht so wichtige Instanzen auf einen zweiten Host geschoben. Jetzt sind über 2GB RAM frei. Ich habe jetzt schon zweimal das Backup manuell gestartet und es lief ohne Fehler und ohne den SQL Adapter abzuschießen. Mal sehen wie es sich heute Nacht verhält. Wenn es dann wieder abschmiert, werde ich das Skript testen. Falls es am RAM liegt, muss die SQL DB eben doch auf die NAS umziehen :face_with_rolling_eyes:

Zwischendurch nochmal danke für euren super Support! Das erlebt man so nicht in vielen Foren.

[init5]

Es lag in der Tat am RAM. 800MB freier RAM reichten scheinbar nicht aus. Ich habe wie gesagt ein paar unkritische Instanzen auf einen anderen Host verschoben und jetzt scheint genug Luft zum atmen. Seit zwei Tagen läuft das System jetzt wieder fehlerfrei.
Danke für die Unterstützung!

[Thomas Braun]

@init5 sagte in [gelöst] sql Instanz wird immer beendet:

800MB freier RAM reichten scheinbar nicht aus.

Nicht für speicherhungrige Prozesse wie z. B. ein Backup.

[Supermicha]

Falls dein zweiter Host nicht auch ein Raspi ist, würde ich dir raten die Datenbank auch auf dem aufzusetzen. Je nachdem wie viele Datenpunkte du loggst kommt da schon einiges an Schreiblast zusammen, und eine SD- Karte ist ja immer ein bisschen anfälliger als eine SSD.

Zum Thema RAM. Meine ioBroker-Installation frisst auch gut 3 GB. Aber auch nur weil ich der VM nicht mehr gebe, sonst würde iob sich wohl noch mehr genehmigen...

[init5]

@supermicha Der Master ist ein Raspi4 mit 4GB und SSD, also keine SD. Der Slave ist nur ein Raspi3. Der existiert eigentlich nur, weil er für Zigbee zuständig ist und anders als der Master, mitten im Haus hängt.
Ich bin wie gesagt am überlegen, die DB auf eine NAS zu verlagern. Dann müsste nur noch der DB Client auf dem Raspi laufen. Der DB Server wäre ja dann die NAS. Das müsste doch theoretisch auch etwas Entlastung bringen.

[Supermicha]

Alles was nicht auf dem Raspi läuft wird mit Sicherheit Entlastung bringen. Ich habe einen SQL-Server in einem Container laufen, der verbraucht "nur" 250 MB RAM. und da sind noch einige DB's mehr drauf... also soviel isses nicht, aber Kleinvieh macht auch Mist.

Wenn das NAS leistungsfähig genug ist, wäre es vielleicht auch eine Option, ioBroker direkt auf dem NAS laufen zu lassen.
Falls das NAS noch nicht existiert, könntest du ja beim Kauf diese Anforderungen gleich berücksichtigen.
(Wobei ich persönlich kein Fan von diesen proprietären NAS-Systemen bin, ich selber habe einen Server mit Proxmox drauf und fahre damit seit Jahren sehr gut... ist aber nur meine persönliche Meinung)

[init5]

@supermicha Ich hatte es mal versucht einen ioBroker im Container laufen zu lassen. Allerdings hatte ich da ein paar Probleme. Ich glaube einige Ports gingen dann nicht. Ich habe im Hinterkopf, dass CoAP für Shelly dann nicht mehr ging. Kann mich aber auch täuschen. Das war auch sicher nur ein Anwenderproblem, aber ich bin damals an irgendetwas essenziellem gescheitert.