31–40 of 137 posts
Swap on servers somewhat defeats the purpose of ECC memory: your program state is now subject to complex IO path that is not end-to-end checksum protected. Also you get unpredictable performance. So typically: swap off on servers. Do they have a server story?
Using the example from the article, extracting an archive. Surely that use case is entity not possible using in-memory? What happens if you're dealing with a not-unreasonable 100gb archive? Who runs around with 100gb+ of swap?!
Who runs around with a 100gb+ /tmp partition? Our default server images come with a 4.4GB /tmp partition...
My /tmp is my default folder for downloads and temporary work. It will grow 100GB+ easily.
The third mitigating feature the article forgot to mention is that tmpfs can get paged out to the swap partition. If you drop a large file there and forget it, it will all end up in the swap partition if applications are demanding more memory.
what swap partition? I meant this sort of jokingly. I think have a few linux systems that were never configured with swap partitions or swapfiles.
Earlier quoted context omitted.
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 ki…
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 ki…
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.
Earlier quoted context omitted.
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.
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.
https://www.redhat.com/en/blog/polyinstantiating-tmp-and-var...