massive CPU Auslastung

[da_Woody]

@apollon77 sorry...
ok

woody@ioBroker:~$ npm install iobroker.js-controller@3.3.22 --production

> iobroker.js-controller@3.3.22 preinstall /home/woody/node_modules/iobroker.js-controller
> node lib/preinstallCheck.js

NPM version: 6.14.16

> iobroker.js-controller@3.3.22 install /home/woody/node_modules/iobroker.js-controller
> node iobroker.js setup first

object _design/custom updated
object _design/system updated

ATTENTION: Error reporting via Sentry will be activated on next start of ioBroker

ioBroker wants to make sure to deliver the most stable smart home system.
To allow this we decided to implement an automatic error and crash reporting solution into the js-controller and also into adapters.

THIS REPORTING WILL BE ENABLED WITH THE NEXT START OF YOUR IOBROKER!

For any error that leads to the crash of the js-controller or one of the relevant adapters the error details are send to a server. For the js-controller and core adapters this server is located and operated in germany. For community adapters please check the Github Readme of the affected adapter for details which Sentry server is used.

If you want to disable the error reporting you can use the command
'iobroker plugin disable sentry'
This command will also make sure that no adapter that runs on this host will send crash reporting data to sentry.


npm WARN saveError ENOENT: no such file or directory, open '/home/woody/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/woody/package.json'
npm WARN woody No description
npm WARN woody No repository field.
npm WARN woody No README data
npm WARN woody No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

+ iobroker.js-controller@3.3.22
updated 1 package and audited 485 packages in 8.91s

12 packages are looking for funding
  run `npm fund` for details

found 21 vulnerabilities (13 low, 5 moderate, 3 high)
  run `npm audit fix` to fix them, or `npm audit` for details
woody@ioBroker:~$

sieht mal nicht so schlecht aus... denk ich mal.
was bedeutet das run npm audit fix to fix them, or npm audit for details jetzt? soll ich den fix ausführen vor iob start?
ich kann diese meldungen nicht wirklich interpretieren ob notwendig, oder nicht.

[apollon77]

@da_woody sagte in massive CPU Auslastung:

/home/woody/

Jetzt haste es wieder in deinem Home Dir ausgeführt und nicht in /opt/iobroker ... also nochmal bitte an deer richtigen Stelle.

npm audit ... ignorieren bzw wenn alles wieder tut machste einmal "iob fix" und das kommt eh nie wieder

[da_Woody]

@apollon77 oh mann. die shell geschichten treiben mich noch ins irrenhaus.

woody@ioBroker:/opt/iobroker$ npm install iobroker.js-controller@3.3.22 --production

> iobroker.js-controller@3.3.22 preinstall /opt/iobroker/node_modules/iobroker.js-controller
> node lib/preinstallCheck.js

NPM version: 6.14.16

> iobroker.js-controller@3.3.22 install /opt/iobroker/node_modules/iobroker.js-controller
> node iobroker.js setup first

Server Cannot start inMem-states on port 9000: Failed to lock DB file "/opt/iobroker/iobroker-data/states.jsonl"!
npm WARN xmlhttprequest-ts@1.0.1 requires a peer of @angular/common@>= 5.0.0 but none 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.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.3.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.3.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (node_modules/osx-temperature-sensor):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-temperature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

npm ERR! code ELIFECYCLE
npm ERR! errno 24
npm ERR! iobroker.js-controller@3.3.22 install: `node iobroker.js setup first`
npm ERR! Exit status 24
npm ERR!
npm ERR! Failed at the iobroker.js-controller@3.3.22 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/2022-02-16T15_24_17_456Z-debug.log
woody@ioBroker:/opt/iobroker$

jetzt kommen wieder die errors und plötzlich port 9000?

[apollon77]

@da_woody Ok, versuch mal ob er vllt den 4.0.10 installiert manuell ... so langsam gehen mir die ideeen aus ... und du bist sicher das nicht iiiiirgendwas auf der kiste noch läuft?

[opossum]

Hallo, @apollon77,

