Re: dnf processing causes oom-kill
On Sat, 2022-10-29 at 01:29 +0000, George R Goffe via test wrote:
Hi,
I've been seeing this problem for a few days now.
I start a "normal" dnf upgrade that fails to complete because something in dnf
or perhaps a script that triggers an oom-kill event.
I have seen this in a VM host (8G swap) and in a VM guest (2G swap)... both FC38.
I wrote a bug on the bugzilla for this...
https://bugzilla.redhat.com/show_bug.cgi?id=2138369
Has anyone seen this?
Is there info that would be needed to discover just why this is happening? Please let me
know.
I've also noticed much more OOM killing going on in the openQA tests of
Rawhide updates in the last few weeks, I think it started with kernel
6.1. It seems particularly bad on KDE tests, I'm not sure if this is
just due to KDE using more memory than other environments or what. I've
had to introduce various mitigations. We used to allot only 2G of RAM
to each VM in openQA tests on x86_64; I first bumped it to 3G, now I'm
up to 4G for KDE tests. I also tweaked the tests to stop the desktop
environment before doing the `dnf update` to install the packages from
the update. Even with that, it still happens sometimes.
It seems to be a bit better with more recent 6.1 kernels, and it's
better with non-debug than debug kernels (the builds like "kernel-
6.1.0-0.rc2.21.fc38" are non-debug, builds like "kernel-6.1.0-
0.rc2.20221028git23758867219c.24.fc38" are debug - basically if it's a
dated snapshot it's debug). But there definitely seems to be some kind
of issue. I filed https://bugzilla.redhat.com/show_bug.cgi?id=2133829
about it.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net