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

Dagger memory usage #862

Merged
merged 3 commits into from
Dec 10, 2024
Merged

Dagger memory usage #862

merged 3 commits into from
Dec 10, 2024

Conversation

wkz
Copy link
Contributor

@wkz wkz commented Dec 9, 2024

Description

When reconfiguring the system many times (seen during regression testing), the RAM usage of keeping all generations around starts to add up.

A tmpfs file, no matter how small, will always consume at least one full page (4k). So one generation of tiny setup scripts and log files can end up locking ⚠️ 1 MB ⚠️ of memory.

Therefore: Once we're done with a generation, archive it in a compressed tarball, which typically fits inside a single 4k page. Limit the total number of archives to 10. This should give full visibility into the history of a system in all normal situations, while still allowing hammering systems with reconfig cycles in testing scenarios.

Checklist

Tick relevant boxes, this PR is-a or has-a:

  • Bugfix
    • Regression tests
    • ChangeLog updates (for next release)
  • Feature
    • YANG model change => revision updated?
    • Regression tests added?
    • ChangeLog updates (for next release)
    • Documentation added?
  • Test changes
    • Checked in changed Readme.adoc (make test-spec)
    • Added new test to group Readme.adoc and yaml file
  • Code style update (formatting, renaming)
  • Refactoring (please detail in commit messages)
  • Build related changes
  • Documentation content changes
    • ChangeLog updated (for major changes)
  • Other (please describe):

wkz added 3 commits December 9, 2024 13:35
When reconfiguring the system many times (seen during regression
testing), the RAM usage of keeping all generations around starts to
add up.

A tmpfs file, no matter how small, will always consume at least one
full page (4k). So one generation of tiny setup scripts and log files
can end up locking a 1 MB (!) of memory.

Therefore: Once we're done with a generation, archive it in a
compressed tarball, which typically fits inside a single 4k
page. Limit the total number of archives to 10. This should give full
visibility into the history of a system in all normal situations,
while still allowing hammering systems with reconfig cycles in testing
scenarios.
Previously, the generation number was only increased for successful
evolutions. This led to a confusing state in /run/net where multiple
<N>-ABANDONED-<date> directories could exist, with the same value of
N.

Move to a scheme where the generation increments every time we evolve,
even if the evolution fails. If multiple consecutive evolutions fail,
we can now unabiguously determine the order in which they were
executed.
@wkz wkz requested a review from mattiaswal December 10, 2024 08:52
Copy link
Contributor

@troglobit troglobit left a comment

Choose a reason for hiding this comment

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

Nicely done!

@wkz wkz merged commit ec64c15 into main Dec 10, 2024
6 checks passed
@wkz wkz deleted the dagger-mem-usage branch December 10, 2024 09:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants