A deep dive into Debian 13 /tmp: What's new, and what to do if you don't like it

Which is a great reason to have a big swap file now.

Note though that if you don't have swap now, and enable it, you introduce the risk of thrashing [1]

If you have swap already it doesn't matter, but I've encountered enough thrashing that I now disable swap on almost all servers I work with.

It's rare but when it happens the server usually becomes completely unresponsive, so you have to hard reset it. I'd rather that the application trying to use too much memory is killed by the oom manager and I can ssh in and fix that.

[1] https://docs.redhat.com/en/documentation/red_hat_enterprise_...

This is why I’m running with overcommit 2 and a different ratio per server purpose.

…though I’m not sure why we have to think about this in 2025 at all.

Disabling swap on servers is de-facto standard for serious deployments.

The swap story needs a serious upgrade. I think /tmp in memory is a great idea, but I also think that particular /tmp needs a swap support (ideally with compression, ZSWAP), but not the main system.

Swap always seemed more meant for desktop use. Servers you need to give the real memory expected of the application stack.

plenty of footguns in that general advice, local in memory storage services with default config, etc

I'm assuming that you monitor the service closely for OOM then adjust with demand ?

Pretty much all the guidelines about swap partitions out there reference old allocator behaviour from way over a decade ago - where you'd indeed typically run into weird issues without having a swap partition, even if you had enough RAM.

Short (and inaccurate) summary was that it'd try to use some swap even if it didn't need it yet, which made sense in the world of enough memory being too expensive, and got fixed at the cost of making the allocator way more complicated when we started having enough memory in most cases.

Nowadays typically you don't need swap unless you work on a product with some constraints, in which case you'd hand tune low memory performance anyway. Just don't buy anything with less than 32GB, and you should be good.

That's not true. Without swap, you already have the risk of thrashing. This is because Linux views all segments of code which your processes are running as clean and evictable from the cache, and therefore basically equivalent to swap, even when you have no swap. Under low-memory conditions, Linux will happily evict all clean pages, including the ones that the next process to be scheduled needs to execute from, causing thrashing. You can still get an unresponsive server under low memory conditions due to thrashing with no swap.

Setting swappiness to zero doesn't fix this. Disabling swap doesn't fix this. Disabling overcommit does fix this, but that might have unacceptable disadvantages if some of the processes you are running allocate much more RAM than they use. Installing earlyoom to prevent real low memory conditions does fix this, and is probably the best solution.

yeah pretty much, also configuring memory limits everywhere where apps allow it. some software also handles malloc failures relatively gracefully, which helps a whole lot (thank you postgres devs)

So the ideal behaviour would be:

  - for most processes no SWAP
  - for tmpfs, use RAM until a quota
  - for tmpfs, start using a swapfile above that quota

ChatGPT doesn't think it is achievable, though it thinks cgroup2 can achieve something similar.

> Disabling swap on servers is de-facto standard for serious deployments.

I guess I have not been deploying seriously over the last couple of decades because the (hardware) systems that I deploy all had some swap, even if it was only a file.

What's your swappiness ?

Ive spent the last day thinking about that, I really can't see any big negative side effects, the only issue that I'd have is being notified of OOM conditions, and that would just be a syslog regex match. Great plan.