On Mon, Mar 6, 2023 at 4:09 AM Alexander Ploumistos <alex.ploumistos@xxxxxxxxx> wrote: > > Hello, > > TL;DR: > DNF memory usage during upgrades from F37 to F38 on a couple of Fedora > Cloud images (with 2 GB of RAM each) led to oomd kicking in and > killing the upgrade process. It might be worth looking into before the > final (also beta?) release. > > > The longer story: > I have a couple of hosted VMs, which started their lives as Fedora > Cloud 27 and which I have been upgrading to the next Fedora release > via dnf-plugin-system-upgrade. These VMs run very few things, mainly > some PHP applications on Apache and a good chunk of the PHP stack, > some scheduled network scripts, a private rpm repository, OpenVPN and > Wireguard nodes and when I am far from my main computer and koji or > copr happen to be busy, I test things in mock on them. These VMs are > near clones of each other, so usually only one of them is up at any > moment. > > I've never had an issue with memory use up to now and when the systems > aren't building packages, they seldom require more than 200 MB of RAM. > What's more, there's the default swap-on-zram, so they should be more > than happy memory-wise with 2 GB of RAM. > > I tried to upgrade one VM to F38, to see what problems I might face > and after the packages had been downloaded, I lost the ssh connection > as DNF was running the transaction test, right after a successful > transaction check. I repeated the whole thing a couple more times, > until I remembered that oomd is there and sure enough, DNF had been > consuming 1-1.3 GB until oomd decided to kill it. Well, actually it > killed my entire session and not just DNF. I tried running the upgrade > inside a screen (the GNU one) session and I came back to an empty > session. The transaction involved the upgrade of 1620 packages, with > a total size of 1.2 GB. I think the difference between that and the > previous upgrade F36 to F37) is around 100 MB and 30 or 40 packages. > In each of the failed attempts, the memory pressure was 55 to 78% for > more than 20 seconds, according to systemd-oomd. The exact same issues > appeared when upgrading the second VM. > > Eventually I did the upgrade by doubling the available RAM to 4 GB > (and then set it back to 2), but perhaps this could be a problem for > others, especially those who pay for cloud-based resources. Is DNF > supposed to be a legitimate target for systemd-oomd? Conversely, is > DNF supposed to use up so much memory? I know I'm late to the party, but I think this is still worth taking a look at. I have two small Fedora servers that used to run just fine with 1 GB of RAM, but I needed to up that to 2 GB for the upgrade to Fedora 36 (thanks to DNF running out of memory otherwise). Reading the original post, it sounds like I'll need to up that again soon, either for the upgrade to Fedora 37 or 38? I don't really want to throw money out the window just because DNF eats up all the memory it can :( Additionally, the smallest offerings of popular VPS providers have just 1 or 2 GB of RAM, is Fedora Server no longer supported on systems like these? Do we need to update the documentation for system requirements? Ping cloud hosting providers that they shouldn't offer installing Fedora on configurations with too little RAM? There's also lots of SBCs with limited RAM - are Fedora users on these devices supposed to reinstall Fedora every six months, since in-place upgrades might no longer be possible? Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue