Left it run for a few hours today. The issue now is I can see it increasing as a trend from the graph but it’s happening very very slowly over the last 24h compared to going 38 to 90% over 1-2h before
My question though is how do I interpret the output profile publishes in the logs?
It is outputting the number of each object type in memory. If you post some of the log I can give you better guidance
OK was removing everything not coming from Profiler otherwise was getting crowded
This is everything since starting it last night. Also in the process of me doing this it seems I caught it right in the act. Now even CPU is going up. Was slowly going up and all of a sudden sky rocketed
EDIT: I take it back whatever caused the abnormal CPU/RAM of the last 20mins has now died down. RAM is back at the previous but elevated levels of around 47% for now
Is the python process actually increasing in memory, or is it a subprocess?
I may have the same issue, but wat more specifically do you mean was the error and solution you applied?
I had found the culprit Huawei_solar
When I disable this component my cpu drops
I have opened an issue Last version high cpu usage · Issue #15 · Emilv2/huawei_solar · GitHub
I have been asked by @bdraco to provide a py-spy dump in connection with a performance bug.
I have spent hours now trying to find out how to login to the host of HassOS, how to put ssh addon in non protected mode, how to run a command inside a container. I am stuck now in the error similar to above.
And even if I try to eat my way through the 161 posts in this thread I cannot find a working step by step how to run a py-spy dump
What is a working step by step instruction? I cannot find it anywhere. I have tried myself now many hours trying to do my best to sort it out but I am stuck.
and I also wonder what and how to clean up afterwards
Did anything change recently that would have resurrected this issue?
I started getting high CPU usage recently and HA became sluggish it was almost not functional (Ok maybe it wasn’t that bad but it’s definitely below expectation).
I went thru all of my integrations and removed everything and nothing helped…until I remembered about the discussion of the “unavailable sensors” template causing issues.
So I had two sensors set up using different templates for a few months now with no issues…until recently.
After removing those two sensors everything calmed down and CPU load is back to normal.
here is a screenshot of the differences between with the templates and without. It’s pretty stark:
the first low section is with neither template active. then the 100% load is with both active. then I disabled one of them. re-enabled both. then disabled both again.
here are the templates:
sensor:
- platform: template
sensors:
unavailable_entities:
#entity_id: sensor.time
friendly_name: Unavailable Entities
unit_of_measurement: items
icon_template: >
{% if states('sensor.unavailable_entities')|int == 0 %} mdi:check-circle
{% else %} mdi:alert-circle
{% endif %}
value_template: >
{% set update = states('sensor.time') %}
{{expand(states.binary_sensor, states.sensor, states.switch, states.variable, states.media_player, states.light)|selectattr('state', 'in', ['unavailable','unknown','none'])
|reject('in', expand('group.entity_blacklist'))
|reject('eq', states.group.entity_blacklist)
|list|length}}
attribute_templates:
entities: >
{% set update = states('sensor.time') %}
{{expand(states.binary_sensor, states.sensor, states.switch, states.variable, states.media_player, states.light)|selectattr('state', 'in', ['unavailable','unknown','none'])
|reject('in', expand('group.entity_blacklist'))
|reject('eq' , states.group.entity_blacklist)
|reject('eq' , states.group.battery_status)
|map(attribute='entity_id')|list|join(', ')}}
sensors_unavailable:
friendly_name: 'Entities that need attention'
entity_id: sensor.time
value_template: >
{{ states | selectattr('state', 'in', ['unavailable', 'unknown', 'none']) | list | length }}
attribute_templates:
entities: >
{{ states | selectattr('state', 'in', ['unavailable', 'unknown', 'none']) | map(attribute='entity_id') | list | join('\n') }}
Again, did something change recently that would have caused the issue to re-appear?
So to add another datapoint, I was seeing a large amount of CPU usage and my startup would hang if I had default-config or dhcp enabled (which is part of default-config). Disabling ipv6 on my router (latest openwrt) seems to have fixed it and its now faster than I ever remember it being. My cpu usage on my NUC has dropped from ~12% to <2%.
Hello @bdraco
would you like to help me out? I wish I could read the speed scope py-spy profile by myself. Maybe you can tell me what to look at?
Should I pm you the .svg file?
Feel free to send it
Hi everyone
What is the consensus on this issue? Is this individual?
I am running it on NUC and noticed CPU usage increase as well
_worker can be ignored as its idle time.
eintr_retry_call looks like a bug in pyudev. It could be related to Stack trace from MonitorObserver thread · Issue #194 · pyudev/pyudev · GitHub
write is from a tarfile / backup creation.
I have an Intel Nuc and its always running between 60-100 cpu use. I have tried the profiler and created to files. But I have no idea how to look at the files. Can someone help me or guide me how to do that? 
I believe the docs on the profiler page give a few options on how to view the files:
I also have this issue with mostly 100% cpu. But I’m wondering why.
Can someone read these files, as I can’t get to read it with those programs: HERE
What about addons. Which ones do you have installed?
I’m running HA in docker. I only have integrations:
Wemo
Marantz
Viera VT60 DLNA
Slimme meter
Google Cast
Govee
HACS
Brother Printer
Libreelec
LG webOS Smart TV
Lifx
Home
Mobile app
MQTT
Netgear
Node-RED companion
Profiler
Squeezebox
Tuya
Xiaomi Miio
Sun
