% for i in {1..1000}; do docker run -dit --name shell_$i busybox sh; done
% for i in {1..1000}; do docker rm -f shell_$i; done
You'll notice that /proc/meminfo shows a large amount of overcommited memory. If you look at pprof output from the daemon, there is nowhere near that much memory being used (so it's not a goroutine leak or something like that). If you then re-run the first command the memory still rises, which shouldn't happen because it has ample unused heap space.
Well, you can try running the following testcase:
% for i in {1..1000}; do docker run -dit --name shell_$i busybox sh; done
% for i in {1..1000}; do docker rm -f shell_$i; done
You'll notice that /proc/meminfo shows a large amount of overcommited memory. If you look at pprof output from the daemon, there is nowhere near that much memory being used (so it's not a goroutine leak or something like that). If you then re-run the first command the memory still rises, which shouldn't happen because it has ample unused heap space.
So yes, it's a real bug that I'm debugging.