Intel Nuc pustet, CPU Load hoch – finde nix

[metawops]

Bei mir läuft HA nativ auf einem dedizierten kleinen Intel Nuc mit i5.
Manchmal pustet der kleine Rechner deutlich hörbar, tagsüber, wenn keine Backups gemacht werden.
Ich schaue dann z.B. per ssh und htop drauf und sehe, ja, die Load ist hoch. Gleichzeitig sehe ich keine Prozesse, die signifikant Load erzeugen würden.

Habt ihr noch Tools, Kniffe, Tipps, wie man der Last auf die Schliche kommen kann? Da fehlen mir noch ein paar forensische Unix Kenntnisse …

Also: Her mit den Spezial-Kommandos!

[dp20eic]

Moin,

@metawops

Also: Her mit den Spezial-Kommandos!

da HAOS, ja nur ein abgespecktes Linux mit darauf installierten Docker ist, geht das meiste bei den Docker Containern drauf.

Installiere dir einmal das Add-on Glances, lass es dann mal eine Zeit laufen, und dann schaue dort nach.

VG
Bernd

[metawops]

Ahhh, cool, vielen Dank für den Hinweis, Glances kannte ich noch nicht!
Es läuft jetzt und ich habe das mal im Blick.
Sollte ich aus den Ergebnissen nicht selbst draus schlau werden, verlängere ich den Thread hier …

[alexsaas]

Mal ins Blaue gefragt. Nutzt du VSCode (Studio Code Server)?

Falls ja, dann ist das bekannt:

Out of control CPU while using

Ich habe das auch und starte diesen nachdem ich ihn benutzt habe neu. Dann beruhigt sich das.

[metawops]

Lieben Dank fürs Mitdenken und den Hinweis.
Aber ich habe das VSCode Addon nicht installiert hier.

Ein erstes Sichten der Ausgabe von Glances ergibt, dass zwar MotionEye, NodeRed und Glances selbst ein bisschen Last erzeugen, aber dass HomeAssistant selbst die meiste Last erzeugt – was immer das heißt.

Ob man da noch irgendwie reinschauen kann, was genau beim homeassistant Container denn die Last ausmacht bzw. wie sie sich aufteilt, wer/was da am meisten braucht?

[alexsaas]

War ein Versuch, hätte ja sein können. Ich hoffe dir kann geholfen werden. Ich bin da nicht tief genug drin.

[Jim_OS]

@metawops

dass zwar MotionEye, NodeRed und Glances selbst ein bisschen Last erzeugen,

Das ist die Last von deren Container, aber das sagt jetzt ja nichts darüber aus was sie für eine Last bei HA und bei dem HA-Container erzeugen. Als einfaches Beispiel mal MotionEye: Auch wenn Du eine Kamera bei MotionEye - also im MotionEye Container - eingebunden hast, heißt das ja nicht das diese nicht auch irgendwelche Last bei dem HA Container erzeugt. Z.B. durch einen eingebundenen Stream, oder irgendwelche Aktionen bei irgendwelchen Detektionen usw.

Bei dem überfliegen der installierten Addons würde ich vielleicht MotionEye, oder Music Assistant, oder Grafana + InfluxDB als mögliche Ursache vermuten.

@metawops

was genau beim homeassistant Container denn die Last ausmacht bzw. wie sie sich aufteilt, wer/was da am meisten braucht?

Dazu ist mir nichts bekannt. Da bleibt dann wohl ein Ausschlussverfahren, sprich einzelne Addons Schritt für Schritt deaktivieren und beobachten ob dann das “pusten” ggf. weg ist.

VG Jim

[metawops]

Ah ja, verstehe, vielen Dank für Deine Gedanken dazu, @Jim_OS!

Beim Lesen fiel mir auf, dass ich noch gar nicht erwähnt hatte, dass dieses Pusten kein Dauerzustand ist, sondern sporadisch auftritt. Selbst wenn ich nichts dagegen unternehme, “fängt” sich HA auch irgendwann wieder und man hört kein Pusten des kleinen Nucs.

