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

Backport of docker_logger: reorder imports to save memory into release/1.2.x #14876

Merged

Conversation

hc-github-team-nomad-core
Copy link
Contributor

Backport

This PR is auto-generated from #14875 to be assessed for backporting due to the inclusion of the label backport/1.2.x.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

The below text is copied from the body of the original PR.


Nomad runs one logmon process and also one docker_logger process for each running allocation. A naive look at memory usage shows 10-30 MB of RSS, but a closer look shows that most of this memory (ex. all but ~2MB for logmon) is shared (Shared_Clean in Linux pmap).

But a heap dump of docker_logger shows that it currently has an extra ~2500 KiB of heap (anonymously-mapped unshared memory) used for init blocks coming from the agent code (ex. mostly regexes from go-version, structs, and the Consul SDK). The packages for running logmon, docker_logger, and executor have an init block that parses os.Args to drop into their own logic, which prevents them from loading all the rest of the agent code and saves on memory, so this was unexpected.

It looks like we accidentally reordered the imports in main to undo some of the work originally done in 404d2d4. This changeset restores the ordering. A follow-up heap dump shows this saves ~2MB of unshared RSS per docker_logger process.

@hashicorp-cla
Copy link

hashicorp-cla commented Oct 11, 2022

CLA assistant check
All committers have signed the CLA.

Nomad runs one logmon process and also one docker_logger process for each
running allocation. A naive look at memory usage shows 10-30 MB of RSS, but a
closer look shows that most of this memory (ex. all but ~2MB for logmon) is
shared (`Shared_Clean` in Linux pmap).

But a heap dump of docker_logger shows that it currently has an extra ~2500 KiB
of heap (anonymously-mapped unshared memory) used for init blocks coming from
the agent code (ex. mostly regexes from go-version, structs, and the Consul
SDK). The packages for running logmon, docker_logger, and executor have an init
block that parses `os.Args` to drop into their own logic, which prevents them
from loading all the rest of the agent code and saves on memory, so this was
unexpected.

It looks like we accidentally reordered the imports in main to undo some of the
work originally done in 404d2d4. This changeset
restores the ordering. A follow-up heap dump shows this saves ~2MB of unshared
RSS per docker_logger process.
@tgross tgross force-pushed the backport/docker_logger_memory/heavily-sterling-terrier branch from 27d707b to 5e225a4 Compare October 11, 2022 17:25
@tgross
Copy link
Member

tgross commented Oct 11, 2022

Turns out 1.2.x didn't need a backport because the original reordering wasn't found here. I've cherry-picked the non-changelog changes anyways so that the docstring warning is there.

@tgross tgross merged commit ef13918 into release/1.2.x Oct 11, 2022
@tgross tgross deleted the backport/docker_logger_memory/heavily-sterling-terrier branch October 11, 2022 17:26
@github-actions
Copy link

github-actions bot commented Feb 9, 2023

I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants