To SWAP or not to SWAP?

P

proxuser77

Member
Aug 12, 2023
95
89
23
Hi everyone.

Since it's pretty much impossible to buy workstation or server-grade hardware with 128GB or more right now, unless you've won the lottery, I got my hands on two 1L PCs with 64GB each, which I plan to use to supplement my existing Proxmox server, which also has 64GB of RAM and is starting to reach its limits. I set up both mini PCs with a ZFS RAID1 (please no discussion about ZFS on consumer-grade hardware. I know the consumer-grade SSDs in those won't last forever with ZFS, and yes, no ECC, etc., but I'm just a home user, and want to be able to use the advantages of ZFS.

Now to the actual topic:

After setting up both, I noticed that no SWAP partition is created by default anymore (apparently since Proxmox 5.3, as I then discovered, and yes, I also found the relevant section in the docs, which basically says it's better to use enough physical RAM. And yes, of course, I get that, but on the other hand, it doesn't hurt to have SWAP just in case, right? Or at least that's what I always thougt.

Now my question to the experts here:

What is the actual reasoning for not creating a SWAP partition by default, or at least leave a few GB of space by default in case you need it later?

...and do you think I should leave it as it is, or should I set it up again and then leave space for a SWAP partition?

Thanks for your thoughts and suggestions on this. :-)
 
Last edited:
Thanks to both of you for the links.

ZRAM does indeed seem to be a viable solution, despite the warning in the wiki that it could cause lockups. The post to which the warning refers is from 2019, so I guess this isn't a widespread issue anymore.

I'm still a bit on the fence though, and I'll do some more reading, but for now, I'm leaning towards doing nothing, i.e. neither setting up a SWAP partition nor ZRAM, seeing how it goes, and then adding ZRAM later should it become necessary.
 
Last edited:
When both memory and ZRAM is completely full it can cause a lockup/freeze. That's why I use nohang. Earlyoom is another option.
 
  • Like
Reactions: Johannes S
Impact said:
When both memory and ZRAM is completely full it can cause a lockup/freeze.
Click to expand...
That's exactly why I'm struggling with the topic. As a non-expert with limited understanding of how SWAP works in detail, I always thought, SWAP is mainly needed to prevent exactly that from happening. And somehow, I could never quite wrap my head around the idea of using a RAM disk for SWAP, i.e. using this very thing that's running low to store the things in it that otherwise don't fit in anymore. That sounds kind of illogical to me, despite compression and everything. ;)

On my existing host (which I have rebuilt as well, and would like to avoid to rebuilding it again because everything is already set up), I previously had an 8GB SWAP partition and had set swappiness to 0, and SWAP was then actually always empty. Hence my conclusion or intention that I don't really need SWAP (especially now that I can distribute the workload across two additional hosts and even with the extra stuff that is still to come, none of the three hosts are likely to reach their RAM capacity in the foreseeable future.

However, if something ever goes haywire. which, if I understand correctly, mainly concerns containers, it might be useful to have SWAP. SWAP would then, so to speak, 'expand' memory to the disk, which, of course, performs very poorly, but would be better than the system freezing completely. So, that's why I also still consider a SWAP partition.

But I might be missing something obvious here.

Impact said:
That's why I use nohang.
Click to expand...
I have two probably rather naive questions about this...

1. Could you just use nohang then, or in other words, do you still need SWAP if you use a low memory handler like nohang?

2. Can I just install it and it works reasonably well in its default configuration with Proxmox and ZRAM, or do I have to dlve deep into it and “tune” it?
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back