IoBroker Neustarts, Erreichbarkeit, Aktualisierung

[Homoran]

iobroker del AdapterName

[mic62]

Ja, das habe ich in PuTTY schon probiert. Dauert 5-10 Minuten und bricht dann ab.

[Homoran]

dann tipp mal TOP ein

und poste die Kopfzeilen

mit STRG-C kommst du da wieder raus

[mic62]

Hab den Pi jetzt stromlos gemacht weil er nach 10 Minuten immer noch nicht erreichbar war und gleich nach dem Neustart nochmal den freien Speicher abgefragt:

pi@ioBroker-RasPi:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         949448      267804      535692       12264      145952      619076
Swap:             0           0           0

pi@ioBroker-RasPi:~ $ df
Dateisystem    1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/root       15046340 2606152  11797384   19% /
devtmpfs          470116       0    470116    0% /dev
tmpfs             474724       0    474724    0% /dev/shm
tmpfs             474724   12256    462468    3% /run
tmpfs               5120       4      5116    1% /run/lock
tmpfs             474724       0    474724    0% /sys/fs/cgroup
/dev/mmcblk0p1     42131   22541     19590   54% /boot
tmpfs              94944       0     94944    0% /run/user/1000

Danach sofort im Admin-GUI erneut versucht einen Adapter zu löschen. Das hat für HM-Rega, HM-RPC und TVSpielfilm (den drei Adaptern mit denen ich es vorher erfolglos versucht habe) nun auch geklappt.

TOP ergibt folgendes:

pi@ioBroker-RasPi:/opt/iobroker $ top
top - 18:03:34 up 13 min,  1 user,  load average: 0,81, 1,22, 0,82
Tasks: 125 total,   1 running,  80 sleeping,   0 stopped,   0 zombie
%Cpu(s):  4,5 us,  0,7 sy,  0,0 ni, 94,6 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
KiB Mem :   949448 total,   178844 free,   700288 used,    70316 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   187228 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  606 root      20   0  165688  57280   7196 S   5,6  6,0   1:16.35 iobroker.js-con
  948 root      20   0  138716  39340   5008 S   3,3  4,1   0:12.71 io.tr-064.1
  872 root      20   0  128988  31024   4516 S   3,0  3,3   0:21.35 io.ble.0
  958 root      20   0  136452  37512   3992 S   2,0  4,0   0:26.10 io.upnp.0
  511 redis     20   0   34184   2092    552 S   1,3  0,2   0:09.98 redis-server
  782 root      20   0  158192  57248   4356 S   1,3  6,0   0:15.98 io.javascript.0
 1063 root      20   0  128448  18960   5580 S   1,3  2,0   0:02.22 io.text2command
 1878 pi        20   0    8512   3216   2736 R   1,3  0,3   0:00.40 top
  665 root      20   0  129256  18156   4624 S   0,7  1,9   0:02.66 io.socketio.0
 1008 root      20   0  133096  20228   4564 S   0,7  2,1   0:05.06 io.iot.0
    8 root      20   0       0      0      0 I   0,3  0,0   0:00.91 rcu_sched
  145 root      20   0       0      0      0 I   0,3  0,0   0:00.88 kworker/u8:2
  322 avahi     20   0    6404    728    372 S   0,3  0,1   0:01.79 avahi-daemon
  593 root       0 -20       0      0      0 I   0,3  0,0   0:00.85 kworker/u9:2
  745 pi        20   0   11664   1616    868 S   0,3  0,2   0:00.05 sshd
  792 root      20   0  148148  38944   5496 S   0,3  4,1   0:13.95 io.admin.0
  832 root      20   0  127200  17192   5072 S   0,3  1,8   0:04.37 io.kodi.0
  862 root      20   0  130464  30468   4072 S   0,3  3,2   0:02.93 io.fritzbox.0
    1 root      20   0   26928   2052    988 S   0,0  0,2   0:02.19 systemd
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd
    3 root      20   0       0      0      0 I   0,0  0,0   0:00.06 kworker/0:0
    4 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/0:0H
    5 root      20   0       0      0      0 I   0,0  0,0   0:00.42 kworker/u8:0
    6 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 mm_percpu_wq
    7 root      20   0       0      0      0 S   0,0  0,0   0:00.12 ksoftirqd/0
    9 root      20   0       0      0      0 I   0,0  0,0   0:00.00 rcu_bh
   10 root      rt   0       0      0      0 S   0,0  0,0   0:00.01 migration/0
   11 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/0

