Weihnachtsangebot 2025! 🎄

[sigi234]

@manuelgrasgruen-it sagte in Node.exe 100% CPU:

Node.js: v10.15.1

Ja das :

Node.js: v10.15.1

[apollon77]

Welcher Prozess genau ist es denn mit den 100% Schau mal in die Kommandozeile des Prozesses? Ist es ein Adapter oder der js-controller? Wie gross ist die Installation denn so? Wieviele States und Objekte (steht im Admin unter Objekte rechts oben).

[manuelgrasgruen.it]

@sigi234 Gibt es ein Problem mit node.js 10.15.1 ? Andere Version einsetzen?

@apollon77 Es ist nicht ein Prozess auf 100%, sondern die node.exe Prozesse summieren sich auf 100%. Das auch nicht durchgehend, sondern alle paar Sekunden für ein paar Sekunden. Ich denke das ist, da der Adapter offensichtlich ständig wieder gestartet wird.

Die Installation ist noch ziemlich klein, hab noch kaum was eingerichtet. Allerdings zeigt er bereits: Objekte: 980, Zustände: 844
Ist das normal?

Danke

[sigi234]

@manuelgrasgruen-it sagte in Node.exe 100% CPU:

@sigi234 Gibt es ein Problem mit node.js 10.15.1 ? Andere Version einsetzen?

Diese Version wird noch nicht unterstützt.....

[apollon77]

Speziell auf Windows gab es probleme, die aber mit dem latest js-controller (1.5.7) gefixt sein sollten. Also gern js-controller Upgrade testen.

[apollon77]

@manuelgrasgruen-it Das kommt darauf an um welchen Adapter es sind handelt. Ja es gibt welche die nach Schedule neu gestartet werden ... welcher Adapter ists denn?

[lobomau]

@manuelgrasgruen-it

Die Installation ist noch ziemlich klein, hab noch kaum was eingerichtet. Allerdings zeigt er bereits: Objekte: 980, Zustände: 844
Ist das normal?

Danke

Das ist normal und nicht viel. Bei mir steht:
Objekte: 15037, Zustände: 13253

[manuelgrasgruen.it]

Ich habe nun mal ein js-controller update gemacht. Wenn es wieder auftritt werde ich wohl node.js downgraden müssen.

@apollon77 Der Node-Red Adapter. Alle paar Sekunden wird wohl kein Adapter neu gestartet werden. Und es taucht immer erst nach einigen Stunden auf und bemängelt dann immer den blockierten Port.

Danke

[apollon77]

Naja dann musst Du rausfinden was noch auf 1881 läuft ... oder stoppe mal ioBroker und schau das alle Prozesse gestoppt sind und starte neu

[manuelgrasgruen.it]

js-controller update hat wohl geholfen. Bisher läuft es stabil ohne große CPU Auslastung.

Ich glaube nicht, dass irgendetwas anderes den Port 1881 nutzt. Vor allem war es beim 1880 gleich und beim Neustart des Adapters passt es ja immer für eine Weile.

[aleks-83]

Hi,

ich bin mit meinem System aus der Ubuntu VM ins native Windows 10 64 bit umgezogen und habe auch eine CPU Auslastung von fast dauerhaften 100%.
Der Prozess node.exe taucht 33 ! mal im Taskmanager auf.
Runtimebroker.exe 8 mal

Aber komischerweise Opera auch 15x. Obwohl er nur 1x geöffnet ist.

Die node.exe Prozesse sind aber meist vorne mit dabei und dürften den Großteil der CPU Last ausmachen.

Beende ich iobroker (iobroker stop) beruhigt sich der CPU nach 1-2 Minuten auf 10-12%

[apollon77]

Ok, Aktive Instazen 32 plus eine für den js-controller ergibt 33 Prozesse. Das passt. Der "Runtimebroker" hat mit ioBroker nichts zu tun.

Bei Opera oder Browsern haben teilweise eigene Tabs eigene Prozesse damit nicht alles abschmiert wen einer crasht.

Je nachdem was genau jetzt deine Adapter so alles machen müsstest Du schauen. in ioBroker hat jeder Adapterprozess unter "system.adapter.Name" einige Statistik-States (ggf musst Du Filter in der Objektansicht rausnehmen das Du die States siehst). Da siehst Du auch wieviel CPU jeder Prozess so braucht. So kannst Du den Lastverursachern auf die Schliche kommen.

Ingo F

[aleks-83]

Bei den Prozessen unter "system.adapter.name" steht überall "0.00 % of one core"
Aber ioBroker nutzt auf jeden Fall alle 4 Kerne aus, das sehe ich im Taskmanager.

Habe jetzt mal alle Adapter deaktiviert ausser admin.
Dann läuft er super mit 15-20% CPU-Last.
Je mehr Adapter ich aktiviere (egal welche) desto mehr nimmt die Last zu.
Bei 20 zugeschalteten Adaptern schwankt er schon zwischen 50-80%
ab ca. 15 Adaptern steht konstant 100% an.

