NEWS
iobroker.js-con 100% cpu
-
@homoran
Alle 1 Minute kommen da die verschiedenen Daten von der Wetterstation.Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@wendy2702 Jep
Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@wendy2702 Jep
-
@wendy2702 sagte in iobroker.js-con 100% cpu:
der verliert scheinbar im Millisekunden Takt die Verbindung
Oder ein ungünstig progammiertes Script, welches sich anmeldet, Wert subscribed, sich abmeldet, sich wieder anmeldet, nächsten Wert subscribed, ...
Darauf deutet der Name hin.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@wendy2702 sagte in iobroker.js-con 100% cpu:
der verliert scheinbar im Millisekunden Takt die Verbindung
Oder ein ungünstig progammiertes Script, welches sich anmeldet, Wert subscribed, sich abmeldet, sich wieder anmeldet, nächsten Wert subscribed, ...
Darauf deutet der Name hin.
@marc-berg
Das könnte gut sein. Ich werd mal meine Scripts (Python und BASH) überprüfen. -
@wendy2702 sagte in iobroker.js-con 100% cpu:
der verliert scheinbar im Millisekunden Takt die Verbindung
Oder ein ungünstig progammiertes Script, welches sich anmeldet, Wert subscribed, sich abmeldet, sich wieder anmeldet, nächsten Wert subscribed, ...
Darauf deutet der Name hin.
@marc-berg
Du hast mich auf die richtige Fährte gebracht. Wenn ich die MQTT Server IP ändere (ins Leere), sieht top so aus:
Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@marc-berg
Du hast mich auf die richtige Fährte gebracht. Wenn ich die MQTT Server IP ändere (ins Leere), sieht top so aus:@spicer sagte in iobroker.js-con 100% cpu:
Wenn ich die MQTT Server IP ändere (ins Leere)
@marc-berg sagte in iobroker.js-con 100% cpu:
Hast du das Loglevel der MQTT.1 Instanz mal auf "debug" gestellt?
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@spicer sagte in iobroker.js-con 100% cpu:
Wenn ich die MQTT Server IP ändere (ins Leere)
@marc-berg sagte in iobroker.js-con 100% cpu:
Hast du das Loglevel der MQTT.1 Instanz mal auf "debug" gestellt?
@marc-berg
Ja, aber da kann so viel Output, dass top 300% CPU anzeigte ^^Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@marc-berg
Ja, aber da kann so viel Output, dass top 300% CPU anzeigte ^^@spicer sagte in iobroker.js-con 100% cpu:
@marc-berg
Ja, aber da kann so viel Output, dass top 300% CPU anzeigte ^^Das sagt aber schon alles. Ich bleibe dabei: eine Schleife.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@spicer sagte in iobroker.js-con 100% cpu:
@marc-berg
Ja, aber da kann so viel Output, dass top 300% CPU anzeigte ^^Das sagt aber schon alles. Ich bleibe dabei: eine Schleife.
@marc-berg
Jo, das glaube ich Dir.
Muss nun suchen
Ist ziemlich viel.Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@marc-berg
Jo, das glaube ich Dir.
Muss nun suchen
Ist ziemlich viel.@spicer sagte in iobroker.js-con 100% cpu:
Muss nun suchen
Aber wenn du das Debug-Log kurz anmachst, dann wirst du sicher Hinweise sehen.
NUC10I3+Ubuntu+Docker+ioBroker+influxDB2+Node Red+RabbitMQ+Grafana
Pi-hole, Traefik, Checkmk, Conbee II+Zigbee2MQTT, ESPSomfy-RTS, LoRaWAN, Arduino, KiCad
Benutzt das Voting im Beitrag, wenn er euch geholfen hat.
-
@spicer sagte in iobroker.js-con 100% cpu:
Muss nun suchen
Aber wenn du das Debug-Log kurz anmachst, dann wirst du sicher Hinweise sehen.
Ist zwar jetzt etwas OT hier, aber hier einer der wirklichen Gründe, warum man keine GUI auf einem Server laufen hat:
https://www.phoronix.com/news/X.Org-CVE-2024-9632
Was nicht läuft und am besten auch erst gar nicht installiert ist kann auch nicht anfällig für eine 'Privilege Escalation' sein.
-
Hab das Problem gefunden.
Alle 30 Sekunden oder teilweise sogar 10 Sekunden wurde der MQTT Server mit sub/pub's gelöchert.
Wenn das geschieht, geht die CPU für ca 30 Sekunden auf 100%.
Das war natürlich zuviel.
Habe jetzt das Intervall (ausser Regen und Wind Warnung) auf mind 2 Minuten gesetzt.
So beruhigt sich das Ganze immer für ca 90 Sekunden. -
Konnte die Situation weiter entschärfen, in dem ich alles MQTT auf dem RPI1, welches für die Dachfenster und Rollo Steuerung zuständig ist, sammle.
Sende dann nur alle paar Minuten MQTT Daten an das RPI5.
Einzig die Windgeschwindigkeit sende ich jede minute (das ist ein String von 3-4 Zeichen).
Es fällt auf, dass der ioBroker Adapter MQTT auch nur bei diesem empfangenen MQTT Datensatz die CPU für fast 30 Sekunden auf 100-106% (laut top) treibt.
Es sieht so aus, dass da der Adapter auch "etwas komisches" macht. Wenn ihr mich fragt, mit dem Adapter stimmt was nicht.
So viel Rechenleistung wegen einem einzigen Subscribe (Datenempfang) von zBsp "0.1".
Ein Loop kann es nicht sein, weil das Gleiche geschieht, wenn ich die Instanz Javascript stoppe.Befriedigend ist die jetzige Lösung bzw Verhalten nicht.
PS:
Beim RPI1 zeigt top unter 1% Auslastung, obschon da jede Sekunde Mosquitto Daten reinschneien.
Dieses hat einen Bruchteil der Rechenleistung des RPI5!
Wenn ich auf dem RPI1 top ausführe, ist meistens top der belastendste Task ^^Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
Konnte die Situation weiter entschärfen, in dem ich alles MQTT auf dem RPI1, welches für die Dachfenster und Rollo Steuerung zuständig ist, sammle.
Sende dann nur alle paar Minuten MQTT Daten an das RPI5.
Einzig die Windgeschwindigkeit sende ich jede minute (das ist ein String von 3-4 Zeichen).
Es fällt auf, dass der ioBroker Adapter MQTT auch nur bei diesem empfangenen MQTT Datensatz die CPU für fast 30 Sekunden auf 100-106% (laut top) treibt.
Es sieht so aus, dass da der Adapter auch "etwas komisches" macht. Wenn ihr mich fragt, mit dem Adapter stimmt was nicht.
So viel Rechenleistung wegen einem einzigen Subscribe (Datenempfang) von zBsp "0.1".
Ein Loop kann es nicht sein, weil das Gleiche geschieht, wenn ich die Instanz Javascript stoppe.Befriedigend ist die jetzige Lösung bzw Verhalten nicht.
PS:
Beim RPI1 zeigt top unter 1% Auslastung, obschon da jede Sekunde Mosquitto Daten reinschneien.
Dieses hat einen Bruchteil der Rechenleistung des RPI5!
Wenn ich auf dem RPI1 top ausführe, ist meistens top der belastendste Task ^^Bitte testet doch mal selber und meldet es gegebenenfalls dem Dev.
DankeEs könnte ja auch sein, dass das nur bei Raspberry OS so ist und nicht bei Raspbian.
deCONZ zBsp hatte genau dieses Problem!
Eine if Abfrage ging auf "raspbian" und nicht auf "debian", was Raspberry OS heute ausgibt.Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
Bitte testet doch mal selber und meldet es gegebenenfalls dem Dev.
DankeEs könnte ja auch sein, dass das nur bei Raspberry OS so ist und nicht bei Raspbian.
deCONZ zBsp hatte genau dieses Problem!
Eine if Abfrage ging auf "raspbian" und nicht auf "debian", was Raspberry OS heute ausgibt.@spicer said in iobroker.js-con 100% cpu:
Bitte testet doch mal selber und meldet es gegebenenfalls dem Dev.
DankeEs könnte ja auch sein, dass das nur bei Raspberry OS so ist und nicht bei Raspbian.
deCONZ zBsp hatte genau dieses Problem!
Eine if Abfrage ging auf "raspbian" und nicht auf "debian", was Raspberry OS heute ausgibt.Dass ein IF nicht geht klingt mal komisch. Wahrscheinlich meinst du eher, dass eine Abfrage eines APIs andere Werte geliefert hat.
EGAL:
Bitte gib doch bei allen solchen Problemmeldungen gesammelt die Versionsinfos an. Ich kann aus deinen letzen Beiträgen weder die Adapetr version noch js.controller, node, os etc herauslesen.Und natürlich stellt sich die Frage was der Adapetr im DEBUG bzw. SILLY Mode loggt wenn er so ausgelastet ist / wird.
Entwicklung u Betreuung: envertech-pv, hoymiles-ms, ns-client, pid, snmp Adapter;
Support Repositoryverwaltung.Wer Danke sagen will, kann nen Kaffee spendieren: https://paypal.me/mcm1957atiobroker
-
@spicer said in iobroker.js-con 100% cpu:
Bitte testet doch mal selber und meldet es gegebenenfalls dem Dev.
DankeEs könnte ja auch sein, dass das nur bei Raspberry OS so ist und nicht bei Raspbian.
deCONZ zBsp hatte genau dieses Problem!
Eine if Abfrage ging auf "raspbian" und nicht auf "debian", was Raspberry OS heute ausgibt.Dass ein IF nicht geht klingt mal komisch. Wahrscheinlich meinst du eher, dass eine Abfrage eines APIs andere Werte geliefert hat.
EGAL:
Bitte gib doch bei allen solchen Problemmeldungen gesammelt die Versionsinfos an. Ich kann aus deinen letzen Beiträgen weder die Adapetr version noch js.controller, node, os etc herauslesen.Und natürlich stellt sich die Frage was der Adapetr im DEBUG bzw. SILLY Mode loggt wenn er so ausgelastet ist / wird.
@mcm1957
mqtt: v6.1.1Plattform: linux Betriebssystem: linux Architektur: arm64 CPUs: 4 Geschwindigkeit: 2400 MHz Modell: Cortex-A76 RAM: 7.8 GB System-Betriebszeit: 3 T. 15:40:26 Node.js: v20.18.0 time: 1730545435253 timeOffset: -60 NPM: 10.8.2 Adapter-Anzahl: 545 Datenträgergröße: 57.9 GB Freier Festplattenspeicher: 49.3 GB Aktive Instanzen: 10 Pfad: /opt/iobroker/ Betriebszeit: 3 T. 16:14:09 aktiv: trueReicht das?
Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz) -
@mcm1957
mqtt: v6.1.1Plattform: linux Betriebssystem: linux Architektur: arm64 CPUs: 4 Geschwindigkeit: 2400 MHz Modell: Cortex-A76 RAM: 7.8 GB System-Betriebszeit: 3 T. 15:40:26 Node.js: v20.18.0 time: 1730545435253 timeOffset: -60 NPM: 10.8.2 Adapter-Anzahl: 545 Datenträgergröße: 57.9 GB Freier Festplattenspeicher: 49.3 GB Aktive Instanzen: 10 Pfad: /opt/iobroker/ Betriebszeit: 3 T. 16:14:09 aktiv: trueReicht das?
@spicer
Der Output von "Debug" ist unglaublich gross. Das kann ich nicht posten.
Da müsstest schon per Teamviewer oder Anydesk schauen hier.Ey, ich habe nicht nur 2-3 Adapter/Geräte!
Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen nach sich zieht, dann wird es jemand genau so machen. Alles, was schiefgehen kann, wird auch schiefgehen.
(Murphys Gesetz)
656
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge