Anyone else having performance issues after upgrading to 0.118.4? My system is now running like a dog…, although there is no increase in CPU usage, everything is very sluggish…
Downgraded to 0.118.3 and everything is fast and responsive once again, any ideas I. what this could be ?
These are the changes between x.3 and x.4, do any of them look like they may apply to your use case?
Nope, don’t use any of those integrations, apart from templates, and the ones I have do not use scientific number notation or have variables with leading zeros…
couple of questions?
On what kind of device is it running?
How large is the .db file?
Are you using any custom integrations or hacs?
Pi3B+
Hass OS 4.17
DB 405Mb
Sonoff & Govee custom integrations (HACS not installed)
System Health
Home Assistant Core Integration
version: 0.118.3
installation_type: Home Assistant OS
dev: false
hassio: true
docker: true
virtualenv: false
python_version: 3.8.6
os_name: Linux
os_version: 4.19.127-v7
arch: armv7l
timezone: Europe/London
Home Assistant Supervisor
host_os: HassOS 4.17
update_channel: stable
supervisor_version: 2020.11.0
docker_version: 19.03.12
disk_total: 57.8 GB
disk_used: 6.1 GB
healthy: true
supported: true
board: rpi3
supervisor_api: ok
version_api: ok
installed_addons: Terminal & SSH (8.10.0), AdGuard Home (2.6.1), Check Home Assistant configuration (3.6.0), Duck DNS (1.12.4), File editor (5.2.0), Home Assistant Google Drive Backup (0.102.0)
Lovelace
dashboards: 2
mode: storage
views: 8
resources: 3
And when I say everything is sluggish, I mean everything, from loading, to turning simple lights on/off, drawing graphs etc. Even ssh’ing to the box took 10 seconds to connect, and after downgrading to 118.3 it’s back to connecting instantly.
Just off the top of my head… the kernel version does not look correct for a recent version of HassOS, I would expect 5.4.x LTS.
When you upgrade, did it upgrade the OS to 4.18 as well?
Nope, no notifications in the supervisor to update the core OS… should there be ?
~ $ ha os info
board: rpi3
boot: A
update_available: false
version: "4.17"
version_latest: "4.17"
~ $
4.18 was released last week… so yes… however I think they pulled it due to boot failure, you can still do the upgrade if you make a copy of the current boot script, upgrade, then use a usb live os to replace the script
Ok, so pulled is pulled…, but I still don’t see how this would account from my issue as the Core and OS builds should be independent…
I dont either, but since your slowness seems independent of cpu usage combined with slow ssh I figured looking at everything might find some connection, also it seems the rpi uses the 4.19 kernel, at least until the next major update, which is using 5.4
Well, it’s obviously just me, as no one else is reporting this as an issue…, with every HA config being unique, there is no chance of tracking down what the underlying probkem is. Fingers crossed the next release is not similarly crippled…
Not sure whether it is the same problem or not, but since updating a couple weeks ago I’ve started noticing the system (Raspbian on a PI 3 *) freezing up completely every now and then. When it happens, HA does not respond, I cannot connect via SSH to the docker ssh add-on or to the host OS. The only thing the PI still responds to is a ping. The PI console itself is also frozen.
If I leave it at that is usually recovers after a few hours. It might be related to memory usage, because the only time I seem to have triggered this myself I was updating a few addons all at the same time, and it seemed to me that memory usage shot up some and swap usage reached 100%.
Right now I have tmux with htop, dmesg and a tail of the ha log file going on the PI’s terminal, so next time it happens I hope to at least see some indication of what happened.
( * ) note that I’m not complaining, since my setup is unsupported; this is entirely on me, but I’m sharing since the symptoms seem a bit similar - the system becomes supper sluggish before seizing up.
Are both of you running on sd cards or ssds?
I’m on an SD card, currently working perfectly on 0.118.3, CPU usage under 10%, instant response to all controls etc.
You’re not alone.
After upgrading a few weeks ago (probably to 1.118.0) I also went from a super fast system to major slow down, but only on the UI. Other interfaces work fine, namely the automations, via HomeKit and ssh all respond quickly. But the UI is unusable. There is no CPU usage.
I’m running supervised on docker in a dedicated mini-pc (shuttlebox) with a SSD drive. I also heavily use templates but I’ve commented all out, no difference.
I had grafana and influx dB, stopped both of them, no difference.
Been removing some devices from config, including efergy platform which just stopped working, but to no avail.
Going to update to 0.118.4 but I’m keeping hopes down.
arch: amd64
audio_input: null
audio_output: null
boot: true
image: homeassistant/qemux86-64-homeassistant
ip_address: 172.30.32.1
last_version: 0.118.4
machine: qemux86-64
port: 8123
ssl: true
update_available: true
version: 0.118.1
version_latest: 0.118.4
wait_boot: 600
watchdog: true
I’m running on an SD card, yes.
One thing I noticed, my swap file was always near capacity not long after a reboot. I’ve changed it from the default 100MB to 300MB and have not had a problem since - it’s been about 36h since this change, swap usage is around 50% and the system is responsive and stable.
Update: upgrade to 0.118.4 did not improve anything.
But, today, I had to change routers in my house and temporarily the network changed lan IPs. After resetting it all back to normal network lan ips, had to restart HA, and voila, it started to work super quickly again.
So I suspect some sort of network related issue, if anyone has this UI problem I recommend to restart network or some other form of network rebuilt.
I have UI slowness and hangs. In logs, it hangs when getting this message. Has to do with cameras… i have 4.
If I refresh, browser hangs… if i close browser and re-open, fast again. Non-UI wise everything is normal speed.
2020-12-09 08:22:53 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_protocol.py", line 422, in _handle_request
resp = await self._request_handler(request)
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_app.py", line 499, in _handle
resp = await handler(request)
File "/usr/local/lib/python3.8/site-packages/aiohttp/web_middlewares.py", line 118, in impl
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 18, in request_context_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 72, in ban_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 127, in auth_middleware
return await handler(request)
File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 129, in handle
result = await result
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 502, in get
return await self.handle(request, camera)
File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 537, in handle
return await camera.handle_async_mjpeg_stream(request)
File "/usr/src/homeassistant/homeassistant/components/ring/camera.py", line 136, in handle_async_mjpeg_stream
await stream.close()
File "/usr/local/lib/python3.8/site-packages/haffmpeg/core.py", line 158, in close
await self._loop.run_in_executor(None, _close)
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/local/lib/python3.8/site-packages/haffmpeg/core.py", line 153, in _close
self._proc.stdin.write(b"q")
BrokenPipeError: [Errno 32] Broken pipe
looks like Ring
I’ve come across this problem upgrading from 115 to 118 but it looks like an SD card problem even though I always make sure to get the A2 class cards. The upgrade was literally killing my RPi3 system, even ping was gone. I’ve recovered from a saved image (of 115) and the upgrade works fine on a different card.