Managed Windows das ganz so viel schlechter als Linux?
Als ioBroker noch in einer Ubuntu 18.04 VM unter Proxmox lief brauchte die gleiche ioBroker Instanz nur 20-30% CPU.

Ich werde mal versuchen unter Windows eine Ubuntu VM laufen zu lassen und die Instanz dort zu installieren.

[Stabilostick]

@aleks-83

Ich habe Dir eine Chat-Nachricht wegen der CPU-Last geschrieben. Lass uns das zusammen ansehen.

[Stabilostick]

Vorläufiges Ergebnis der Untersuchung zusammen mit @aleks-83:

System-Ausgangszustand

• NUC mit CPU Intel Celeron J3455 @ 1.50GHz
  • Average CPU Mark: 2110
  • Cores: 4, Typical TDP: 10 W
• 16GB RAM
• Software
  • Windows 10
  • Avast Antivirus
  • Opera Webbrowser
  • Etliches an kleinen Hilfsprogrämmchen im Hintergrund
    • Java-Updater
    • Buhl-Updater
    • Unify
    • ...
• ioBroker mit neuem Windows Installer installiert
  • 32 Adapterinstanzen
  • etwa 900 Ereignisse/15s im System, javascript hat alle abonniert
  • zum Zeitpunkt der Prüfung wurden viele Ereignisse vom upnp-Adapter erzeugt. (etwa 500/15s)
• CPU schwankt zwischen 70% und 100% Last

CPU-Nutzung durch ioBroker

• ioBroker hat für den js-controller Node.js-Prozess mit den Datenbanken durchweg etwa 5% CPU benötigt.
• Jeder Adapter hat etwa 0,1-0,5% CPU verwendet.
• Alle 15s hat jeder Adapter einmal WMIC aufgerufen. Der Prozess hat dann für ca. 1s jeweils etwa 3-5% CPU genutzt
• Der WMIPRVSE-Prozess hat als Gegenstelle für die WMI-Abfragen hat ebenfalls etwa 2-5% CPU Last erzeugt

CPU-Nutzung durch Anwendungen und System

• Teamviewer 10-20%
• Opera 20-50% (wenn was gemacht wurde, sonst <5%)
• ProcessExplorer 10%
• Avast System Dienst 5%
• Desktop-Manager 3%, Java-Updater 1%, Buhl 0,5%, ......

Rechenspiele
Damit ergibt sich die Gesamtsystemlast für ioBroker zu:

jscontroller + 32*Adapter + WMIC-Abfragen für 32 Instanzen mit jeweils 1s Dauer alle 15s
5% + 32*0,5 + (1s*32/15s) * 5% = ~30% im Maximum

Gesamtsystemlast pi mal Daumen hochgerechnet:

Prozess	CPU-Last
iobroker	30% im Maximum
TeamViewer	15%
Process Explorer	10%
Avast Antivir	5%
30x irgendwelche kleinen Prozesse à 0,5%	15%
	=====
Summe	70%
Opera zusätzlich mit Admin aufrufen	40%
	=====
Summe	110% ;-)

Und das entspricht (trotz Milchmädchenrechnung) dem, was wir am laufenden System auch beobachtet haben.

Ergebnisse also für ioBroker-Server (mit kleiner CPU) auf Windows:

• Einen Rechner mit kleiner CPU mit TeamViewer fernzusteuern kostet locker 1/5 der Systemperformance.
• Auf dem Server mit kleiner CPU sollte man keinen Webbroswer aufgerufen. Wenn doch, verursacht er schnell 1/4 oder mehr CPU-Last und verlangsamt zusätzlich die Serverprozesse.
• Datenbankdateien oder Datenbankordner müssen unbedingt vom Virenscan ausgenommen werden, da der Virenscanner sonst übermäßig CPU-Ressourcen verbraucht. Auf Windows ist der eingebautet Defender zu bevorzugen wegen relativ geringer CPU-Last. Der aktuelle Window Installer trägt eine entsprechende Ausnahme in den Defender ein.
• Jede zusätzliche Anwendung im Hintergrund verbraucht (unnötig) CPU-Ressourcen. Deinstallieren.
• Den Prozess-Ausführungsmodus für dedizierte ioBroker-Server umstellen auf "Hintergrunddienste":
  

Und abschließend:

• Die Node.js-Prozesse und damit ioBroker ist hier nicht vorwiegend an der 100% CPU-Last verantwortlich. Haltet Eure Serversysteme schlank.

PS: Und wenn man kleine Linux-Systeme hernimmt und sagt, wie toll die doch sind:
Die haben i.d.R. kein grafische Benutzeroberfläche aktiv und führen keine Antiviren-Programme oder Webbrowser aus, kein Homebanking und keine Maustreiber von Logitech. Es liegt bei uns.

[aleks-83]

Moin,

was für eine Zusammenfassung :rolling_on_the_floor_laughing: :ok_hand:
Dir auch nochmal vielen Dank für die persönliche Hilfe und das gute Gespräch.

Deine Beobachtungen kann ich so zu 100% unterschreiben.
Ich habe nach unserem Telefonat noch etwas ausprobiert und aufgeräumt.

