cmd/containerd-shim: aggressive memory reclamation#2055
cmd/containerd-shim: aggressive memory reclamation#2055stevvooe merged 1 commit intocontainerd:masterfrom
Conversation
To avoid having the shim hold on to too much memory, we've made a few adjustments to favor more aggressive reclamation of memory from the operating system. Typically, this would be negligible, on the order of a few megabytes, but this is impactful when running several containers. The first fix is to lower the threshold used to determine when to run the garbage collector. The second runs `runtime/debug.FreeOSMemory` at a regular interval. Under test, this result in a sustained memory usage of around 3.7 MB. Signed-off-by: Stephen J Day <[email protected]>
| } | ||
|
|
||
| func main() { | ||
| debug.SetGCPercent(10) |
There was a problem hiding this comment.
looks good, but could/should these be configurable to let folks tune?
There was a problem hiding this comment.
we can add a flag on the shim post merge, i'm cool with that
There was a problem hiding this comment.
How does -Xio.containerd.ShimMemoryUsage=keepitlow sound?
There was a problem hiding this comment.
I'd prefer a runtime flag instead of a build time one
There was a problem hiding this comment.
@mlaventure Sorry, this was a JVM joke.
We can add a flag in a follow up, but I don't think it is important to tune for this use case.
There was a problem hiding this comment.
Yes, not tuning for "just" this use case was the point of my let it be configurable comment :-)
Codecov Report
@@ Coverage Diff @@
## master #2055 +/- ##
==========================================
- Coverage 50.35% 45.43% -4.93%
==========================================
Files 84 96 +12
Lines 7393 9429 +2036
==========================================
+ Hits 3723 4284 +561
- Misses 2964 4435 +1471
- Partials 706 710 +4
Continue to review full report at Codecov.
|
|
LGTM |
[release/1.0] cmd/containerd-shim: aggressive memory reclamation
5 participants
To avoid having the shim hold on to too much memory, we've made a few
adjustments to favor more aggressive reclamation of memory from the
operating system. Typically, this would be negligible, on the order of a
few megabytes, but this is impactful when running several containers.
The first fix is to lower the threshold used to determine when to run
the garbage collector. The second runs
runtime/debug.FreeOSMemoryat aregular interval.
Under test, this result in a sustained memory usage of around 3.7 MB.
Fixes #2020
Signed-off-by: Stephen J Day [email protected]