Because it's typically not an option in these kinds of VMs – you'd need to create a swapfile, enable it, before you could launch the first DNF command. Ideally, disable it after, as chances are a certain bookseller is billing you per IOPS.
It's completely out of the questions for (e.g. cgroups) limited containers, which can't even tell the kernel to enable swap.
Best, Marcus
On 8/29/22 12:12, Roberto Ragusa wrote:
On 8/29/22 09:19, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Aug 22, 2022 at 05:44:26PM -0700, Adam Williamson wrote:
it's quite an old bug, but up until recently, the summary was apparently accurate - dnf would run out of memory with 512M of RAM, but was OK with 1G. However, as of quite recently, on F36 at least (not sure if anyone's explicitly tested F37), dnf operations are commonly failing on VMs/containers with 1G of RAM due to running out of RAM and getting OOM-killed.
The discussion in the bug indicates that this memory growth is related to loading of the full filepath dataset. We have been discussing splitting out the non-primary-filepath-data (i.e. paths that are not /etc, /usr/bin, /usr/sbin), out into a separate lazilly-loaded file.
If it is currently loading stuff that is not really used in the computation, this is a perfect case where swap could help (things would be written to swap and then forgot on deallocation). Unfortunately, swap is for some reason considered out-of-fashion, even in these memory constrained set ups.
Regards.