Insgesamt war es nicht der ioBroker selbst der die Maschine ausgelastet hat, sondern die Kombination aus ioBroker, TeamViewer, Opera und avast.
Was ja eigentlich keine ungewöhnlichen Tools sind auf so einer Maschine!?

Ein, bei mir sehr großer Punkt war aber auch der Info Adapter.
Bei "aktuelle Systemdaten nicht lesen" war kein Haken gesetzt, und die Systemdaten wurden alle 3-10s gelesen.
Wenn ich diesen Haken gesetzt habe, wurde das System um bis zu 30% weniger belastet.
Ob das jetzt nur bei mit so ist, oder ob es ein Problem im Adapter ist, kann ich nicht sagen.

Jetzt läuft das System bei 31 aktivierten Adaptern bei 25-30%.

Den TeamViewer nutze ich nur noch wenn nötig. Den hatte ich eigentlich genutzt um den Rechner komfortabler einrichten zu können und nicht immer im Wohnzimmer den TV zu blockieren wo der NUC dran hängt (zwecks Kodi). Ja, Kodi ist auch installiert, läuft aber nur bei Bedarf.
ioBroker konfiguriere ich dann nur noch von extern.
Avast habe ich deinstalliert und nutze wieder den Defender.

[klassisch]

Vielen Dank für die Beiträge. So sieht man mal die Lasten mit anderen Prozessoren.
Auch nach meiner Beobachtung / Erfahrung ist die Defaulteinstellung des sehr hilfreichen info-Adapters paranoid (subjektive Meinung). Das scheint auch der Kampf vom user @Feuersturm zu zeigen. Es wäre prima, wenn man das Update-Intervall noch etwas in den Minutenbereich hin ausdehnen könnte und das als Default wert einstellen könnte. Ich habe die Hürde zum Eintragen in die History durch großzügige Deltabedingungen erhöht. Im Normalbetrieb ist das noch Info genug, die Kurven sind etwas gröber aber normalerweise noch aussagkräftig.
Die Last durch info-Adapter und einen system-info Adapter hatte auch die Instabilitäten meines headless operierenden linuxbasierten Orange Pi Plus 2e ausgelöst.
Auf meinem i5 läuft noch eine deutlich intensivere Applikation parallel und ich komme auf eine Gesamtlast von 14% bis 30%. ioBroker ist der kleinste Anteil.
Immer noch aktuell; allerdings erst seit Win Update auf 1903: Wenn ich mit Remote Desktop auf dem Rechner war, dann den Remote Desktop schließe, geht die Prozessorast dramatisch hoch, was sich auch an der Temp bemerkbar macht. Wenn ich dann kurz mit UltraVNC drauf gehe und das wieder schließe ist alles wieder gut. Experimenteller Befund auf meinem System, Ursache sowie Übertragbarkeit der Beobachtung unklar. Hier also Vorsicht bzw. Augen auf.

Gibt es eine einfache Möglichkeit, die gesamte ioBroker-induzierte Last zu erfassen? Ich sehe halt eine Vielzahl ununterscheidbarer ioBroker Prozesse im Taskmanager aufblitzen und muß dann schätzen oder raten.

[apollon77]

@klassisch sagte in Node.exe 100% CPU:

Es wäre prima, wenn man das Update-Intervall noch etwas in den Minutenbereich hin ausdehnen könnte und das als Default wert einstellen könnte.

Dann legt dazu bitte ein GitHub Issue an. Nur solist sichergestellt das es der ENtwickler sieht und es auch nicht vergisst

[klassisch]

@apollon77 sagte in Node.exe 100% CPU:

Dann legt dazu bitte ein GitHub Issue an. Nur so ist sichergestellt dass es der Entwickler sieht und es auch nicht vergisst

Danke für den Hinweis. Es gibt bereits einen ähnlichen issue
https://github.com/iobroker-community-adapters/ioBroker.info/issues/38#

auf den ich geantwortet habe. Bin nicht so Git-virtuos und weiss nicht, ob das dem normalen Vorgehen entspricht; falls nicht kann ich einen neuen issue anlegen

[OT]
btw. Git issues: Welche Komponente verwaltet das Logfile? bei meiner Win Installation erhalte ich reproduzierbar immer beginnend nach einer Woche und bei jeder Auswahl eines Menuepunkte im Admin-Menue bzw. Aufruf des Admins selbst eine Fehlermeldung im log:

Cannot check file: C:\Program Files\iobroker\ioBrMain2\log/iobroker.log.2019-09-01

Es kann also das Logfile, welches vor einer Woche angelegt wurde, nicht mehr bearbeitet werden. Die Datei ist mit dem TotalCommander noch sichtbar aber mit Notepad++ nicht mehr zu öffnen mit Hinweis auf Nichtexistenz.

Ich würde bei der entsprechenden Komponente einen issue anlegen

[apollon77]

@klassisch hm ... also um Standard werden logfiles nach 7 Tagen gelöscht. Sicher das das file wirklich noch da ist?