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

Set GOMEMLIMIT when running in a containerized environment #14475

Open
marclop opened this issue Oct 30, 2024 · 2 comments
Open

Set GOMEMLIMIT when running in a containerized environment #14475

marclop opened this issue Oct 30, 2024 · 2 comments
Labels
9.0-candidate enhancement impact:high Short-term priority; add to current release, or definitely next. performance urgency:medium

Comments

@marclop
Copy link
Contributor

marclop commented Oct 30, 2024

Descripiton

how do we look at setting soft memory limit for apm-server https://pkg.go.dev/runtime/debug#SetMemoryLimit based on total memory %.

@1pkg brought up that we should probably be setting GOMEMLIMIT to 85-90% of the container memory limit (or the detected total memory when not running in containerized environments). It would avoid the APM server running out of memory when memory usage approaches that GOMEMLIMIT.

If GOMEMLIMIT is set, then we should respect the setting and not set it ourselves in the code.

Arguably, this is something that elastic-agent could do, but if we do it in APM Server, then this limit would apply to the process regardless of the mode/manner it is run.

@marclop marclop added enhancement performance impact:high Short-term priority; add to current release, or definitely next. urgency:medium labels Oct 30, 2024
@simitt
Copy link
Contributor

simitt commented Nov 11, 2024

@marclop how does this play together with the Elastic Agent potentially running multiple other processes? The GOMEMLIMIT could still be set too high in such cases.

@marclop
Copy link
Contributor Author

marclop commented Nov 11, 2024

@simitt we'd be setting the memory limit in-process, so it'd only apply to APM Server, and this doesn't take into consideration elastic-agent. Net, net it's better than what we have at the moment.

The fact that the elastic-agent has multiple processes running in a single cgroup is problematic of course, and we can only do so much about it.

We could be very conservative and set the limit to ~80-85% of the actual container's memory, but once we get close to that threshold the GC will start being very aggressive and force more and more GC cycles to keep the memory in check, so it may be detrimental in cases where there's high memory utilization. Perhaps a 90% limit would be preferable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
9.0-candidate enhancement impact:high Short-term priority; add to current release, or definitely next. performance urgency:medium
Projects
None yet
Development

No branches or pull requests

2 participants