Ein Reboot von HA löst das Problem freilich – für den Moment – auch, aber es kann sein, dass es nach einigen Stunden, manchmal aber auch erst nach einigen Tagen wieder rauscht …

Ein spezielles Ereignis – wie z.B. die Installation eines neuen Add-ons oder das Aktivieren einer Integration oder der Start eines Kamera Feeds o.ä. –, welches das Pusten ursächlich auslöst, konnte ich bisher nicht ausmachen.

[Jim_OS]

Da ich hier schon seit vielen Jahren NUCs für alles Mögliche nutze:

@metawops

dass dieses Pusten kein Dauerzustand ist, sondern sporadisch auftritt.

Mit “pusten” meinst Du ja vermutlich das sich die Drehzahl des Lüfters erhöht und Du statt eines leisen Rauschens dann ein lauteres Geräusch des Lüfters hörst. Das kann zwei Günde haben:

1. Die Software die auf dem NUC läuft verursacht eine höhere Last - passiert z.B. ganz gerne wenn man die Kiste mit hochauflösenden Videos “quält” - sodass die Temp. der CPU in die Höhe geht und der Lüfter gegensteuert. Geht die Last und somit die Temp. zurück dreht der Lüfter dann irgendwann natürlich auch wieder langsamer.
2. Das Innenleben des NUC sieht ggf. so aus
   https://community.simon42.com/uploads/default/original/3X/5/0/502af78c9e7c926f971e57f8d1faf893e58fade4.jpeg
   Homeassistant auf intel nuc hardware anfrage - #22 von Jim_OS
   und das sorgt automatisch und regelmäßig dafür das die Temp. immer mal wieder so hoch geht und ist, dass der Lüfter einen Gang höher schaltet.

Die Raum- bzw. Umgebungs-Temp. spielt dann natürlich auch noch eine Rolle.

Edit: Wie gesagt würde ich da nach dem Ausschlussprinzip vorgehen und einfach mal die einzelnen Addons nacheinandere und temporär deaktivieren. Dann kannst Du zumindest diese als mögliche Ursache ausschließen. Z.B. MotionEye oder auch den Music Assistant mal einen Tag lang nicht laufen lassen wäre ja kein Beinbruch.

VG Jim

[dp20eic]

Moin,

@metawops

Ob man da noch irgendwie reinschauen kann,

ja, mach einmal das, was da steht

Damit wird diese Ansicht erweitert,

Dann, dazu kann ich aber nicht viel sagen was da ein gesunder Wert ist, hast Du viele TCP Connections,

Und der Load, der Maschine ist auch eher hoch, das bedeutet, dass ~ 3 Prozesse auf CPU Zuteilung warten

zudem wurde trotz 8 GB Memory, der Swap genutzt

Ich vermute, dass es irgendwann einmal zu einer Auslastung des Memory gekommen ist, da wurde dann ein Prozess, Task ausgelagert, in den Swap, aber anschließend nicht wieder korrekt wieder zurückgeholt.
Es kann also sein, dass da jetzt noch ein Zombie Prozess herumschwirrt und die Kiste beschäftigt, wenn Du noch nicht gebootet hast und das Add-on Advansed ssh & Web Terminal installiert hast, dann kannst Du ja mal schauen, ob es da Zombies gibt,

# ps aux | grep 'Z'

Gerade beim Backup wird viel Memory gebraucht, da die Daten erst im Speicher gesammelt werden, um dann daraus ein Archive-File zu machen.
Eigentlich sollte der Speicher auch wieder freigegeben werden, kann aber etwas dauern, da Linux den Speicher auch für andere Schreib-, Leseoperationen nutzt.

Also einmal sauber durchstarten und beobachten, wäre jetzt meine Devise.

VG
Bernd

P.S.:

@Jim_OS

sagt jetzt ja nichts darüber aus was sie für eine Last bei HA

