Stop making swap partitions–use swap files instead

It does not if you switch swapp off and use zram instead. I am typing right now on such a setup wityh 16 GiB ram and it occasionally, once a week or so, kills my firefox due to oom.

If you are you using disk swap - not sure why would if you have a SSD, but I once heard some justification for doing that - then install early OOM.

I had a 1GB Debian VM which started freezing (requiring a hard reboot) after a routine aptitude upgrade to apply security patches. It was indeed caused by low memory, but not out of memory as there was still enough swap space remaining.

The culprit turned out to be the kernel itself, and rolling back to a 6.1 series kernel made the problem go away. I see that Linus's love for vibe-coding is already paying dividends.

> does anyone know why

In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it.

Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?

This is called an oomkiller. The kernel has one but it kicks in very late and the kernel prefers to do page trashing instead of killing processes.

systemd-oomd should be integrated in systemd, you can configure it to your liking and see if it improves your problem.

Set `/sys/kernel/mm/lru_gen/min_ttl_ms` at boot (see https://docs.kernel.org/admin-guide/mm/multigen_lru.html).

User-space OOM killers never really worked for me and imo are not a proper solution anyway. This option instead lets you make the kernel OOM killer actually work for desktop use.

Currently have it set to `1000` and it works very well for me (don't remember the last time I had a full system freeze due to OOM).

OS are designed to fully exploit available resources, Linux tries its best before triggering an OOM kill.

I recommend using the earlyoom if you want more aggresive oom kill:

https://github.com/rfjakob/earlyoom

The README contains a lot of interesting information.

This has finally been fixed in the latest Ubuntu version (26), it now force closes the culprit.

Just mentioning this in case it's helpful:

If you know ahead of time which programs / processes are at risk of unacceptably high memory usage, check out "ulimit".

I always install earlyoom for that reason

not tangential at all...try setting up a swap partition

That’s a good call out. I’ve never used ZFS on root. Been a ZFS user on Linux since the FUSE days but it has never seemed particular well suited (O_DIRECT support came late, ARC/page cache redundancy, etc)

It also doesn't sound like a particularly good idea on BTRFS, judging by the linked documentation:

https://btrfs.readthedocs.io/en/latest/Swapfile.html

In practice, there’s a potentially tremendous impact if you’re using a spinning metal disk. Sectors at the beginning of the disk (which is at the outer edge) are read/written way faster than sectors at the end. File systems tend to prefer writing files at the beginning. If the file system has been used for ‘a long time’ then it’s either fragmented - or it’s been defragmented and the free space is at the slow end of the drive.

One nice thing about swap partitions is that they can be fixed in place even before OS installation.

(Of course, if you’re using swap enough for this to be a huge factor, you probably have bigger problems. But I haven’t done the math.)

Swap files are very fragile if you are using hibernation. For FDE I prefer LVM-over-LUKS and a dedicate partition

How often are you needing to change partition geometry after install, on a server?

Unless you use the Linux package that does manage swap files dynamically.