Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: gc unused exec processes #1129

Merged
merged 1 commit into from
Apr 18, 2018
Merged

feature: gc unused exec processes #1129

merged 1 commit into from
Apr 18, 2018

Conversation

Ace-Tang
Copy link
Contributor

add gc to clean unused exec processes

Signed-off-by: Ace-Tang [email protected]

Ⅰ. Describe what this PR did

add gc to clean unused exec processes, gc process will be triggered every 5 minutes.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how you did it

Ⅳ. Describe how to verify it

Ⅴ. Special notes for reviews

@codecov-io
Copy link

codecov-io commented Apr 15, 2018

Codecov Report

Merging #1129 into master will increase coverage by 0.42%.
The diff coverage is 26.92%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1129      +/-   ##
==========================================
+ Coverage   15.19%   15.62%   +0.42%     
==========================================
  Files         173      173              
  Lines        9705     9846     +141     
==========================================
+ Hits         1475     1538      +63     
- Misses       8125     8197      +72     
- Partials      105      111       +6
Impacted Files Coverage Δ
daemon/mgr/container_types.go 15.38% <ø> (ø) ⬆️
daemon/mgr/container.go 0% <0%> (ø) ⬆️
pkg/collect/safe_map.go 96.22% <77.77%> (-3.78%) ⬇️
pkg/kernel/kernel.go 72.72% <0%> (-27.28%) ⬇️
pkg/utils/utils.go 78.15% <0%> (-4.55%) ⬇️
client/volume_remove.go 100% <0%> (ø) ⬆️
cli/cli.go 0% <0%> (ø) ⬆️
client/client.go 33.33% <0%> (+2.89%) ⬆️

@@ -1564,6 +1566,35 @@ func (mgr *ContainerManager) setBaseFS(ctx context.Context, meta *ContainerMeta,
meta.BaseFS = filepath.Join(mgr.Config.HomeDir, "containerd/state", "io.containerd.runtime.v1.linux", namespaces.Default, info.Name, "rootfs")
}

// execProcessGC cleans unused exec processes config every 5 minutes.
func (mgr *ContainerManager) execProcessGC() {
for range time.Tick(5 * time.Minute) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do not hard code here in the detailed implementation. Maybe we can define this variable in the front of some file, and make this a const variable.
WDYT? @Ace-Tang

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I do not think time clock need to be a variable.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this feature very much, and it indeed brings much benefit to improve memory efficiency. While I totally agree with the initial point. While to be honest, I am not on a tiny point of this part. How about making this 5 * time.Minute to be a const variable of DefaultExecGCInterval?

/cc @rudyfly @Letty5411

Copy link
Contributor Author

@Ace-Tang Ace-Tang Apr 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have already update that, but forgot to push. @allencloud .
And I make it a variable, not const.

for id, v := range execProcesses {
execConfig, ok := v.(*ContainerExecConfig)
if !ok {
logrus.Warnf("get uncorrect exec config: %v", v)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/uncorrect/incorrect

@@ -25,6 +25,19 @@ func (m *SafeMap) Get(k string) *Value {
return &Value{v, ok}
}

// Values returns all key-values stored in map
func (m *SafeMap) Values() map[string]interface{} {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If m.inner equals to nil, do we need to return nil instead of map[string]interface{}?

Just a little confused on this.

Copy link
Contributor Author

@Ace-Tang Ace-Tang Apr 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

m.inner can not be nil, since

func NewSafeMap() *SafeMap {
 	return &SafeMap{
 		inner: make(map[string]interface{}, 16),
 	}
 }

and if inner is not initialled, it won't be panic.

Copy link
Collaborator

@allencloud allencloud Apr 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Someone has some potential possibility that they do not use NewSafeMap() to create a SafeMap. If they create it via safetyMap := &SafeMap{}, it works fine. But, if they call function safetyMap.Values(), it could panic. Right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same reason with #1132 .
for range a nil map will never cause panic, since nil value will convert to a nil map(map[] ), that add a nil check is useless.

@pouchrobot pouchrobot added size/L and removed size/M labels Apr 17, 2018
@Ace-Tang
Copy link
Contributor Author

updated, and add more test for collect pkg, @allencloud

add gc to clean unused exec processes
add Values funtion to collect pkg, and make the
pkg more robust.

Signed-off-by: Ace-Tang <[email protected]>
@pouchrobot pouchrobot added size/M and removed size/L labels Apr 17, 2018
@allencloud
Copy link
Collaborator

Thanks a lot for your update. LGTM

@pouchrobot pouchrobot added the LGTM one maintainer or community participant agrees to merge the pull reuqest. label Apr 18, 2018
@allencloud allencloud merged commit 5caea36 into AliyunContainerService:master Apr 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature LGTM one maintainer or community participant agrees to merge the pull reuqest. size/M
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants