Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Thomas Braun]

@philipp-dorn

|Arbeitsspeicher:| 1GB |
Unify-Server

Und da quetscht du auch noch neben den iobroker noch weiteren Kram? Das ist ohnehin schon knapp bemessen mit dem einen GB.

[Philipp Dorn]

@thomas-braun Ja, grundsätzlich richtig, allerdings in der RAM übersicht war es nie so, dass ich da in einen kritischen Bereich kam....

Hat ja auch wirklich mittlerweile Jahre funktioniert....

pi@homeserver:~ $ free
              total        used        free      shared  buff/cache   available
Mem:         996100      620888      100256        1740      274956      345296
Swap:       1023996      209664      814332

[Thomas Braun]

@philipp-dorn

Der Speicherbedarf ist in den letzten Versionen des iobrokers aber auch gestiegen. Was 'vor Jahren' ging muss heute nicht unbedingt noch passen.
Ich vermute, dass der Kiste der Spielraum ausgeht. Vielleicht beim nächtlichen Backup.

[Thomas Braun]

@philipp-dorn

free -ht --mega

Kann Mensch besser lesen.

[Philipp Dorn]

@thomas-braun Backup mache ich manuell, also beim Backup kanns nicht sein...

Also empfiehlst du nen Raspi4? Ich habe eh schon seit längerem Überlegt ein kubernetes Cluster aus zwei Raspis 4 zu erstellen und alles dadrin zu hosten. Von der Leistung her, müsste der Raspi 4 das ja locker schaffen.

pi@homeserver:~ $ free -ht --mega
              total        used        free      shared  buff/cache   available
Mem:           972M        329M        535M        0.0K        107M        596M
Swap:          999M        331M        668M
Total:         2.0G        661M        1.2G

[Thomas Braun]

@philipp-dorn

Ich empfehle mehr RAM als 1GB. Ob das jetzt ein Raspberry ist oder was anderes ist egal.

Edith: Dein Swap ist komisch...

[Philipp Dorn]

