Problem: HA reagiert nicht mehr da CPU usage bei 80-100%

[J_B_O]

Hallo Zusammen,
ich habe seit einige Tagen das Problem, dass HA nicht mehr reagiert (login im Frontend nicht mehr möglich ) da die CPU Auslastung über 80% liegt.
Hier Infos zu meiner HA Installation:

Code: Alles auswählen

{
  "home_assistant": {
    "installation_type": "Home Assistant Container",
    "version": "2022.11.2",
    "dev": false,
    "hassio": false,
    "virtualenv": false,
    "python_version": "3.10.7",
    "docker": true,
    "arch": "x86_64",
    "timezone": "Europe/Berlin",
    "os_name": "Linux",
    "os_version": "5.10.60-qnap",
    "run_as_root": true
  },

Ich habe vor paar Tagen HA auf 2022.11.2, Update von HACS auf 1.28.3, Tibber Puls (Der Pulse übermittelt deine Verbrauchsdaten in Echtzeit an unsere Tibber-App) an meinem Stromzähler in Betrieb genommen. Tibber Intergation war vorher schon aktiv.

Als das erste Mal der HA die hohe CPU Load hatte konnte ich den Fehler auf Tibber zurückführen. Hier gibt es wohl ein API-Call limit (ERROR (MainThread) [tibber] Error connecting to Tibber, resp code: 429). Danach habe die alle Entity von Tibber deaktiviert und nur zwei (Verbrauch und Einspeisung) wieder aktiviert. das lief dann 2-3 Tage ohne Probleme.

Heute Früh hatte HA wieder über 80% und der Login im Frontend war nicht möglich. Ich hatte natürlich wieder Tibber in Verdacht, aber im Log nichts dazu zu finden. Stattdessen:
ERROR (MainThread) [custom_components.hacs] Request exception for 'https://api.github.com/rate_limit' with - Cannot connect to host api.github.com:443 ssl:default

HACS hat API connection limit bei 5000 pro Stunde. Wenn ich die Calls überprüfe, steht da auch net viel drin (meist ist used zwischen 10 und 140)
Überprüfen mit: curl -i -u YOUR_GITHUB_USER:YOUR_GITHUB_PERSONAL_TOKEN 'https://api.github.com/users/YOUR_GITHUB_USER'

Code: Alles auswählen

github-authentication-token-expiration: 2022-12-20 10:35:19 +0100
x-github-media-type: github.v3; format=json
x-ratelimit-limit: 5000
x-ratelimit-remaining: 4997
x-ratelimit-reset: 1668944023
x-ratelimit-used: 3

Nun stellen sich mir zwei Fragen:

• warum HACS wohl mal austickt um mehr als 5000 Call die Stunde abfeuert
• warum HA so was nicht abfangen kann und die CPU load hoch geht. Es kommen ja auch Fehler zurück, dass die URL nicht erreichbar ist.

Hat jemand von Euch schon mal ähnliche Probleme gehabt? Ist echt blöd die Situation, da HA jederzeit unerwartet stehen bleibt.

[Osorkon]

Auf welcher Hardware läuft Dein Home Assistant?
HA OS im Einsatz, oder eine andere Art der Installation?

Bei der Installation von HACS wird deutlich drauf hingewiesen,
dass Du das auf eigene Gefahr tust. Es zu Problemen kommen kann, da Du externe Quellen verwenden tust.
Nicht die Home Assistant Entwickler sind verantwortlich, das HACS Komponente richtig funktionieren, sonder die einzelne Entwickler die die Sachen in HACS zur Verfügung stellen.

Gruß
Osorkon

[J_B_O]

Auf welcher Hardware läuft Dein Home Assistant?

Läuft als Docker auf QNAP NAS

HA OS im Einsatz, oder eine andere Art der Installation?

Home Assistent Container (siehe Code oben in meinem Threat), also ohne Supervisor.

Mir ist die Konstellation um HACS bewusst, Danke aber nochmals für den Hinweis.

[J_B_O]

Update:
Mittlerweile bin ich mir gar nicht mehr so sicher, ob die hohe CPU Load und damit verbunden das nicht reagieren des HA Frontends was mit den beiden oben beschriebene Sachen zu tun hat. Eben war es gerade wieder so weit und die Load ist über 80%, im Logfile kann ich aber dieses mal gar nichts außergewöhnliches erkennen.

Hat jemand eine Idee, wie ich der Ursache auf den Grund kommen kann?

[Jim_OS]

Ich habe HA zwar nicht im Docker sondern in einer VM am laufen, aber ich glaube auch nicht das es etwas mit HACS und den Calls zu tun hat, sprich das mit dem limit und remaining 5.000 ist ja normal.

Bei mir sehen die Werte so aus:

Code: Alles auswählen

resources	
core:	
limit	60
remaining	57
reset	1668954856
used	3
resource	"core"

graphql:	
limit	0
remaining	0
reset	1668956152
used	0
resource	"graphql"

integration_manifest:	
limit	5000
remaining	5000
reset	1668956152
used	0
resource	"integration_manifest"

search:	
limit	10
remaining	10
reset	1668952502
used	0
resource	"search"

rate:	
limit	60
remaining	57
reset	1668954856
used	3
resource	"core"

Bist Du mal alle HA-Logs durchgegangen, sprich nicht nur das Home Assistant Core Log?
Hast Du mal bei allen Add-ons die CPU- und RAM-Auslastung angeschaut?

Ansonsten bleibt Dir wohl nur Schritt für Schritt alle Integrationen und Add-ons durchzugehen, diese zu deaktivieren und wieder zu aktivieren und zu schauen ob Du ggf. irgendwelche Unterschiede feststellen kannst. Sprich ob das Problem bei/mit einer bestimmten Integration, oder bei/mit einem bestimmten Add-on auftritt.

BTW: Das das dann 2-3 Tage ohne Probleme lief ist auch etwas seltsam und deutet ja eher darauf hin das da irgendetwas "voll läuft" und Ressourcen "frist". Das Problem kann bei HA liegen, aber auch bei Docker auf dem QNAP. Da wäre dann wohl suchen im HA-Forum nach Docker und ggf. QNAP und möglichen Problemen aktuell, aber auch in der Vergangenheit angesagt.

VG Jim

[J_B_O]

Ich hatte bisher nur im HA Core log geschaut. Wüsste auch nicht, wo ich schauen müsste,
da bei mir HA als Container läuft und da gibt es kein Supervisor und Add-on Store.
Die CPU Load betrifft auch nur den HA Docker. Alle anderen Docker (Unifi, diplicati, File Browser) haben keine Auffälligkeiten, sprich die CPU Load ist bei 1-5 %. NAS CPU Load ist auch nicht zu hoch.

[Jim_OS]

Da ich HA nicht per Docker benutze weiß ich leider nicht wie das dann aussieht und welche Möglichkeiten es dann da gibt. Du hast nicht die Möglichkeit Dir unter Einstellungen --> System --> Log die verschiedenen Logs anzuschauen? Also so/da:

HA_Logs.png

Wie ist das dann mit den Add-ons? Auch da hat man im Normalfall die Möglichkeit sich die Auslastung anzeigen zu lassen.

HA_Addon_System.png

Auch kann man sich dort die Logs zu dem Add-on anschauen.

Das die CPU Load nur den HA Docker betrifft hatte ich schon verstanden. Das kann in erster Linie daran liegen das HA - warum auch immer - diese Last verursacht, aber eben auch an der Docker-Umsetzung beim QNAP NAS selber. D.h. weil das Zusammenspiel zwischen HA und QNAP-Docker ggf. nicht richtig funktioniert. Nur weil andere Docker Anwendungen wie z.B. Unifi, diplicati, File Browser "keine Auffälligkeiten" haben, heißt das noch nicht das HA im QNAP-Docker dann auch richtig und immer funktioniert.
Bsp.: Ein HA Add-on greift z.B. auf bestimmte Ordner zu, die vielleicht bei einer Docker Install. gar nicht (oder woanders) vorhanden sind. Oder ein HA Add-on will z.B. MQTT Daten abrufen, aber z.B. der Mosquitto broker ist bei einer Docker Install. ggf. anders eingerichtet. Oder die Docker-Install kann z.B. nicht auf Port 1883 zugreifen. Usw.

Unabhängig davon würde ich Dir empfehlen - sofern Du dies nicht eh schon gemacht haben solltest - Dein QNAP TS-253A mit RAM aufzurüsten (8 GB) und dann HA in einer VM laufen zu lassen. Die HA-Grundinstallation in einer VM dauert vielleicht 10 - 15 min. Eine Docker-Installation ist immer nur eine "Notlösung" und unterliegt schon einigen Einschränkungen, bzw. kann es dabei durch das Docker-Grundgerüst zu Problemen kommen die machmal schwer nachvollziehbar sind.

VG Jim

[carsten_h]

Wie ist das dann mit den Add-ons?

In der Docker-Variante kann man keine Add-Ons benutzen!

[Jim_OS]

OK ich dachte das betrifft nur Add-ons über den Add-on Store (ja die "Compare Installation Methods" Tabelle/Übersicht kenne ich) und Add-ons ließen sich bei der Docker-Variante trotzdem zumindest irgendwie manuell installieren. OK noch ein Grund mehr nicht die Docker-Variante zu benutzen.

[carsten_h]

Add-ons ließen sich bei der Docker-Variante trotzdem zumindest irgendwie manuell installieren.

Sicher kannst Du die manuell als Container per Hand installieren. Dann muß man aber selber auf Updates achten etc.
Das würde ich dann aber nicht als Add-On bezeichnen.

Ich lasse ja auch deCONZ auf einem anderen Pi laufen und muß mich dort natürlich um Updates selber kümmern. Das ist aber kein Add-On. Die deCONZ Integration habe ich aber trotzdem installiert, da die auch mit dem deCONZ auf dem anderen Pi spricht.

[Jim_OS]

Ne ich meinte schon direkt unter HA und nicht als extra Container. Aber wie schon gesagt von HA per Docker habe ich keine Ahnung.

@J_B_O
Bzgl. VM auf QNAP: Ich habe eben mal nachgeschaut. Die Celeron CPU in Deinem QNAP ist zwar etwas älter als die Celeron J3355 in meinem Synology DS218+ NAS, aber dafür hat die bei Deinem QNAP zumindest 4 Core. Ich gehe davon aus das HA in einer VM auf Deinem QNAP NAS ziemlich problemlos und auch performant genug laufen sollte, sofern Du mehr als die Standard-RAM (2 oder 4 GB) installiert hast, bzw. installieren würdest.

Auf meiner DS218+ laufen folgende VMs (nur zu Testzwecken)

Syn_VMs.png

und sofern ich nicht mehrere davon parallel laufen lasse läuft HA durchaus performant genug um damit arbeiten zu können.

VG Jim

[carsten_h]

Ne ich meinte schon direkt unter HA und nicht als extra Container.

"Unter" HA geht ja nicht. Das was dort im Docker Container läuft ist der "Home Assistant Core" mehr nicht. Also das was bei Dir auch als Container in Home Assistant OS parallel zu den Add-Ons läuft.

[Jim_OS]

Das Problem hat sich dann wohl zwischenzeitlich erledigt:

Den Systemmonitor habe ich auch seit gestern Mittag am Laufen. Seit dem gab es keine Auffälligkeiten mehr und die Werte sind im "normalen Bereich".

[J_B_O]

Sorry, dass ich mich nicht eher gemeldet habe. Auf Grund einer Knie-OP kann ich nur begrenzt Zeit am Rechner verbringen.

Also leider hat sich das Problem nicht erledigt und gestern Abend zwischen 16 und 17h ist es wieder aufgetreten.
Im portainer hatte der HA Container wieder 100% CPU Load.

Im HA im Systemmonitor war die CPU "Normal", sie war bei 15% als der HA abgeschmiert ist (weiss leider nicht wie ich einen Screenshot hier einfügen kann). Aber die Systemmonitor Integration im HA bezieht ja die Werte vom Hostsystem (also bei mir das NAS). Somit würde ich das NAS nun ausschließen. Habe mir auch logs auf dem NAS angeschaut und nix auffälliges gesehen.

Zum Vorschlag auf VM umziehen: Das möchte ich nicht. Es würde in dem Fall auch nicht weiter helfen. Da ich nur HA Core und keinen Add-Ons habe, kann ich die Add-ons schon mal als Fehlerquelle ausschließen. Bis vor einigen Tagen lief der HA im Docker auch mehrere Monate lang ohne Probleme. Da ich vor paar Tagen zuviele Änderungen gemacht habe (Update HA, Integrationen von Shells umgestellt, Integrationen von Tibber, Miehle, ..., Update HACS, Update Portainer, ...) wird es mit Rollback nicht einfacher. Bin nun an dem Punkt alles nochmal neu aufzusetzten Step by Step.

[Jim_OS]

Ich habe eben mal - just for fun - HA im Docker auf meiner DS218+ installiert. In der Tat gibt es dort ja nicht die unterschiedlichen Logs, oder die Anzeigen für Auslastung bei HA usw. Somit sorry falls ich Dich da ggf. auf eine falsche Fährte geführt haben sollte.

In der Docker-Übersicht der DS218+ kann ich mir dann die laufenden Prozesse, die CPU- und Speicherauslastung und das Potokoll anschauen. Also wohl so ähnlich wie Du bei Deinem QNAP.

Zu Deinem Problem kann ich daher also nichts sagen, weil ich die Docker-Variante halt nicht nutze.

VG Jim

[J_B_O]

Danke Euch ... habe gestern HA neu aufgesetzt, erst mal nur mit den für mich wichtigsten Integrationen (Hue, Homematic (mittels HACS, Systemmonitor, Workday, Sun, Moon), Unifi, Shelly. Die Dashboards und Automationen konnten leicht per YAML wieder hergestellt werden. Nun werde ich noch ein Monitoring für den Docker suchen und dann warte ich mal ab, wie es sich die Tage verhält.

[m4d-maNu]

Hilft dir nun zwar nicht wirklich weiter, vor allem da du HA eh neu aufgesetzt hast, mit HA 2022.11.2 im Docker, hatte ich auch immer wiedermal ein hängendes Frontend, es war aber nur das Fronted, ein neues aufrufen der Weboberfläche behob das Problem. Mit 2022.11.3 ist es nun besser geworden aber auch da passiert es nun ab und zu noch.

Und ich habe HACS bis dato nicht in Verwendung gehabt, da ich nur begrenzt einen Sinn darin sehe, alles was über HACS sich besorgt werden kann, kann sich ja auch Manuell installiert werden.

[J_B_O]

Und ich habe HACS bis dato nicht in Verwendung gehabt, da ich nur begrenzt einen Sinn darin sehe, alles was über HACS sich besorgt werden kann, kann sich ja auch Manuell installiert werden.

Verwechselt du HACS vielleicht mit dem Superviser? Im HACS (Home Assistant Community Store) befinden sich beispielsweise Integrationen, die es bei den "offiziellen" HA Integration nicht (oder noch nicht gibt). Ich verwende aus dem HACS
die Homematic Integration. Bevor ich neu aufgesetzt und "abgespeckt" hatte, verwendete ich aus dem HACS noch Gardena (für Rasenmährobbi), Audi, Miele. Das gibt es alles sonst nicht im HA.

[Jim_OS]

m4d-maNu hatte je breits geschrieben: "alles was über HACS sich besorgt werden kann, kann sich ja auch Manuell installiert werden." D.h. Du/man braucht kein HACS um die von Dir genannten Integrationen (Gardena, Audi connect, Miele ...) zu installieren. Geschätzt 99 % aller Integrationen bei HACS lassen sich natürlich auch manuell installieren.

Bsp. Gardena: https://github.com/py-smart-gardena/has ... art-system siehe unter Installation --> Manual installation

Die Installation per HACS ist nur der etwas "bequemere" Weg.

VG Jim

[m4d-maNu]

Verwechselt du HACS vielleicht mit dem Superviser?

[/quote]Nein, ich meine schon den HACS und nicht den Supervisor.

m HACS (Home Assistant Community Store) befinden sich beispielsweise Integrationen, die es bei den "offiziellen" HA Integration nicht (oder noch nicht gibt).

Ja stimmt, über HACS kann einfach mit einen Klick (zumindest sehr oft, Hass Hue Icons benötigt noch einen Manuell Eintrag in der Configurations.yaml zusätzlich) eine neue Integration oder auch Frontend installiert werden, die es so im HomeAssistenten nicht gibt aber eigentlich alle können auch Manuell installiert werden, mit entsprechenden Ergänzungen in der Configurations.yaml und oder Installation im config/www Ordner.

[J_B_O]

Ah, OK. Danke Euch für die Aufklärung. Wieder was gelernt.