core: Massive Memory Leak when running on Intel NUC
Home Assistant release with the issue: 0.102.0
Last working Home Assistant release (if known): 0.101.3
Operating environment (Hass.io/Docker/Windows/etc.): Hassi.io in Docker on an Intel NUC with Ubuntu 18.04.3 LTS Intel® Core™ i3-8109U CPU @ 3.00GHz 8GB RAM
Integration: All the custom components have been removed. The issue still exists without custom components
Description of problem: After a restart of Home-Assistant, everything works fine for about an hour. The RAM consumption of the Home-Assistant docker image is constant. After that, the consumption increases exponentially in steps. After another one or two hours, all the memory of the system is consumed up. Since the Linux tries to do memory swapping, the HDD LED is always on, CPU load is at 100%, and the system gets completely unresponsive. After about an hour, the Home-Assistant restarts and the system is stable again. The whole issue repeats.
I was able to take the following picture of the RAM consumption of the Home-Assistant container by using Portainer:
While the system is doing the memory swapping, I was able to connect to the host system over SSH with a lot of patience (it is extremely slow). The “top” command showed the following CPU and memory usage:
top - 09:51:56 up 14:55, 2 users, load average: 116.85, 135.05, 88.71
Tasks: 378 total, 2 running, 325 sleeping, 0 stopped, 0 zombie
%Cpu(s): 24.7 us, 31.0 sy, 0.0 ni, 0.0 id, 43.8 wa, 0.0 hi, 0.5 si, 0.0 st
KiB Mem : 8035168 total, 113200 free, 7783184 used, 138784 buff/cache
KiB Swap: 2097148 total, 0 free, 2097148 used. 25556 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9516 root 20 0 1332188 8892 0 S 100.6 0.1 27:35.67 grafana-server
59 root 20 0 0 0 0 R 99.7 0.0 274:51.01 kswapd0
1715 root 20 0 2386572 18528 0 S 8.0 0.2 23:34.93 dockerd
16466 root 20 0 8252480 6.866g 0 S 2.7 89.6 16:36.29 python3
6437 root 20 0 385560 3264 156 D 1.2 0.0 0:23.55 php7.2
3425 root 20 0 118424 8924 0 S 0.9 0.1 9:56.59 python3
26847 root 20 0 449932 5320 2176 D 0.9 0.1 8:38.62 Xorg
6465 root 20 0 109104 768 0 S 0.6 0.0 1:54.53 containerd-shim
The PID 16466 belongs to the main Home-Assistant container.
Additional information: I have tried it with several versions. The issue is introduced with version 0.102.0. Updating to 0.102.3 does not work. The problem still exists in the 0.103.0b0.
I am not a software engineer. Therefore, any help on further narrowing the issue down is highly appreciated.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 39 (11 by maintainers)
I’m now testing 0.103.4 with Deconz 4.1. @Kane610 Thanks for your help!!!
EDIT Until now, no problems!
It does indeed look like the battery value 0 would create multiple sensors trackers, I will evaluate to see what happens
@agners no, the tracker is used to keep a check of devices not currently reporting battery state, which is common on a newly restarted system. The problem is that a battery value of ‘0’ would evaluate if sensor.battery: as false. Which if a sensor reports battery state of 0 would for each tracker create a new tracker exponentially increasing the amounts of sensors. Lets see if it improves your situation with next release
What integrations you enabled and configured? Start disabling those one by one to narrow the scope.