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

The jnlp container in each slave consumes about 200M memories #721

Closed
tianya2010 opened this issue Jul 26, 2017 · 4 comments
Closed

The jnlp container in each slave consumes about 200M memories #721

tianya2010 opened this issue Jul 26, 2017 · 4 comments

Comments

@tianya2010
Copy link

tianya2010 commented Jul 26, 2017

We used the jenkins-kubernetes plugin to set up a test framework, and we found that the jnlp-container in each jenkins slave consumes about 200M memories. Is it normal or there is something wrong?

Is there any way to constrain the memory consumption? Will such limit affects the performance?

@oleg-nenashev
Copy link
Member

200M is an expected consumption if Java starts with the default options. You can tweak Java options and try to decrease the memory footprint, but I am not sure it's possible to achieve much difference

@tianya2010
Copy link
Author

Thanks for the suggestion.

The jnlp container is started by jenkins-kubernetes plugin by default, and how can I tweak the java options for this container instead of other affect the other working containers in a slave?

@oleg-nenashev
Copy link
Member

It makes sense to as Kubernetes maintainers. @carlossg fyi

@carlossg
Copy link
Contributor

You can see how to customize it at https://github.com/jenkinsci/kubernetes-plugin#pipeline-support

lemeurherve referenced this issue in lemeurherve/jenkinsci-docker-inbound-agent Nov 19, 2023
Fixed Jenkins UID and GID to be consistent with the Jenkins Docker image
@lemeurherve lemeurherve transferred this issue from jenkinsci/docker-inbound-agent Jan 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants