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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1822738
Title:
memleak in 2.38+ ?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1822738/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
