massive CPU Auslastung

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... :D
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! :D 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. :D
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.

Codierknecht

@djmarc75 sagte in massive CPU Auslastung:

Warum auch - wenn die Server bei dasWetter ausgelastet sind dann sollte dies nicht die CPU beeinflussen.

Wenn der Adapter per Schleife versucht, eine funktionierende Verbindung hinzukriegen, schon ;-)

Axel Koeneke

@djmarc75 sagte in massive CPU Auslastung:

@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.

Genau das Gleiche bei mir. Neu Zeiten (27, 47 Minuten) - wieder 15% CPU Last.
Liegt also nicht am Traffic...

Prinzipiell kann ich damit leben alle 2 Stunden ein Abruf der Daten zu machen, aber die Ursache ist damit nicht geklärt.

VG
Axel

apollon77

@codierknecht Langsame Antworten brauchen keine CPU :-)

apollon77

@codierknecht Tut er aber nicht :-)

Am Ende generiert er halt viele Daten und parst je nach settings einige Daten. Jetzt ist die Frage ewas genau passiert

Codierknecht

@apollon77 sagte in massive CPU Auslastung:

@codierknecht Tut er aber nicht :-)

Sollte auch keinesfalls eine Art Vorwurf sein.

Am Ende generiert er halt viele Daten und parst je nach settings einige Daten. Jetzt ist die Frage ewas genau passiert

Mir ist das eigentlich völlig wurscht. Ich kann durchaus damit leben.
Um ehrlich zu sein, habe ich die CPU-Last an der Ecke noch nie wirklich überwacht.
Dass das Parsen etwas mehr Last erzeugt, ist ja durchaus normal. Das haben Parser halt oft so an sich.
Und 15% ist ja jetzt auch kein echtes Problem ...

Man sollte sich immer vor Augen halten: Wir zapfen da einen (noch) kostenlosen Service an.
Wenn das Ganze mal etwas längert dauert als üblich bzw. erwartet ... so what.

DJMarc75

@codierknecht um mal ehrlich zu sein - ich hab da auch kein Problem damit.
Und wenn ich mal in meinen iobLXC schaue dann sinds bei mir keine 15% mehr sondern kurzzeitig nur 1,5% mehr als normal, also knapp 4% :grin: hab mir halt auch ne Kampfmaschine zugelegt :muscle:

Community Forum

NEWS

massive CPU Auslastung

Support us

356

32.4k

81.5k

1.3m