[apollon77]

Kannst mal versuchen ioBroker zu beenden und dann die Adapter zu löschen. Das sollte generell auch tun und dann solltest Du viel mehr Speicher haben.

Aktuell kannst Du bei einem nodejs Prozess mit 40MB+ Speicherverbrauch rechnen. Wenn nur ioBroker-Adapter laufen würden wären das also maximal 25. Der js-controller und dein System braucht auch noch etwas. Also musst Du drastisch reduzieren. Oder einen zweiten Raspi als Slave hinstellen wo Du dann verteilst (geht auch). Brauchst auf im ersten Schritt gar nicht löschen - deaktivieren der Instanzen sollte ausreichen.

Ingo

[apollon77]

Und ja bei für such Netzteil prüfen obwohl du ggf in /var/log/syslog was mit oom finden dürftest.

Gesendet vom Handy …

[mic62]

In /var/log/ finde ich nur die Unterverzeichnisse /apt, /redis und /samba wobei /redis in FileZilla mit einem Fragezeichen versehen und nicht einsehbar ist.

[eric2905]

Arbeite mal nicht mit FileZilla, sonder gehe per SSH auf den Host und schau in die Verzeichnisse.

Gruß,

Eric

Von unterwegs getippert

[mic62]

Hallo,

sorry, ich bin gesundheitlich gerade etwas angeschlagen und komme daher erst jetzt dazu mich wieder in der Angelegenheit zu melden.

Ich habe nun doch die syslog-Datei im Verzeichnis gefunden - auch mit FileZilla. Keine Ahnung warum ich am WE nicht fündig geworden bin.

Ich hänge die Datei mal hier an, da sind in der Tat eine Menge Einträge mit oom, aber das sagt mir leider nicht viel. Ich habe mitbekommen, dass diese Einträge wohl bei Speicherknappheit von einem "oom-killer" erzeugt werden.

Mir scheint aber, dass es keinen eindeutigen Verursacher gibt. Ich habe die oom-Einträge in Verbindung mit io.xxx gefunden, scheint also in der Tat, dass die Anzahl der Adapter Probleme macht. Wenn ich die installierten Adapter aber mittelfristig benötige, dann bleibt mir nur der Wechsel auf ein NUC mit mehr RAM?

Was mich bei all dem ein wenig wundert ist, dass ich meine ioBroker Mitte letzten Jahres mit nicht sehr viel weniger Adaptern auf einem Pi 2b laufen gehabt zu haben, ohne dass ich diese Probleme dort festgestellt hätte.
6039_syslog.log
6039_adapter1.jpg
6039_adapter2.jpg

[apollon77]

Na ok, oom-killer heisst Speicher ist knapp geworden.

Wieviele Instanzen laufen denn bei Dir?

Was läuft da noch so?

[mic62]

Die in meinem letzten Post angezeigten Adapter sind die mit Instanzen.

[apollon77]

Ok, ich habe 42 Instanzen gezählt? Korrekt? Und das ganze mit 1GB RAM von nem Raspi … lass mich mal Rechnen ...

Eine nodejs Instanz braucht 30-50MB ... also optimistisch gerechnet 30x42 = 1,26GB ... hm ... naja ... sagen wir es mal so ...

Ist ein bissl viel für deine RAM Ausstattung.

[mic62]

Ja, das sehe ich ein.

Ich habe das Swapping erst kürzlich deaktiviert, evtl. habe ich deshalb von der Speicherknappheit vorher nichts bemerkt.

Sehe ich das richtig, dass es im Prinzip folgende drei Alternativen gibt?

1. Swapping einschalten - Nachteil Micro-SD-Karten-Verschleiß

2. Umstellung auf NUC mit mehr RAM

3. Deaktivierung, bzw. Deinstallation von mindestens. 10 Adaptern/Instanzen

[Stabilostick]

4. Einen weiteren PI aus der Bastelkiste nehmen und ihn zur bestehenden Installation dazufügen. Dann 20 Adapter auf jeden. Zentrale Verwaltung über den vorhandenen Master-ioBroker. Ist easy.

Späßchen: Falls Du mutig bist, kannst die die Swap-Datei für 1) auch auf einen USB-Stick legen. Soll doch der kaputt gehen…

[mic62]

Hmm, an die vierte Lösung habe ich noch gar nicht gedacht. Habe das zwar schon mal gelesen, aber es nicht weiter verfolgt, weil ich es für mich als Linux-Laien zu kompliziert hielt. Muss mich dahingehend Mal schlau machen. Oder kannst Du mir ein leicht verständliches Tutorial empfehlen - am liebsten auf Deutsch, aber Englisch ginge auch.

[mic62]

Gemäss der Anleitung auf iobroker.net scheint es ja wirklich einfach zu sein.

http://www.iobroker.net/docu/?page_id=3068&lang=de

Gibt es bei so einem System irgendwelche Besonderheiten/Einschränkungen (außer der beschriebenen Verteilung der Adapter auf die Hosts) bei Installation von Adaptern/Instanzen oder im laufenden Betrieb?

Gibt es z.B. Probleme bei Anschluss von Peripherie (z.B. Zigbee- oder ZWave-USB-Stick) an einen der beiden Raspberries?

[Stabilostick]

Ja, die Anleitung liest sich so:

„Man gibt beim Master nur noch ein: sudo iobroker multihost enable

Anschließend auf dem slave: sudo iobroker multihost browse

Jetzt müssten vorhandene Master angezeigt werden.

Daraufhin wird mit sudo iobroker multihost connect der entsprechenden Master ausgewählt

Damit ist die Multihost-Verbindung fertig.“

Der Admin wird immer auf dem Master aufgerufen. Der neue Pi ist der Slave und Du kannst für jeden Adapter im Admin angeben, ob er auf dem Master oder Slave verschoben und dort laufen soll. Natürlich muss die für den Adapter jeweilig ggf. erforderliche HW (z.B. USB-Stick) an dem Raspberry angeschlossen werden, auf dem auch der zugehörige Adapter läuft.

Und die beiden Pi‘s müssen im gleichen Netzwerksubnetz sein. (z.B. 192.168.178.x)

[mic62]

Das hört sich gut an. Ich denke das werde ich erst mal probieren. Ist viel preiswerter als ein NUC - da ich den Rechner wirklich nur für ioBroker verwende.

Werde es erst mal mit einem Pi2B testen, den habe ich noch hier rumliegen. Wenn das spürbar Besserung bringt leiste ich mir evtl. einen zweiten 3B+ - wegen der Ausgewogenheit. Oder bringt das keine merklichen Vorteile?

[Stabilostick]

Ab 3 Pi‘s bist Du ggf. mit einem NUC oder einem anderen Einplatinenrechner mit >=2GB RAM günstiger. [emoji81]

[mic62]

Der 3B+ würde dann den 2b ersetzen, so dass das Multihostssstem aus zwei gleichen Pi's bestehen würde - wenn das denn Vorteile gegenüber einem gemischten System bringt.

Mehr als zwei Pi's sollen es nicht werden <emoji seq="1f609"></emoji>