Comment 5 for bug 1822738

The binaries themselves are quite large. Using current master (a057a16c6), and go 1.11.5, snapd is ~20MB, snap is ~15MB in size. I think it's fair to assume that whenever snapd or snap runs, most of it ends up in the memory. So calling 'snap refresh' would take up (worst case) 35MB to start with.

As I understand, the situation is blocking the refresh of some snaps. Wonder if running a simple curl like this would help:

 sudo curl -X POST --unix-socket /run/snapd.socket \
     http://localhost/v2/snaps/core \
     -d '{"action":"refresh"}'

Did some tinkering in my system with snapd and tweaking some Golang runtime options (GOGC specifically).

Right after starting:
$ ps -C snapd -ocmd,rsz,vsz,pid
CMD RSZ VSZ PID
/usr/lib/snapd/snapd 18968 3811024 6923

Running install hello && remove hello in a loop makes the RSS grow. At 23 iterations, it grew from 18100kB to 22352kB, ~180kB per iteration. The state file grew fro ~50kB, to ~140kB. Pruning the state, the state file goes back to ~50kB, RSS stays unchanged (which is expected, I wouldn't expect the allocator to give back the memory). Restarting the loop, it took 25 iterations to see RSS growing again.

This would suggest that what's taking the memory is related to the state.

The state file grows at ~4kB per install/remove loop iteration.