sorry, wenn ich mich hier reinhänge. Ich könnte anbieten, mit @da_Woody via Telefon und Anydesk die VM und den ioB neu aufzusetzen. Dann erst mal sein Backup zurückspielen und dann erst den Contoller 4.0.10. Habe ihm das auch per Chat angeboten. VM aufsetzen und IOB installieren dauert ja nicht lange. Da hätte man dann erst einmal eine "Grundstock", mit dem man arbeiten könnte. Ginge auch sofort.

[apollon77]

@opossum So etwas wäre mein nächster Vorshclag gewesen ... Und eine super Idee. Ist natürlich @da_Woody entscheiden, aber vielen Dank für das Angebot von mir in jedem Fall!

[da_Woody]

@apollon77 sagte in massive CPU Auslastung:

und du bist sicher das nicht iiiiirgendwas auf der kiste noch läuft?

login as: woody
woody@192.168.0.250's password:
Linux ioBroker 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Feb 16 16:18:11 2022 from 192.168.7.209
woody@ioBroker:~$ cd /opt/iobroker
woody@ioBroker:/opt/iobroker$ ps auxww|grep io
root        12  0.0  0.0      0     0 ?        S    16:17   0:00 [migration/0]
root        16  0.0  0.0      0     0 ?        S    16:17   0:00 [migration/1]
root       212  0.0  0.0      0     0 ?        I<   16:17   0:00 [rpciod]
root       215  0.0  0.0      0     0 ?        I<   16:17   0:00 [xprtiod]
message+   370  0.0  0.0   9100  4280 ?        Ss   16:17   0:07 /usr/bin/dbus-daemon --system --address=systemd: --nofork -                                                                  -nopidfile --systemd-activation --syslog-only
woody    11698  0.0  0.0   6088   888 pts/1    S+   21:12   0:00 grep io
woody@ioBroker:/opt/iobroker$ ps auxww|grep backup
woody    11732  0.0  0.0   6088   888 pts/1    S+   21:12   0:00 grep backup
woody@ioBroker:/opt/iobroker$

sieht für mich nicht danach aus...

versucht mit 4.0.10. auch nicht. hab aber das log mal rausgefischt das am schluß angegeben ist. vllt hilft das?

