Neues YouTube-Video: Visualisierung im Devices-Adapter

[Homoran]

@amg_666 sagte in iobroker nach Neustart "tot":

wenn 13 Instanzen zuviel sind würde eine größere SD Karte Abhilfe schaffen, oder?

nein!

das RAM wahrscheinlichj hast du nur 1GB) reicht nicht

Es fehlt noch die Info wann genau du rebootet hattest

[amg_666]

@homoran Ja klar, Denkfehler von mir, die PIs haben 1GB... Reboot weiss ich nicht mehr, müsste aber so gegen 15:45 gewesen sein

[apollon77]

@amg_666 Jeder iobroker prozess hat sagen wir 50MB ... 13 Adapter plus controller ... 700MB allein dafür ... jetzt ist die Frage was noch drauf läuft ...

[Homoran]

@apollon77 sagte in iobroker nach Neustart "tot":

13 Adapter plus controller ..

aber die sind doch auf den 3 Hosts verteilt!

@amg_666
oder?

[amg_666]

@apollon77 Wie meisnt du das? Auf den PIs läuft "nur" iobroker (und vis edit und flot und auf einem Slave)

[amg_666]

@homoran Oh OH, ich hatte gesagt, dass es "locker" 13 Instanzen sind, hatte mir das irgendwann mal dokumentiert. Stimmt es sind 13 auf dem MASTER) plus nochmal 10 auf einem Slave, beim 2. Slave weiß ich es nicht mehr genau, auf dem läuft vis inkl diverser vis-ergänzungen

[Thomas Braun]

@apollon77 @amg_666
Da geht halt regelmäßig das RAM aus.
Da hilft nur mehr Hubraum.

[amg_666]

@thomas-braun @apollon77
Wie gehe ich denn jetzt weiter vor (unix dummy). "Wiederherstellen aus objects Backup und state backups "
Was genau muss ich da machen? Wenn ich das wieder zum rennen kriege, dann kann ich ja erstmal die Adapter auf ein "basic set" einkürzen und alles was nicht sooo wichtig ist stoppen.
Mehr Hubraum ist eine gute Idee aber den müsste ich mir erstmal besorgen...

[Thomas Braun]

@amg_666
Man kopiert eine funktionierende Datei zurück an den Platz wo die kaputte liegt. Wie das geht steht im Mini-HowTo drin.

https://forum.iobroker.net/topic/43325/mini-howto-cannot-find-view-system-for-search-host

[apollon77]

Ok, nochmal beide Logfiles zusammen gecheckt im "Problembereich":

• 15:40:12 wurde controller gekillt von OOM

• 15:40:32 restarted

• 15:46:xx 3 mal fehler das die bak nicht kopiert werden kein weil die .json nicht da ist. das kapiere ich nicht

• 15:48:37 nächster kill

• 15:48:54 restart (übrigens restart counter = 11 ...)

• 15:49:00 beim start: states.json broken, backup genutzt

• 15:50:47 objects.json bak kann nicht geschrieben werden weil .json nicht da ist (kapiere ich nicht)

• 15:52:01 nochmal gleiche meldung

• 15:52:15 Login und Reboot

• 15:53:32 Start nach Reboot, hat geklappt trotz defekter objects.json weil backup genommen
  ... alles kommt hoch

• 15:58:49 neuer oom kill
  und dann gibts oom kill loop

Aber schon heute nach um 2 Uhr gabs einen Fall wo die objects.json korrupt war. Es hat aber geklappt aus dem letzten backup zu lesen

also an sich alles ok aber ramist zu heftig

Schau das du drauf kommst, stoppe iobroker, disbale ein paar instanzen manuell per "iobroker stop ...." und schau das es dann wieder läuft. Und schau was den RAM frisst mit "top"

[apollon77]

@thomas-braun Daran liegts diesmal noch nicht mal weil er als Fallback scheinbar immer die ".bak" nehmen kann ... die scheint zu tun.

EDIT: DOCH !!!

Der Crash 2021-03-19 16:31:52.066 hat dann alles zerstört. Also dfoch backup File restoren

[apollon77]

@apollon77 Am Ende ging der OOM Loop ne ganze Weile gut aber dann

2021-03-19 16:31:52.312 - error: host.iomaster-Server Cannot load /opt/iobroker/iobroker-data/objects.json: /opt/iobroker/iobroker-data/objects.json: Unexpected end of JSON input. Try last Backup!
2021-03-19 16:31:52.315 - error: host.iomaster-Server Cannot load /opt/iobroker/iobroker-data/objects.json.bak: Database file /opt/iobroker/iobroker-data/objects.json.bak does not exists.. Continue with empty dataset!

Und damit wars schluss

[apollon77]

@thomas-braun Aber die Frage ist WARUM? :-) deswegen wa r ich bei ... iobroker stoppen und erstmal "top" schauen ohne das ioBroker läuft was da abgeht. Und dann kann man ja eine instanz nach der anderen weider einschalten. Irgendeine muss der RAM Fresser sein

[Thomas Braun]

@apollon77 Bin ich dabei. Wobei ich

htop

ja bevorzuge. Sort (F6) auf RAM usage setzen.
@amg_666 Schalt den radar2 Adapter dann als letzten dazu. Der versaut spammt das log file... :-)

Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.

[Homoran]

@apollon77 sagte in iobroker nach Neustart "tot":

Irgendeine muss der RAM Fresser sein

ich tippe um 02:00 auf backitup

@amg_666
passt das?

[Homoran]

@thomas-braun sagte in iobroker nach Neustart "tot":

Und die Systeme würde ich auch alle auf den letzten Stand bringen. Da scheint noch ein älterer Kernel zu laufen.

lohnt das noch, wenn jetzt der NUC kommt?

[Thomas Braun]

@homoran

Ich sage
io.javascript.0
schwappt über. Unsauberes skript vermutlich.

[Thomas Braun]

@homoran sagte in iobroker nach Neustart "tot":

lohnt das noch, wenn jetzt der NUC kommt?

Was für ein NUC? Ich hab nix bestellt!11!!1

Aber ein aktuelles System lohnt sich IMMER. :-)

[amg_666]

@thomas-braun @apollon77 @Homoran
Danke, danke, danke
mit dem MiniHowTo hab ich ihn wieder ans Laufen bekommen. Was ich jetzt (noch) nicht verstehe ist folgendes, siehe Screenshot, freies RAM 34% und auf meiner VIS habe ich auch über den rpi2 Adapter die relevanten Infos zu den 3 Raspis angezeigt, mir ist da noch nie groß was aufgefallen. Kann es evtl auch an irgendwelchen Skripten liegen, die unsauber sind und deshalb das System "zufahren" ? Ich werd in jedem Fall für mehr Systempower sorgen, aber die Momentaufnahme sieht doch garnicht so kritisch aus oder?
Dass der zigbee Adapter gelb ist liegt an Fehlermeldungen, dass er den Stick nicht findet, ich stöpsel jetzt aber am Raspi erstmal nicht rum, reicht mir für heute :-)

[Homoran]

@thomas-braun sagte in iobroker nach Neustart "tot":

Ich hab nix bestellt!11!!1

nix du!

@amg_666 braucht einen Kleinbus, keinen smart