@thomas-braun Pro Node oder pro Cluster? Ich könnte natürlich (aufgrund der aktuell nicht bekommbaren Raspis 4 einen zweiten 3er als Node hinzufügen. Dann wäre es mehr Ram. Zukunfsträchtig ist es aber nicht auch nicht sehr lange.

[Philipp Dorn]

@thomas-braun said in broker mit und ohne Fehlermeldung nicht erreichbar:

Edith: Dein Swap ist komisch...

Definiere komisch? :grimacing:

[Thomas Braun]

@philipp-dorn

Komisch groß, komisch zu voll.
Du hast ein Problem mit zu wenig RAM.

Mein System:

echad@chet:~ $ free -ht --mega
               total        used        free      shared  buff/cache   available
Mem:            7.8G        2.1G        2.6G        0.0K        3.2G        5.6G
Swap:            99M          0B         99M
Total:          7.9G        2.1G        2.7G

[Philipp Dorn]

@thomas-braun Okay, das stimmt scheinbar. Aber ist nicht genau dafür eigentlich der Swap da, damit eben mein System nicht abschmiert?

Ich schaue mich nach einem Raspi 4 um, lege ein Kubernetes-Cluster an und werde da Unify und iobroker als Container laufen lassen. Gibts Erfahrungen mit iobroker als Container?

[Thomas Braun]

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

Aber ist nicht genau dafür eigentlich der Swap da, damit eben mein System nicht abschmiert?

Jein. Swap ist der Notüberlauf, wenn der in letzter Verzweiflung genutzt werden muss ist aber schon das System übervoll. Wenn swap dann auch ausgereizt ist geht gar nix mehr und der Sensenmann (oom-reaper) senst sich im Selbsterhaltungstrieb durch das System und säbelt Prozesse weg.

Gibts Erfahrungen mit iobroker als Container?

Bin ich kein Freund von. Geht aber prinzipiell.

[Philipp Dorn]

@thomas-braun Was merkwürdig ist, dass ich jetzt nicht wirklich einen Prozess sehe, der den RAM so überbügelt.....

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND

11539 iobroker  20   0  448804 257160  18696 R  87.6  25.8   2:09.13 iobroker.js-con
11650 iobroker  20   0  157188  35892  18896 S  10.7   3.6   0:03.22 node
11686 iobroker  20   0  157368  36044  18836 S   9.7   3.6   0:03.22 node
11721 iobroker  20   0  156884  32808  18852 S   9.1   3.3   0:03.28 node
  888 unifi     20   0 1331416  83620   5316 S   7.7   8.4   3:32.63 java
11735 iobroker  20   0  158436  34288  18872 S   6.7   3.4   0:03.64 node
11581 iobroker  20   0  283308 134608  18808 S   5.4  13.5   0:16.93 io.admin.0
 1603 root       0 -20       0      0      0 I   2.0   0.0   0:15.72 kworker/0:0H-mmc_complete
11637 iobroker  20   0  161692  40252  18816 S   2.0   4.0   0:03.77 node
11644 iobroker  20   0  159292  38160  18840 S   2.0   3.8   0:03.07 node
11652 iobroker  20   0  158996  37652  18832 S   2.0   3.8   0:02.99 node
11664 iobroker  20   0  162184  41088  18788 S   2.0   4.1   0:04.21 node
11693 iobroker  20   0  158176  34932  18872 S   2.0   3.5   0:03.46 node
11694 iobroker  20   0  157188  31384  18788 S   2.0   3.2   0:03.39 node
11707 iobroker  20   0  160080  37724  18864 S   2.0   3.8   0:03.31 node
11671 iobroker  20   0  163256  42456  18812 S   1.7   4.3   0:03.73 node
11674 iobroker  20   0  161232  39296  18788 S   1.7   3.9   0:03.69 node
11709 iobroker  20   0  162424  41336  18940 S   1.7   4.1   0:04.00 node
   92 root      20   0       0      0      0 I   1.3   0.0   0:09.39 kworker/u8:1-events_unbound
11614 iobroker  20   0  161008  22716  18192 S   1.3   2.3   0:03.77 node
11120 root      20   0       0      0      0 I   1.0   0.0   0:00.90 kworker/0:1-events
   11 root      20   0       0      0      0 S   0.7   0.0   0:04.76 ksoftirqd/0
   84 root       0 -20       0      0      0 I   0.7   0.0   0:08.16 kworker/1:1H-kblockd
 1032 unifi     20   0 1367868  10592   7640 R   0.7   1.1   0:48.04 mongod
 6517 root       0 -20       0      0      0 I   0.7   0.0   0:04.10 kworker/2:0H-kblockd
11598 iobroker  20   0  157976  22176  18388 S   0.7   2.2   0:03.25 node
11631 pi        20   0   10340   2008   1580 R   0.7   0.2   0:00.49 top
  610 root      20   0  917012   4288   1404 S   0.3   0.4   0:06.70 containerd
 4630 pi        20   0   12204   1740   1588 S   0.3   0.2   0:00.16 sshd
 9536 root       0 -20       0      0      0 I   0.3   0.0   0:00.89 kworker/3:2H-kblockd
11795 root      20   0       0      0      0 I   0.3   0.0   0:00.02 kworker/2:0-mm_percpu_wq
    1 root      20   0   34780   2364   1968 S   0.0   0.2   0:10.30 systemd
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.07 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:00.00 rcu_tasks_rude_
   10 root      20   0       0      0      0 S   0.0   0.0   0:00.00 rcu_tasks_trace
   12 root      20   0       0      0      0 I   0.0   0.0   0:05.06 rcu_sched
   13 root      rt   0       0      0      0 S   0.0   0.0   0:00.08 migration/0
   14 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0
   15 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/1
   16 root      rt   0       0      0      0 S   0.0   0.0   0:00.04 migration/1
   17 root      20   0       0      0      0 S   0.0   0.0   0:01.89 ksoftirqd/1
   20 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/2
   21 root      rt   0       0      0      0 S   0.0   0.0   0:00.10 migration/2
   22 root      20   0       0      0      0 S   0.0   0.0   0:01.96 ksoftirqd/2
   25 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/3
   26 root      rt   0       0      0      0 S   0.0   0.0   0:00.07 migration/3
   27 root      20   0       0      0      0 S   0.0   0.0   0:01.97 ksoftirqd/3
   30 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kdevtmpfs
   31 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 netns
   34 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kauditd
   36 root      20   0       0      0      0 S   0.0   0.0   0:00.00 khungtaskd
   37 root      20   0       0      0      0 S   0.0   0.0   0:00.00 oom_reaper
   38 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 writeback
   39 root      20   0       0      0      0 S   0.0   0.0   0:10.13 kcompactd0
   57 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kblockd
   58 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 blkcg_punt_bio
   59 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 watchdogd
   62 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rpciod
   63 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/u9:0-hci0
   64 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 xprtiod
   65 root      20   0       0      0      0 S   0.0   0.0   0:44.73 kswapd0
   66 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 nfsiod
   69 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 iscsi_eh
   70 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 iscsi_destroy
   71 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 dwc_otg
   73 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 DWC Notificatio
   75 root       1 -19       0      0      0 S   0.0   0.0   0:00.00 vchiq-slot/0

Wenn ich das so eine Zeit überwache, ist das Maximum der Gefühle ca. 700MB in Use (aber auch nur mal kurzer Peak, ansonsten so ca. 250MB). Warum belegt er dann den Swap?

[Thomas Braun]

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

11539 iobroker  20   0  448804 257160  18696 R  87.6  25.8   2:09.13 iobroker.js-controller

Der liegt schon schwer auf dem System.

[Philipp Dorn]

@thomas-braun Kriegt man den irgendwie kleiner? Ich mein die Komponente ist ja leider unabdingbar...

Jetzt wirds richtig spannend. Habe Unify runtergschmissen und übergangsweise auf meinem Rechner in ne VM geklatscht.
Nun wollte ich iobroker restoren und siehe da, ich habe scheinbar wirklich ein RAM Problem:

pi@homeserver:/opt/iobroker $ sudo iobroker restore 0
host.homeserver Using backup file 2021_11_12-15_25_55_backupiobroker.tar.gz
iobroker controller daemon is not running
host.homeserver OK.
host.homeserver Clear all objects and states...
clean 64689 objects...
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object 0_userdata.0: {"command":{"name":"del","args":["cfg.o.0_userdata.0"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object alias.0: {"command":{"name":"del","args":["cfg.o.alias.0"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object enum.functions: {"command":{"name":"del","args":["cfg.o.enum.functions"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object enum.rooms: {"command":{"name":"del","args":["cfg.o.enum.rooms"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object system.config: {"command":{"name":"del","args":["cfg.o.system.config"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable
[Not critical] Cannot delete object system.repositories: {"command":{"name":"del","args":["cfg.o.system.repositories"]}}
Server Objects 127.0.0.1:55064 Error from InMemDB: Error: Object is marked as non deletable

<--- Last few GCs --->

[791:0x5112b40]    69536 ms: Scavenge 182.0 (194.8) -> 181.8 (196.3) MB, 13.0 / 0.0 ms  (average mu = 0.916, current mu = 0.702) allocation failure
[791:0x5112b40]    69577 ms: Scavenge 183.4 (196.3) -> 183.4 (196.8) MB, 11.4 / 0.0 ms  (average mu = 0.916, current mu = 0.702) allocation failure
[791:0x5112b40]    69598 ms: Scavenge 183.7 (196.8) -> 183.5 (198.3) MB, 13.1 / 0.0 ms  (average mu = 0.916, current mu = 0.702) allocation failure


<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
/usr/bin/iobroker: line 8:   790 Aborted                 sudo -H -u iobroker node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js "$@"

[Thomas Braun]

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

sudo iobroker restore 0

Kannst du mir mal sagen wo immer der Quatsch mit dem sudo an der Stelle herkommt?

iobroker wird NICHT per sudo angepackt.

iobroker stop
iobroker fix
iobroker start

[Philipp Dorn]

@thomas-braun Ja, ich führe alles ohne Sudo aus, nur beim restore habe ich in diesem Forum mit Sudo gelernt, siehe:

https://forum.iobroker.net/topic/6181/backup-und-restore-richtig-korrektes-vorgehen/2

EDIT: Erstes Suchergebnis, wenn du Restore iobroker googlest, also sollte der Beitrag mal geändert werden, denn Homoran ist ja schließlich jemand mit Ahnung...

EDIT2: Ohne Sudo gehts....sorry, aber man soll ja immer brav die Suche hier verwenden, und da kommt nunmal direkt Rainers Post an erster Stelle...

[Thomas Braun]

@philipp-dorn

Der Eintrag ist aber auch von 02/2018.
Steht das in der offiziellen, aktuellen Doku auch so drin?

[Homoran]

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

siehe:

Ja - vor 4 Jahren war das noch so

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

also sollte der Beitrag mal geändert werden, denn Homoran ist ja schließlich jemand mit Ahnung.

• und der soll ale 14 Tage seine 35.000 Posts durchsuchen, ob es da inzwischen Änderungen gibt?
• und dann ändern?
• und dann damit den damaligen Zusammenhang im Thread zerstören?

[Philipp Dorn]

@homoran @Thomas-Braun

Ich will hier ja niemanden angreifen - es wurde nur gefragt woher das mit sudo beim restore immer kommt...

Und ja, ich gebe zu, wenn ich eine Lösung oder etwas suche, suche ich ja nicht noch mehrere andere Posts als Quelle um zu schauen, dass sich mittlerweile nichts mehr geändert hat, vor allem, wenn Google und das Forum selbst den gleichen Beitrag als erstes rausploppen lassen....

[Homoran]

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

enn ich eine Lösung oder etwas suche, suche ich ja nicht noch mehrere andere Posts als Quelle um zu schauen, dass sich mittlerweile nichts mehr geändert hat,

aber ein Datum von 2018 sollte bei etwas so kurzlebigem wie aktueller Software schon stutzig machen

@philipp-dorn sagte in broker mit und ohne Fehlermeldung nicht erreichbar:

wenn Google und das Forum

da sollte man eher mal in der Doku nachsehen, auch wenn die zugegebenermaßen auch nicht überall aktuell ist. Allerdings würde die Doku dann (wenn du das meldest) schnellstmöglich aktualisiert. Da wird ja dadurch nichts mehr aus dem Zusammenhang gerissen