I'm having an aggressive memory leak issue I can't place: Within 5 minutes the 4GB are full. htop and top don't show a massive program growing unbouded. `df` doesn't show a tmpfs that is too large. Only `slabtop` is imforative:

 

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
26638624 26638624  99%    0.12K 832457       32   3329828K kmalloc-128

 

So `kmalloc-128` is growing without bounds. As I understand it kmalloc is a collection of smaller memory allocations? I've tried using a previous kernel version (5.10.16 and 5.10.12) but nada.

 

I've disabled docker, and that along with omv were the only services running. Any suggestions would be great!

Can you share more info because cannot say much based on the few input you provided

 

ps -o pid,user,%mem,command ax | sort -b -k3 -r


top -b -n 1

 

and the link generated by armbianmonitor -u

 

https://linuxhint.com/check_memory_usage_process_linux/

Sadly I seem to have broken my install because the RAM got filled while I was using `armbian-config` to revert a kernel version. With regards to top/ps; As i mentioned nothing pops up with a large usage.

 

I've got a fresh install booting now, I can see if the problem reproduces. (And at what step.)

Okay, it has something to do with 'btrfs-cleaner'. After mounting my RAID kmalloc-128 starts growing. Steps I've taken were install, define root password & user name+password, `apt-get update && apt-get upgrade`, reboot and mount my RAID. `umount` also hangs. (Probably because btrfs-cleaner is running.)

 

 

# ps -o pid,user,%mem,command ax | sort -b -k3 -r
  PID USER     %MEM COMMAND
 1381 root      0.4 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal
  777 root      0.4 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers
  784 root      0.3 /usr/sbin/NetworkManager --no-daemon
[...]

 

 

# top -b -n 1
top - 13:28:22 up 5 min,  3 users,  load average: 3.83, 2.02, 0.84
Tasks: 179 total,   3 running, 176 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.7 us, 20.9 sy,  0.0 ni, 78.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3799.0 total,   1598.0 free,   1755.0 used,    446.0 buff/cache
MiB Swap:   1899.5 total,   1899.5 free,      0.0 used.   1884.1 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 2540 root      20   0       0      0      0 R  66.7   0.0   2:32.56 btrfs-cleaner
 2705 root      20   0    8948   3028   2664 R   9.5   0.1   0:00.09 top
 2688 root      20   0    7188   3360   2604 S   4.8   0.1   0:01.15 htop
    1 root      20   0  165100   9372   7052 S   0.0   0.2   0:04.59 systemd
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.03 kthreadd
[...]

 

`armbianmonitor -u`: http://ix.io/2REF

After (instantly) disabling quotas the issue is remedied. Even though I have 214 subvolumes it seems ridiculous to me that quotas would use enough RAM to cripple a system. Is this a (upstream) bug?

 

When i read "Performance issues" I think slow IO speed, not crippling RAM usage.