[release/1.0] cmd/containerd-shim: aggressive memory reclamation#2058
Merged
crosbymichael merged 1 commit intocontainerd:release/1.0from Jan 25, 2018
Merged
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]> (cherry picked from commit 0e8f084) Signed-off-by: Stephen J Day <[email protected]>
Codecov Report
@@ Coverage Diff @@
## release/1.0 #2058 +/- ##
============================================
Coverage 50.57% 50.57%
============================================
Files 81 81
Lines 7163 7163
============================================
Hits 3623 3623
Misses 2847 2847
Partials 693 693
Continue to review full report at Codecov.
|
Member
Member
|
Ok, we will test this. |
Member
|
@stevvooe @Random-Liu @crosbymichael the records: the ps output:(It is 0.3% with top command) the top output:
the ps output: the top output: |
Member
|
LGTM |
Member
|
@yanxuean @miaoyq Let's do this:
If 2) doesn't show any significant cpu usage difference, we are good. But if 2) shows that the cpu usage of containerd-shim becomes significant, we may need to come back and tune the value here. |
Member
|
Looks like this was in the 1.0.2 release could someone set the 1.0.2 milestone on this one? 🤗 🙏 |
Member
|
Seems fine, but is the milestone reliable to report everything that went into a particular release? I don’t necessarily think so as it seems like for many fixes we simply set the cherry pick label and merge without setting the milestone (especially early in a cycle where we haven’t decided what/when about the next point release). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.
Signed-off-by: Stephen J Day [email protected]
(cherry picked from commit 0e8f084)
Signed-off-by: Stephen J Day [email protected]