0 info it worked if it ends with ok
1 verbose cli [
1 verbose cli   '/usr/bin/node',
1 verbose cli   '/usr/bin/npm',
1 verbose cli   'install',
1 verbose cli   'iobroker.js-controller@4.0.10',
1 verbose cli   '--production'
1 verbose cli ]
2 info using npm@6.14.16
3 info using node@v14.19.0
4 verbose npm-session ec259e75475dbf14
5 silly install loadCurrentTree
6 silly install readLocalPackageData
7 http fetch GET 200 https://registry.npmjs.org/iobroker.js-controller 1004ms
8 http fetch GET 200 https://registry.npmjs.org/iobroker.js-controller/-/iobroker.js-controller-4.0.10.tgz 97ms
9 silly pacote version manifest for iobroker.js-controller@4.0.10 fetched in 1127ms
10 timing stage:loadCurrentTree Completed in 3105ms
11 silly install loadIdealTree
12 silly install cloneCurrentTreeToIdealTree
13 timing stage:loadIdealTree:cloneCurrentTree Completed in 29ms
14 silly install loadShrinkwrap
15 timing stage:loadIdealTree:loadShrinkwrap Completed in 1076ms
16 silly install loadAllDepsIntoIdealTree
17 silly resolveWithNewModule iobroker.js-controller@4.0.10 checking installable status
18 silly removeObsoleteDep removing iobroker.js-controller@4.0.9 from the tree as its been replaced by a newer version or is no longer required
19 silly removeObsoleteDep removing @alcalzone/esbuild-register@2.5.1-1 from the tree as its been replaced by a newer version or is no longer required
20 silly removeObsoleteDep removing esbuild@0.11.23 from the tree as its been replaced by a newer version or is no longer required
21 silly removeObsoleteDep removing jsonc-parser@3.0.0 from the tree as its been replaced by a newer version or is no longer required
22 silly removeObsoleteDep removing @iobroker/js-controller-adapter@4.0.9 from the tree as its been replaced by a newer version or is no longer required
23 silly removeObsoleteDep removing node-schedule@2.1.0 from the tree as its been replaced by a newer version or is no longer required
24 silly removeObsoleteDep removing cron-parser@3.5.0 from the tree as its been replaced by a newer version or is no longer required
25 silly removeObsoleteDep removing luxon@1.28.0 from the tree as its been replaced by a newer version or is no longer required
26 silly removeObsoleteDep removing semver@7.3.5 from the tree as its been replaced by a newer version or is no longer required
27 silly removeObsoleteDep removing @iobroker/js-controller-cli@4.0.9 from the tree as its been replaced by a newer version or is no longer required
28 silly removeObsoleteDep removing debug@4.3.3 from the tree as its been replaced by a newer version or is no longer required
29 silly removeObsoleteDep removing ms@2.1.2 from the tree as its been replaced by a newer version or is no longer required
30 silly removeObsoleteDep removing @iobroker/js-controller-common-db@4.0.9 from the tree as its been replaced by a newer version or is no longer required
31 silly removeObsoleteDep removing @iobroker/db-objects-file@4.0.9 from the tree as its been replaced by a newer version or is no longer required
32 silly removeObsoleteDep removing @iobroker/db-base@4.0.9 from the tree as its been replaced by a newer version or is no longer required
33 silly removeObsoleteDep removing @iobroker/js-controller-common@4.0.9 from the tree as its been replaced by a newer version or is no longer required
34 silly removeObsoleteDep removing @alcalzone/pak@0.7.0 from the tree as its been replaced by a newer version or is no longer required
35 silly removeObsoleteDep removing execa@5.1.1 from the tree as its been replaced by a newer version or is no longer required
36 silly removeObsoleteDep removing cross-spawn@7.0.3 from the tree as its been replaced by a newer version or is no longer required
37 silly removeObsoleteDep removing path-key@3.1.1 from the tree as its been replaced by a newer version or is no longer required
38 silly removeObsoleteDep removing shebang-command@2.0.0 from the tree as its been replaced by a newer version or is no longer required
39 silly removeObsoleteDep removing shebang-regex@3.0.0 from the tree as its been replaced by a newer version or is no longer required
40 silly removeObsoleteDep removing get-stream@6.0.1 from the tree as its been replaced by a newer version or is no longer required
41 silly removeObsoleteDep removing human-signals@2.1.0 from the tree as its been replaced by a newer version or is no longer required
42 silly removeObsoleteDep removing merge-stream@2.0.0 from the tree as its been replaced by a newer version or is no longer required
43 silly removeObsoleteDep removing npm-run-path@4.0.1 from the tree as its been replaced by a newer version or is no longer required
44 silly removeObsoleteDep removing onetime@5.1.2 from the tree as its been replaced by a newer version or is no longer required
45 silly removeObsoleteDep removing mimic-fn@2.1.0 from the tree as its been replaced by a newer version or is no longer required

[Jabba_the_Hutt]

nachdem ja der Port 9000 blockiert war/ist ...

was bringt

sudo netstat -tulpen | grep -i 9000

[da_Woody]

@jabba_the_hutt moin. jetzt gar nichts mehr...
gestern spät abends noch mit @opossum rumgefummelt. wir hatten schon eine neue VM fertig mit backup, mussten dann aber feststellen, daß das backup zu jung war. war schon auf jsonl. dann drauf gepfiffen und die ioBroker VMs platt gemacht.
nachdem dann auch noch proxmox rumgezickt hat, ich konnte keine IP an die MAC binden, haben wir dann aufgehört und machen heute weiter.
inzwischen hab ich mal eine debian11 VM mit richtiger IP. kurze nacht...

[apollon77]

@da_woody strange. Aber schau mal im /opt/iobroker/iobroker-Data/backup-objects. Da müssten noch ältere Backups liegen. Die von „filedb“ Zeiten werden Suchaktion nicht gelöscht. Damit solltet Du die letzten „file“ objects und states json herbekommen.

[da_Woody]

@apollon77 kein problem, hab jede menge backups auf dem NAS liegen.
werden heute eins vom 31.1. einspielen. das war vor der js-c 4er aktion. das muss noch auf file stehn. wenn alles spielt, erstmal fettes VM backup. dann nochmal 4.10 versuchen.
aber thnx 4 tip!

