-
Notifications
You must be signed in to change notification settings - Fork 192
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
High memory usage when updating #4687
Comments
Yeah, dnf actually hits this too: https://bugzilla.redhat.com/show_bug.cgi?id=1907030.
Not exactly. :) As soon as you use layering, dependency resolution must happen client-side (we need to know what other packages to pull in) and so rpm-ostree has to download repodata just like dnf would (and in fact uses the same stack, hence why it's hitting this same issue). Without layering, updates are purely OSTree-based. That said, in theory we could have a layering mode where we don't do any libsolv dependency resolution because all the required packages are explicitly provided and librpm can confirm that the deps are satisfied, but that's not the common case. |
You can also switch to layering and avoid paying the rpm penalty per machine. |
Oh hang on: if there is no layering there is no libsolve involvement? That changes quite a few things. Thanks for pointing that out!
I wish CoreOS had a container layering mode that could be used just like toolbox (but using the actual booted OS as base layer instead of downloading a Workstation image). No manual maintenance, updates alongside the base system, that would also make that not so common case you described pretty common since the starting point of the delta would be the raw ostree image.
Thanks for the suggestion! I'll have to try both methods (that, and using a tailscale container). I hope the complexity will stay low because in spite of the problem at hand, layering base packages like this has been a bliss. |
Yes. It's been that way since the creation of rpm-ostree. If no rpms are layered, content is fetched via ostree which does no depsolving, just replicates a filesystem tree efficiently. Now part of the idea of github.com/containers/bootc is to be a new container-native frontend that very clearly does not involve any rpm at all for the container flow. |
In any case sorry this is not an rpm-ostree issue, it's a Fedora issue per https://bugzilla.redhat.com/show_bug.cgi?id=1907030 (Note e.g. CentOS has many many fewer packages and hence uses much less memory) |
Host system details
Provide the output of
rpm-ostree status
.Expected vs actual behavior
High memory usage (much more that before last update date:
Expected:
Steps to reproduce it
Non-DNF systems really don't have that problem. It used to work well. AFAIK we don't have 800MB of metadata we need to have in memory all the time.
rpm-ostree
applies transactional updates, starting from a pre-resolved base image: there is no or little dependency resolution necessary.Would you like to work on the issue?
No.
The text was updated successfully, but these errors were encountered: