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: Memory 0 102 3 (no custom)

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)

Most upvoted comments

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.