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

[paul53]

@miggedy sagte:

Hier nun mal ein aktueller Status von top

Eine CPU-Last von 128 % durch den JS-Controller ist viel zu hoch. Wie verändert sie sich, wenn alle Instanzen - außer admin.0 - deaktiviert werden ?

[miggedy]

Mache mich gerade an das "npm rebuild". Das bricht mit einem Fehler ab.

make: *** [bufferutil.target.mk:103: Release/obj.target/bufferutil/src/bufferutil.o] Error 1
make: Leaving directory '/opt/iobroker/node_modules/kodi-ws/node_modules/bufferutil/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:191:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Linux 4.19.75-v7l+
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /opt/iobroker/node_modules/kodi-ws/node_modules/bufferutil
gyp ERR! node -v v10.19.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! bufferutil@1.1.0 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the bufferutil@1.1.0 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/iobroker/.npm/_logs/2020-03-21T13_53_22_130Z-debug.log

Das genannte log file endet mit:

8190 info lifecycle bufferutil@1.1.0~install: bufferutil@1.1.0
8191 verbose lifecycle bufferutil@1.1.0~install: unsafe-perm in lifecycle true
8192 verbose lifecycle bufferutil@1.1.0~install: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/opt/iobroker/node_modules/kodi-ws/node_modules/bufferutil/node_modules/.bin:/opt/iobroker/node_modules/kodi-ws/node_modules/.bin:/opt/iobroker/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
8193 verbose lifecycle bufferutil@1.1.0~install: CWD: /opt/iobroker/node_modules/kodi-ws/node_modules/bufferutil
8194 silly lifecycle bufferutil@1.1.0~install: Args: [ '-c', 'node-gyp rebuild' ]
8195 silly lifecycle bufferutil@1.1.0~install: Returned: code: 1  signal: null
8196 info lifecycle bufferutil@1.1.0~install: Failed to exec install script
8197 verbose stack Error: bufferutil@1.1.0 install: `node-gyp rebuild`
8197 verbose stack Exit status 1
8197 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
8197 verbose stack     at EventEmitter.emit (events.js:198:13)
8197 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
8197 verbose stack     at ChildProcess.emit (events.js:198:13)
8197 verbose stack     at maybeClose (internal/child_process.js:982:16)
8197 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
8198 verbose pkgid bufferutil@1.1.0
8199 verbose cwd /opt/iobroker
8200 verbose Linux 4.19.75-v7l+
8201 verbose argv "/usr/bin/node" "/usr/bin/npm" "rebuild"
8202 verbose node v10.19.0
8203 verbose npm  v6.13.4
8204 error code ELIFECYCLE
8205 error errno 1
8206 error bufferutil@1.1.0 install: `node-gyp rebuild`
8206 error Exit status 1
8207 error Failed at the bufferutil@1.1.0 install script.
8207 error This is probably not a problem with npm. There is likely additional logging output above.
8208 verbose exit [ 1, true ]

Ist es richtig, dass ich das npm rebuild als "pi" user aufrufe oder sollte ich sudo machen oder es als "iobroker" user ausführen?

Nach dem tutorial bin ich damals übrigens vorgegangen: https://forum.iobroker.net/topic/22867/how-to-node-js-für-iobroker-richtig-updaten
Hatte also damals auch schon ein npm rebuild gemacht. Langsam zweifele ich aber an meiner Erinnerung, dass das damals alles sauber durchgelaufen ist. ;-)

[Homoran]

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

Nach dem tutorial

das gilt eben nur für einen Wechsel des major releases: z.B. 8.x -> 10.x, nicht innerhalb von 10.x

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

dass ich das npm rebuild als "pi" user aufrufe

ja!
https://forum.iobroker.net/topic/17109/wichtige-hinweise-bei-neueren-npm-versionen-und-sudo/1

[Thomas Braun]

@miggedy Bei dem mivacuum Adapter muss manuel noch canvas nachinstalliert werden. Siehe auch auf der git-Seite zum Adapter.

[miggedy]

Ich habe den Kodi Adapter mal gelöscht, da dieser beim npm rebuild ja Probleme gemacht hat. Danach war das npm rebuild auch erfolgreich. Dann ein "iobroker fix" hinterhergeschoben. Auch erfolgreich.
Geändert hat das allerdings nichts. CPU weiterhin so hoch und admin lädt weiterhin so langsam bis gar nicht.

@Thomas-Braun, das habe ich direkt mal gemacht und konnte nun ohne Probleme updaten. Danke.

