Neues YouTube-Video: Visualisierung im Devices-Adapter

[Homoran]

@apollon77 erster oom-killer gum 02:00
ich nehme an, da läuft backitup

dann passend zu deiner Vorhersage:
Mar 19 11:03:36 iomaster kernel: [251223.920004] node invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

[apollon77]

@amg_666 Jupp ...

Mar 19 11:03:36 iomaster kernel: [251223.920004] node invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Mar 19 11:03:36 iomaster kernel: [251223.920872] Out of memory: Killed process 19776 (node) total-vm:231148kB, anon-rss:117040kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:562kB oom_score_adj:0

Mar 19 11:06:11 iomaster kernel: [251378.255863] Out of memory: Killed process 19629 (node) total-vm:282056kB, anon-rss:160004kB, file-rss:720kB, shmem-rss:0kB, UID:1001 pgtables:622kB oom_score_adj:0

[apollon77]

Also ich würde sagen: Wiederherstellen aus objects Backup und state backups und wenn es wieder läuft gleich mal mit "top" schauen was der RAM usage sagt
Ich denke 13 Instanzen sind für den RAM zuviel

[amg_666]

@apollon77 2 Fragen: 1. Wie genau stelle ich das wieder her? 2. wenn 13 Instanzen zuviel sind würde eine größere SD Karte Abhilfe schaffen, oder?

[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?