[apollon77]

@da_woody Dan wäre ich ja bei folgendes Vorschlag:

• 3.3.22 file ... laufen lassen und CPU und RAM und alles sichern und schauen was da so passiert das du eine Baseline hast
• 3.3.22 auf jsonl umstellen .... vergleichen
• 4.0.10 mit jsonl dann ... vergleichen

[da_Woody]

@apollon77 sagte in massive CPU Auslastung:

Dan wäre ich ja bei folgendes Vorschlag:

3.3.22 file ... laufen lassen und CPU und RAM und alles sichern und schauen was da so passiert das du eine Baseline hast
3.3.22 auf jsonl umstellen .... vergleichen
4.0.10 mit jsonl dann ... vergleichen

und genauso sind @opossum und ich auch vorgegangen. nach einem fehlversuch mit einem zu "jungen" backup, wo schon auf jsonl umgestellt war.
nachdem ich das IP problem durch eine "brutal" variante endlich erledigt hatte.
neue debian11 VM aufgesetzt. die hat sich dann eine IP aus dem DHCP bereich gekrallt. nachdem da immer wieder die selben MAC verwendet werden, habe ich mir die aus der VM genommen, an einer stelle das B durch C verändert, diese im router eingetragen, die gewünschte IP und namen dazu, abgespeichert. dann habe ich in der VM die MAC abgespeichert, voila, die gewünschte IP wurde im guest-agent angezeigt. anyway. insgesammt waren wir sicher mehr als 6 stunden mit anydesk und telefon verbunden mit pausen.
angefangen haben wir dann mit dem vorbereiten. sudo und co nachinstallieren, benutzer eintragen, ... den einzeiler, ioB insten, einrichten, ioB, javascript backups in den richtigen ordner kopiert, fertig. 1. VM backup im proxmox gemacht.
backitup angeworfen, kaffee/bierpause. wie schon beim fehlversuch, vis kann nicht installiert werden! beim nachforschen dann rausgefunden, man muss manuell erstmal manuell die ver. 1.4.6 insten, dann kann man erst updaten! @opossum hat dazu ein issue gefunden. dabei wurde angezeigt, daß von 1.4.8 ein downgrade auf eben 1.4.6 gemacht wird. update auf 1.4.12, passt.
gecheckt, alles up2date, js-controller noch auf 3.3.22, file file. nächstes backup im proxmox.
zwischendurch immer wieder CPU und RAM auslastung im auge gehabt. alles im grünen bereich.
manuell die umstellung auf jsonl gestartet. nach fertigstellung, noch immer sehr gute werte, backup.
4.0.10 mit jsonl, admin auch noch auf 5.2.3, alles paletti! aktueller stand:

das einzig seltsame, was noch immer ist, daß ich bei den admin verbindungen noch immer seltsame dinge abspielen...
2 geöffnete tabs:

objekte tab wieder geschlossen:

also statt 8 nur mehr 7 und einen admin weniger. hab allerdings auch schon gesehn, daß beim schlißen eines tabs 2 admins runtergezählt wurde. wer/was noname ist? keine ahnung. aber da wusste bis jetzt auch keiner was dazu...
HAH! geheimniss gelüftet!
extra noch einmal per anydesk auf dem bürorechner nachgeschaut, ob dort noch irgendwelche tabs offen sind. nein, definitiv nicht! dann die eingebung, firefox geschlossen, keine änderung. chrome gechlossen:

offensichtlich hat der chrome da noch einiges irgendwas im hintergrund eingelagert gehabt für eine wiederherstellung!
somit ist wirklich alles i.o.
nochmal an @opossum für die hilfe!
latürnich auch an all die anderen, die in dem tread ihren dauzu gegeben haben!
vielleicht hilft der bericht ja auch noch anderen...
eine Odyssee ist hiermit beendet...

[crunchip]

@da_woody sagte in massive CPU Auslastung:

neue debian11 VM aufgesetzt. die hat sich dann eine IP aus dem DHCP bereich gekrallt. nachdem da immer wieder die selben MAC verwendet werden, habe ich mir die aus der VM genommen, an einer stelle das B durch C verändert, diese im router eingetragen, die gewünschte IP und namen dazu, abgespeichert. dann habe ich in der VM die MAC abgespeichert, voila, die gewünschte IP wurde im guest-agent angezeigt. anyway.

jede neue VM sollte eigentlich auch eine neue MAC bekommen, warum DHCP, stellt man eigentlich von vorn herein auf statisch.
Daher schrieb ich auch

@crunchip sagte in massive CPU Auslastung:

Installier eine Neue VM mit gleicher IP, iobroker installieren und iobroker backup zurück spielen.
Die alte VM legst du zuvor still.

sonst musst du im nachhinein ja alles wieder "umbiegen"

aber schön, wenn es nun endlich läuft

[apollon77]

@da_woody Super zusammenfassung und auch von mir nochmal Danke an @opossum !Einerseits super das es tut, andererseits blöd weil wir den echten Grund nicht kennen :-)) Aber hey, man kann nicht alles haben g

Drücke die Daumen: Und ja Tabs und Browser sind so ne sache

[da_Woody]

@apollon77 sagte in massive CPU Auslastung:

Und ja Tabs und Browser sind so ne sache

as u say... ich dreh jedes mal am rad, wenn ich in iQontrol was mache. einmal passts in FF, ein andermal in Chrome. bei beiden so gut wie nie!
der grund... tja, vllt wirklich, daß ich da gepfuscht hab und nicht immer im richtigen verzeichniss war... who knows.
wollte ja gestern noch den bericht schreiben, nachdem ich aber die nacht zuvor nur 2 stunden gepennt hab, bin ich gestern weggebrochen.
bin jetzt mit allem auf latest, auch den js auf 4.0.12 angehoben. gefühlt sind die instanzen nach start schneller wieder gestartet, die CPUlast weiter runtegegangen!

bitte überfallt jetzt aber nicht alle @opossum wenn ihr probleme habt!!!

[Axel Koeneke]

Moin, habe diesen alten Fred durch googlen endeckt undmöchte dazu noch meine Beobachtung beitragen:
Ich habe auf einer Proxmox-Büchse (Container), eine neue IOB installation fertiggestellt.
Alles läuft sehr gut und flüssig und deutlich schneller, als auf meinen NUC6.
Aber mir ist wieder die CPU Last in 15 minütigen Rythmus aufgefallen.
Also nur die "Das Wetter" Instanz gestopt und siehe da - die Spitzenlast ist weg. Die durchschnittliche Last ging von ca 15% auf 5% zurück.

Leider kann ich jetzt die 15 Minuten Peeks nicht mehr darstellen.
Habt ihr den Adapter inzwischen als Ursache ausgeschlossen?

Das Ganze läuft übrigens auf einem Geekom mini Air 11.
VG
Axel

[Codierknecht]

@axel-koeneke
Da wir das in einem anderen Fred gerade hatten:
Schau mal in den Zeitplan der Instanz. Wenn "DasWetter" jeweils zur vollen (oder halben) Stunde aktualisiert wird, ist deren Server regelmäßig ziemlich ausgelastet - weil das fast alle zu diesen Zeiten machen.
Was passiert, wenn der Adapter zu eher "ungewöhnlichen" Zeiten aktualisiert? Ändert das etwas an der Last?

[Axel Koeneke]

@codierknecht Werde ich gleich mal umstellen. Danke für den Tip

[DJMarc75]

@axel-koeneke sagte in massive CPU Auslastung:

Also nur die "Das Wetter" Instanz gestopt und siehe da - die Spitzenlast ist weg. Die durchschnittliche Last ging von ca 15% auf 5% zurück.

Verhält sich bei mir auch so.

@codierknecht sagte in massive CPU Auslastung:

Was passiert, wenn der Adapter zu eher "ungewöhnlichen" Zeiten aktualisiert? Ändert das etwas an der Last?

Bei mir sind so ziemlich "schräge" Zeiten eingetragen, ändert aber nix an der CPU-Last.
Warum auch - wenn die Server bei dasWetter ausgelastet sind dann sollte dies nicht die CPU beeinflussen.