[Homoran]

@miggedy dann mach bitte was @paul53 geschrieben hat:

@paul53 sagte in admin Seiten laden extrem langsam bis gar nicht:

Wie verändert sie sich, wenn alle Instanzen - außer admin.0 - deaktiviert werden ?

[miggedy]

Hab nach und nach immer mehr Instanzen raus genommen. Wie zu erwarten ging die load average immer etwas weiter runter, die admin Seiten laden aber noch immer recht langsam (schneller, aber noch immer ca. 1 Minute).
So sah das ganze am Ende in top aus (mit nur admin instanz noch am laufen)

top - 17:11:18 up  1:18,  1 user,  load average: 1.82, 1.33, 1.65
Tasks: 109 total,   2 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28.4 us,  0.6 sy,  0.0 ni, 71.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3955.6 total,   2359.0 free,    708.4 used,    888.2 buff/cache
MiB Swap:    100.0 total,    100.0 free,      0.0 used.   3090.6 avail Mem
  scroll coordinates: y = 1/109 (tasks), x = 1/12 (fields)
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
16947 iobroker  20   0  461636 371768  26096 R  59.9   9.2  42:32.93 iobroker.js-con
16981 iobroker  20   0  384892 297708  27468 S  56.6   7.3   7:09.40 io.admin.0
  641 pi        20   0   12204   4140   3340 S   0.3   0.1   0:02.30 sshd
19875 pi        20   0   10188   2912   2548 R   0.3   0.1   0:00.13 top
    1 root      20   0   33696   7992   6296 S   0.0   0.2   0:03.89 systemd
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.01 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.71 ksoftirqd/0
   10 root      20   0       0      0      0 I   0.0   0.0   0:03.18 rcu_sched
   11 root      20   0       0      0      0 I   0.0   0.0   0:00.00 rcu_bh
   12 root      rt   0       0      0      0 S   0.0   0.0   0:00.07 migration/0
   13 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0
   14 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/1
   15 root      rt   0       0      0      0 S   0.0   0.0   0:00.10 migration/1

Hab mittlerweile den log level des js-controler über die iobroker.json auf "debug" gesetzt. Der log gibt aber weiterhin keinerlei Aufschlüsse darüber was hier los sein soll.

[Homoran]

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

So sah das ganze am Ende in top aus

Also läuft nichts außer dem admin?
Dann sind 59% CPU und ein load average von 1.8 ein Vielfaches zu hoch

[miggedy]

Richtig. Nur admin läuft noch.
Hab auch schon mal iobroker gestoppt und dann geschaut um sicher zu gehen ob nicht irgendwas anderes auf der Kiste läuft und die Probleme macht. Aber nein, dann ist CPU komplett runter. Liegt also definitiv am iobroker selbst.

Kann man den iobroker.js-connection neuinstallieren oder so? Scheint ja wirklich an diesem zu liegen und an keinem Adapter (maximal noch am admin adapter).

[Homoran]

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

an keinem Adapter.

der admin, der ja jetzt gar nichts zu tun hat liegt auch bei knapp 60%

ich hoffe das ist jetzt richtig!! aus dem Kopf:
npm install iobroker.js-controller --production

unbedingt im Verzeichnis /opt/iobroker ausführen!!
oder wo auch immer bei dir ioBroker installiert ist

[miggedy]

js-controller wie von dir angegeben fehlerlos aktualisiert. Danach noch iobroker del admin und iobroker add admin.
Aber keine Verbesserung. Das initiale Laden der admin Seite dauert ewig. Wenn die Seite ein mal da ist, geht die CPU runter und man kann auch problemlos zwischen den Menüpunkten des admin hin und herspringen. Echt seltsam.

[miggedy]

Kann es sein, dass irgendwas mit meinen Objekten nicht stimmt? Kann man die prüfen/reparieren lassen oder so?

[Homoran]

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

iobroker add admin.

dann wird er wahrscheinlich wieder aus dem npm-cache installiert.
Falls der Fehler an dem admin liegt sollte er auch über npm mit --production installiert werden

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

Das initiale Laden der admin Seite dauert ewig.

Das könnte ein Indiz dafür sein - muss aber nicht

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

Kann man die prüfen/reparieren lassen oder so?

Auch das ist eine Option, wenn z.B. unzulässige Zeichen in den IDs sind.
ein Backup vorausgesetzt, kannst du ja alle Datenpunkte löschen
Beim Neustart der Instanzen werden diese ja wieder angelegt. (außer manuell angelegte - die kannst du ja vorher exportieren [ohne Werte allerdings])