Doch wenn der Prozess homeassistant 160` % an CPU Zeit verbraucht, dann sind das > 1,5 Kerne, alleine dafür

Bei mir, sieht das entspannt so aus,

[Jim_OS]

@dp20eic

P.S.:

@Jim_OS

sagt jetzt ja nichts darüber aus was sie für eine Last bei HA

Doch

So genau weiß ich jetzt nicht worauf sich Dein “Doch” bezieht, aber woher weißt Du dann welcher der Addon Container und welcher Prozess daraus, die Last bei dem HA Container ggf. verursacht? Weil ich ja geschrieben hatte:

@Jim_OS

Das ist die Last von deren Container, aber das sagt jetzt ja nichts darüber aus was sie für eine Last bei HA und bei dem HA-Container erzeugen.

Wie gesagt wirken sich die Prozesse der Addons in Ihrern Containern ja auch auf den HA Container aus, nur gibt es halt keine Möglichkeit - zumindest kenne ich keine - zu erkennen ob und wie das dann der Fall ist. Siehe mein Beispiel mit MotionEye. Wenn der Container MotionEye z.B. einen Stream an den HA Container liefert und HA diesen dann verarbeiten muss, wird der HA Container dadurch belastet und er braucht mehr CPU-Leistung. Warum er diese braucht ist dann aber nicht ersichtlich.

VG Jim

[dp20eic]

Moin,

@Jim_OS

So genau weiß ich jetzt nicht worauf sich Dein “Doch” bezieht,

das Doch bezieht sich genau auf den einen Prozess

Das ist der Home Assistant itself, der da die Hauptlast verursacht. Durch seine hohe Last, bzw. das Auslasten von 1,5 CPU Kernen, kommt es dann bei allen anderen auch zu weiteren Belastungen der restlichen CPU Kerne, das System schaukelt sich hoch, wie man am Load sieht, ich wette auch da, dass wenn man das so weiter laufen lässt, würde das weiter ansteigen, weil immer häufiger Prozesse auf CPU-Zuteilung warten müssen.

Mein Bauchgefühl sagt mir, dass es bei den Backups zum Auslagern (Swap) kommt.
Der TE hat da schon eine ganz schöne Palette (17) an Add-ons am Laufen, da sagt mir mein Bauchgefühl auch, dass da dann 8 GB bei der Spitzenbelastung zu wenig ist, wenn es dem TE möglich ist, würde ich mal auf 16 GB aufrüsten, wenn es nichts bringt, kann man ja den Speicher auch wieder zurückgeben.

VG
Bernd

[Jim_OS]

Ich verstehe immer noch nicht was Du mit dem “Doch” sagen willst. Ja der HA Container hat in dem Fall eine scheinbare CPU-Auslastung von 167 %, aber darum ging es in meiner Aussage doch gar nicht. @metawops wollte wissen

@metawops

was genau beim homeassistant Container denn die Last ausmacht bzw. wie sie sich aufteilt, wer/was da am meisten braucht?

und meinte das die Addon Container selber ja nur eine geringe Last erzeugen.

@metawops

MotionEye, NodeRed und Glances selbst ein bisschen Last erzeugen,

Daraufhin habe ich gepostet das diese Last-Anzeige für die genannten Container halt nur die Last dieser Container ist, aber nichts darüber aussagt ob und was diese Container bei dem HA Container für eine Last erzeugen.

@dp20eic

Das ist der Home Assistant itself, der da die Hauptlast verursacht.

Korrekt

@dp20eic

Durch seine hohe Last, bzw. das Auslasten von 1,5 CPU Kernen, kommt es dann bei allen anderen auch zu weiteren Belastungen der restlichen CPU Kerne, das System schaukelt sich hoch, wie man am Load sieht,

Das mag zwar sein, aber a) führt eine hohe Auslastung durch den HA Container nicht zwangsläufig dazu das auch die anderen Container höher belastet werden und/oder sich dann “hochschaukeln” müssen und b) weiß man trotzdem nicht ob nicht die anderen Addon Container dafür verantwortlich sind das die Last bei dem HA Container in die Höhe geht. Genau darauf bezog sich meine Aussage.

Also noch einmal kurz und knapp: Ja der HA Container zeigt eine hohe CPU-Last an, aber ob daran ggf. die anderen Addon Container beteiligt und/oder evtl. sogar ursächlich dafür sind, weiß man nicht. Ob dadurch dann das “pusten” des NUC kommt ist dann auch noch eine ganze andere Frage.

Um das Thema hier für mich jetzt abzuschließen: Ich würde halt wie beschrieben mal das Ausschlussverfahren durchspielen.

VG Jim

[dp20eic]

Moin,

@Jim_OS

Um das Thema hier für mich jetzt abzuschließen:

ach einen habe ich da ja noch, Du siehst sehr wohl welcher Prozess da Probleme macht, dazu muss der TE aber, wie ich ja schon geschrieben habe, diese Ansicht einschalten

Aber jetzt bin ich wirklich ruhig, denn wir sind uns ja im großen einig, der TE hat ein Problem

VG
Bernd

[Jim_OS]

@dp20eic

Aber jetzt bin ich wirklich ruhig

Musst Du hier wegen mir aber nicht, aber Dein “Doch” hat mich irgendwie “getriggert”.

@dp20eic

denn wir sind uns ja im großen einig

Jepp

VG Jim

[metawops]

Liebe Mitstreiter,

ganz lieben Dank, dass ihr euch hier so aktiv beteiligt, das hilft mir sehr!

Ich habe ein kleines Update: Gestern habe ich HA einfach mal so laufen lassen und keine Maßnahmen ergriffen. Und siehe da: Das Pusten des NUC hörte irgendwann auf und die CPU Last des Haupt-„homeassistant“-Containers ging auf ca. 12-20% zurück. Der zum Plugin MotionEye gehörige Container war dann der mit der meisten Last.

Ich habe mit der z Taste die Taskanzeige aktiviert und konnte dort sehen, dass ganz oben dazu passend der „motion“ Prozess die Liste anführte.
Dann habe ich dennoch (obwohl die Last ja jetzt wieder normal war mit ca. 30%) mal das MotionEye Plugin deaktiviert und bin dadurch jetzt wieder bei einer mittleren Gesamtlast von ca. 20-25%:

Der python Prozess führt jetzt die Liste an, aber Python wird ja sicher von zahlreichen Addons bzw. vom Core benutzt, das wird man nicht ändern/verringern können.

Nach Deaktivieren des MotionEye Plugins habe ich auch mal HA (nicht den ganzen NUC) neu gestartet und wie wir sehen, bleibt der SWAP Wert immer noch auf gut 20%, scheint also beim HA Reboot nicht zurückgesetzt zu werden oder ist sofort immer wieder auf diesem Wert.

Das mit den 8 GB ==> 16 GB ist eine gute Idee, das werde ich auch mal ausprobieren, denn ihr habt recht, da sind jetzt schon einige Plugins/Addons zusammengekommen.

Auf jeden Fall super, dass ich nun Glances habe und so besser den Finger drauf legen kann, wenn der NUC mal wieder pustet!

[dp20eic]

Moin,

@metawops

Dann habe ich dennoch (obwohl die Last ja jetzt wieder normal war mit ca. 30%) mal das MotionEye Plugin deaktiviert und bin dadurch jetzt wieder bei einer mittleren Gesamtlast von ca. 20-25%:

Ja, alles was Bilder, Videos bearbeitet und analysiert, braucht CPU, oder wenn vorhanden, GPU, oder TPU, dann wird die CPU entlastet.
Das bedeutet ja, dass MotionEye “nur” ~ 5 - 10 % an der Gesamtauslastung trägt.

Was halt noch immer zu sehen ist, dass Prozesse immer noch auf CPU Zeit warten,

Ob die Last, die NodeRed verursacht ok ist, kann ich nicht sagen, das Add-on nutze ich nicht, daher

@metawops

Der python Prozess führt jetzt die Liste an, aber Python wird ja sicher von zahlreichen Addons bzw. vom Core benutzt, das wird man nicht ändern/verringern können.

Das python dort an erster Stelle steht, ja das ist normal, HA ist ja in python geschrieben
Es geht schon, aber nicht für uns normal sterbliche, dazu müsste man ganz tief in den Kaninchenbau hinabsteigen

@metawops

auch mal HA (nicht den ganzen NUC)

Das reicht nicht, HA ist ja nur ein Docker Container der im HAOS Linux läuft, der Swap wird aber vom HAOS gemanagt, das wird erst wieder auf null gehen, denn Du die ganze Kiste einmal durchstartest.

Allgemeine Aussage

die Anzeigen von top, htop, btop, glances, usw. sind Momentaufnahmen, die sich jede Sekunde ändern, will man das ganz genau wissen muss man die Metriken, also CPU, PS, Memory, usw. sammeln und dann auswerten, es gibt wohl die Möglichkeit, dass Glances die ermittelten Daten an eine influxDB senden kann, habe ich mich aber noch nicht mit beschäftigt,

InfluxDB — Glances 4.5.0.5 documentation

Glances | Grafana Labs

@metawops

Das mit den 8 GB ==> 16 GB ist eine gute Idee,

wollte Dich da nicht verleiten Geld auszugeben, denn normalerweise sind 8 GB für ein HAOS nativ auf einem PC ausreichend.
Wobei man natürlich auch nicht jede Installation über einen Kamm scheren kann, somit bestimmt die Ausnahme, die Regel

VG
Bernd

[Jim_OS]

@metawops

Das mit den 8 GB ==> 16 GB ist eine gute Idee, das werde ich auch mal ausprobieren, denn ihr habt recht, da sind jetzt schon einige Plugins/Addons zusammengekommen.

Mehr RAM ist nie verkehrt, aber auf die RAM-Auslastung kannst Du ja auch mit HA Boardmitteln immer mal wieder ein Auge werfen. Sofern da nicht irgendein Addon oder eine Integration “herumspinnen” sollte lässt sich ja leicht nachverfolgen und -vollziehen wie es mit der RAM-Auslastung so aussieht und ob es da ggf. zu einer eher ungewöhnlichen Änderung kommt, oder gekommen ist.

VG Jim

[metawops]

Ja, die InfluxDB Integration hatte ich direkt nach der Installation des Glances Addons konfiguriert und ich bekam im Log von Glances auch keinen Fehler. Somit gehe ich davon aus, dass die Daten derzeit in die InfluxDB fließen – aber kontrolliert habe ich das noch nicht!
Daher vielen Dank für den Doku-Link, das schaue ich mir auf jeden Fall an!

[dp20eic]

Moin,

@metawops

Daher vielen Dank für den Doku-Link, das schaue ich mir auf jeden Fall an!

habe es gerade einmal durchgespielt, ich betreibe alles unter Proxmox, somit ist bei mir influxDB V2 als LXC installiert, dann musste ich weil ich influxDB V2 nutze folgendes in die Konfiguration von Glances eintragen

log_level: info
process_info: true
refresh_time: 10
ssl: false
certfile: fullchain.pem
keyfile: privkey.pem
influxdb:
  enabled: true
  host: influxdb.fritz.box
  port: 8086
  interval: 60
  ssl: false
  version: 2
  username: glances
  password: ""
  database: glances
  prefix: localhost
  protocol: http
  org: glances
  bucket: glances
  token: >-
    mein_token_für_die_organisation_und_das_bucket

Einmal neu Starten und e voilà

Ob ich es nutze, muss ich schauen

VG
Bernd

P.S.: und so dann in Grafana, einiges muss noch angepasst werden, da in der HAOS VM in Proxmox, wohl einige Module fehlen und deswegen einige Daten nicht da sind.