Neues YouTube-Video: Visualisierung im Devices-Adapter

[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

[amg_666]

@homoran JA, 1:30 Homematic Backup und 2:00 Uhr iobroker Systembackup

[Homoran]

@amg_666 sagte in iobroker nach Neustart "tot":

siehe Screenshot, freies RAM 34%

traue diesem Wert mal nicht zu sehr.

top oder htop auf der Konsole sind da viel genauer, auch wenn das auch nur eine Momentaufnahme ist und ein scheduled Adapter erst RAM braucht, wenn er gestartet wird. Insbesondere backitup braucht da seeeehr viel

@amg_666 sagte in iobroker nach Neustart "tot":

Kann es evtl auch an irgendwelchen Skripten liegen, die unsauber sind und deshalb das System "zufahren" ?

Klar:

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

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

[Homoran]

@amg_666 sagte in iobroker nach Neustart "tot":

1:30 Homematic Backup

das ist klein. -> kein Schaden

@amg_666 sagte in iobroker nach Neustart "tot":

2:00 Uhr iobroker Systembackup

Zeitpunkt des ersten OOM (Out Of Memory)

[amg_666]

@thomas-braun "Und die Systeme würde ich auch alle auf den letzten Stand bringen."
???
js-controller 3.2.16
node-js 12.20.1
npm 6.14.10
auf allen 3 Raspi

radar nervt nur rum weil ich hier momentan Probleme mit bluetooth habe bzw auch das wlan manchmal etwas wacklig ist, ich kann den ja sonst auch auf loglevel error setzen (?)

[Thomas Braun]

@amg_666
Ich spreche da vom Betriebssystem, nicht vom ioBroker.
90% der Einträge im syslog stammen vom radar2, bzw. den Programmen, die der da ranzieht.

[amg_666]

@homoran ok, das passt genau auf das eingestellte backup (täglich um 2 Uhr).
Eine schnelle Abhilfe wäre noch einfach noch ein System reinzuhängen (hab noch ein paar Raspi hier rumzuliegen) und dann ein paar Adapter auszulagern.

"top" spricht so garnicht zu mir :-( aber ja vielleicht zu euch?

pi@iomaster:~ $ top
top - 18:46:14 up  1:50,  1 user,  load average: 1,03, 1,31, 1,16
Tasks: 118 total,   2 running, 116 sleeping,   0 stopped,   0 zombie
%Cpu(s): 29,9 us,  4,6 sy,  0,0 ni, 63,8 id,  0,0 wa,  0,0 hi,  1,8 si,  0,0 st
MiB Mem :    925,9 total,    149,7 free,    639,0 used,    137,2 buff/cache
MiB Swap:      0,0 total,      0,0 free,      0,0 used.    268,3 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1439 iobroker  20   0  194160 108044  27804 R  88,1  11,4  12:44.98 node
 1571 iobroker  20   0  169372  81972  27168 S  33,1   8,6   4:40.14 node
 1521 iobroker  20   0  204276 118556  27392 S  14,2  12,5   2:48.56 node
 1549 iobroker  20   0  161132  73924  27472 S   3,3   7,8   0:54.11 node
 3103 iobroker  20   0  137236  50192  27640 S   1,3   5,3   0:07.35 node
 3298 pi        20   0    7792   2856   2412 R   1,0   0,3   0:00.13 top
   60 root      20   0       0      0      0 S   0,7   0,0   0:00.67 kswapd0
 1493 iobroker  20   0  150940  54244  27256 S   0,7   5,7   0:16.20 node
 1620 iobroker  20   0  147528  57020  27580 S   0,7   6,0   0:11.16 node
  373 root      20   0   27656     80      0 S   0,3   0,0   0:08.60 rngd
 1560 iobroker  20   0  133172  42988  27332 S   0,3   4,5   0:06.34 node
 1765 root      20   0       0      0      0 I   0,3   0,0   0:00.16 kworker/1:3-events
    1 root      20   0   33696   7948   6388 S   0,0   0,8   0:05.84 systemd
    2 root      20   0       0      0      0 S   0,0   0,0   0:00.02 kthreadd
    3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_gp
    4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rcu_par_gp
    8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mm_percpu_wq
    9 root      20   0       0      0      0 S   0,0   0,0   0:22.65 ksoftirqd/0
   10 root      20   0       0      0      0 I   0,0   0,0   0:02.69 rcu_sched
   11 root      rt   0       0      0      0 S   0,0   0,0   0:00.03 migration/0
   12 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/0
   13 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/1
   14 root      rt   0       0      0      0 S   0,0   0,0   0:00.02 migration/1
   15 root      20   0       0      0      0 S   0,0   0,0   0:00.91 ksoftirqd/1
   18 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/2
   19 root      rt   0       0      0      0 S   0,0   0,0   0:00.02 migration/2
   20 root      20   0       0      0      0 S   0,0   0,0   0:00.34 ksoftirqd/2
   23 root      20   0       0      0      0 S   0,0   0,0   0:00.00 cpuhp/3
   24 root      rt   0       0      0      0 S   0,0   0,0   0:00.03 migration/3
   25 root      20   0       0      0      0 S   0,0   0,0   0:00.22 ksoftirqd/3
   28 root      20   0       0      0      0 S   0,0   0,0   0:00.01 kdevtmpfs
   29 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 netns
   32 root      20   0       0      0      0 S   0,0   0,0   0:00.00 khungtaskd
   33 root      20   0       0      0      0 S   0,0   0,0   0:00.00 oom_reaper
   34 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 writeback
   35 root      20   0       0      0      0 S   0,0   0,0   0:00.00 kcompactd0
   52 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 kblockd
   53 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 blkcg_punt_bio
   54 root      rt   0       0      0      0 S   0,0   0,0   0:00.00 watchdogd
   57 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 rpciod
   58 root       0 -20       0      0      0 I   0,0   0,0   0:00.06 kworker/u9:0-hci0
   59 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 xprtiod
   61 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 nfsiod
   62 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 iscsi_eh
   63 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 dwc_otg
   64 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 DWC Notificatio
   66 root       1 -19       0      0      0 S   0,0   0,0   0:00.01 vchiq-slot/0
   67 root       1 -19       0      0      0 S   0,0   0,0   0:00.00 vchiq-recy/0
   68 root       0 -20       0      0      0 S   0,0   0,0   0:00.00 vchiq-sync/0
   69 root      20   0       0      0      0 S   0,0   0,0   0:00.00 vchiq-keep/0
   70 root      10 -10       0      0      0 S   0,0   0,0   0:00.00 SMIO
   73 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 mmc_complete
   74 root       0 -20       0      0      0 I   0,0   0,0   0:00.60 kworker/1:1H-kblockd
   76 root       0 -20       0      0      0 I   0,0   0,0   0:00.40 kworker/3:1H-kblockd
   78 root      20   0       0      0      0 S   0,0   0,0   0:00.39 jbd2/mmcblk0p2-
   79 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 ext4-rsv-conver

[Homoran]

@amg_666 sagte in iobroker nach Neustart "tot":

MiB Swap: 0,0 total, 0,0 free, 0,0 used.

das erklärt auch, warum er nicht geswapped hat!

Warum hast du das SWAP deaktiviert?

@amg_666 sagte in iobroker nach Neustart "tot":

MiB Mem : 925,9 total, 149,7 free,

das sieht schon anders aus, als das was in den Instanzen steht

hier werden die namen der Übeltäter nicht (mehr) angezeigt, nimm mal htop