[miggedy]

Habe admin nun auch mit npm install iobroker.admin --production aktualisiert und dabei folgende Warnungen bekommen. Die sind aber nicht wirklich ein Problem, oder?

pi@iobroker-pi4:/opt/iobroker $ npm install iobroker.admin --production
npm WARN enoent ENOENT: no such file or directory, open '/opt/iobroker/node_modules/bufferutil/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/opt/iobroker/node_modules/sqlite3/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/opt/iobroker/node_modules/utf-8-validate/package.json'
npm WARN moment-feiertage@2.0.1 requires a peer of moment@2.15.x but none is installed. You must install peer dependencies yourself.
npm WARN xmlhttprequest-ts@1.0.1 requires a peer of @angular/common@>= 5.0.0 butnone is installed. You must install peer dependencies yourself.
npm WARN xmlhttprequest-ts@1.0.1 requires a peer of @angular/core@>= 5.0.0 but none is installed. You must install peer dependencies yourself.

Nach dem update gab es leider auch keine Besserung.

Werde dann wohl mal die Neulanlage aller Datenpunkte machen müssen.

[Homoran]

@miggedy sagte in admin Seiten laden extrem langsam bis gar nicht:

folgende Warnungen bekommen. Die sind aber nicht wirklich ein Problem

ENOENT klingt für mich nicht beruhigend, aber es ist ja nur ein WARN.

kann ich dir aber nicht wirklich sagen. Da müsste ein wissender etwas zu sagen.

[miggedy]

Das Problem ist identifiziert. Der BLE Adapter hatte fast 160.000 Objekte angelegt. Die objects.json war dadurch fast 80MB groß.
BLE Adapter gelöscht, alles wieder gut. :-)

Also wenn jemand ähnliches feststellt, am Besten mal die objects.json überprüfen ob die unnormal groß ist. Meine schätzungsweise leicht überdurchschnittlich umfangreiche Installation hat z.B. nun eine Größe von 6,5 MB.
Ist die Datei sehr groß könnte das ein Hinweis sein, dass da was nicht stimmt. Da solche großen JSON Dateien für viele Programme zu groß sind um sie zu untersuchen, habe ich den HugeJsonViewer verwendet. Beim einfachen durchscrollen der Datei ist sofort aufgefallen, dass der BLE Adapter Unmengen an Objekten hatte.

Herzlichen Dank @Homoran für deine geduldige Hilfe.

[tr1plx]

Vielen Dank für den Tipp!
Mein ioBroker war auch unendlich langsam geworden und ich habe viele Stunden gerätselt warum.
Meine /opt/iobroker/iobroker-data/objects.json war 83MB groß, die states.json 31MB !

Schuld war bei mir der Adapter unifi.0 - diesen gelöscht und auch die Objekte und schon geht wieder alles.

Meine UniFi-Installation mit > 3500 Endgeräten scheint wohl "too much" für iobroker :-)

[arnold]

hallo.
habe was fast ähnlich, bin vor 1 Woche mit mini bakitup umgezogen von Rpi 3 auf Rpi4 .
nach dem start von iobroker wurde Wlan immer langsamer von 72 Mbit/s (wlan von PRI4)auf nur 1Mbit/s, bis ich garn nicht mit putty mich anmelden konnte .
aber jetzt Lösung

Die existierenden node & node.js Versionen deinstallieren

sudo apt-get --purge remove node

sudo apt-get --purge remove nodejs

sudo apt-get autoremove

sudo reboot

und installieren

curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -

sudo apt install -y nodejs

sudo reboot

vorher mit langsamen Wlan und naher sind
node -v
v10.19.0
nodejs -v
v10.19.0

npm -v
6.13.4
gleich !!!!!

aber jetzt rent der iobroker wieder seit 3 tagen perfekt .
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Fixer drüber laufen lassen und schon wieder Wlan auf 1Mbit/s
curl -sL https://iobroker.net/fix.sh | bash -
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

bei Rpi 3 (jessi) wahr das kein Problem , brauch man den fixer nicht mehr ?
Rpi 4 hat jetzt Buster .

oder hat Buster Lite oder mit Desktop hier was zu sagen ? (habe mit Desktop)

[cTech]

Tipp: Im Admin Adapter (oder auch anderen Adaptern) auch mal einen festen Netzwerkadapter auswählen. Das war bei mir der Übeltäter.