massive CPU Auslastung
-
-
@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 -
nachdem ja der Port 9000 blockiert war/ist ...
was bringt
sudo netstat -tulpen | grep -i 9000 -
@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... -
@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.
-
@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! -
@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
-
@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 ... vergleichenund 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...
-
@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
-
@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
-
@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!!!
-
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 -
@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? -
@codierknecht Werde ich gleich mal umstellen. Danke für den Tip
-
@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. -
@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
-
@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 -
@codierknecht Langsame Antworten brauchen keine CPU
-
@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
-
@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 passiertMir 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.
