5 ms·

I have tried to forego swap because I had hoped that it would avoid swap thrashing, where performance goes into the toilet; I'd rather a process was killed but

I have tried to forego swap because I had hoped that it would avoid swap thrashing, where performance goes into the toilet; I'd rather a process was killed but I could still access the system, than be unable to login to it. But I've found that even with no/little swap, the system can get into high memory pressure situations (even easier because it can't swap out unused pages of libraries and the like), and still go into a sort of thrashing state even though it isn't swapping. My main workstation is a Dell XPS15 with 32GB of RAM and I had 8GB of swap on it. About every month the system load would skyrocket even though it had plenty of mem+cache+swap available. If I killed off my browser and slack, load would return to normal, and I could use the system for a few more days or a week before it happened again. I struggled with this for a year or more, before (for reason's I don't remember), I added another 8GB of swap. Within the next day 80% of the extra swap was used right up. I decided to swapoff that new file and create a 64GB swapfile and just see what happened. It got to around 20-30GB IIRC before it leveled off. And, more importantly, over the next 100+ days I never had that thrashing happen again. That was with Ubuntu 22.04. I just recently (May-ish) switched over to a NixOS setup with 64GB of swapfile, and it's been very stable.

SoftTalker 5d ago
The old rule of thumb used to be 2x actual RAM for your swap file/partition size. That's probably not right with today's RAM sizes but I'm not sure what the current rule is. I just go with the Ubuntu installer default but I don't know if that's just a fixed number or computed in some way from amount of RAM available.
- Sohcahtoa82 5d ago
  > The old rule of thumb used to be 2x actual RAM for your swap file/partition size. Which was always a dumbass rule that made no logical sense. Like, I remember a time when I had 4 GB of RAM and had my swap set to 8 GB. Then I upgraded to 16 GB of RAM. Theoretically, I shouldn't even need a swap file anymore, since my old setup would max at 12 GB and yet I never had OOM problems, but that "rule of thumb" would dictate that I should increase my swap to 32 GB.
  - al_borland 5d ago
    This is why they went on to say it doesn’t make sense with modern RAM sizes. I remember when I first came across this rule when getting into Linux for the first time. If memory serves, I had 256MB of RAM, so I set swap for 512MB, which seems perfectly cromulent.
- lotharcable 5d ago
  Some of that was driven by people wanting hibernation to be reliable. The other part was that it kinda matched the money you were spending on the machine. The guy with 128MB of ram could likely afford to spend the extra disk space on a swap partition then the guy stuck with just 32MB.
lokar 5d ago
Read only pages (most of libraries and binaries) get “paged out” to the file they came from, not swap. (They obviously don’t page out, they are just discarded and read again when needed)
- anyfoo 5d ago
  Yes, only dirty (i.e. modified) pages profit from getting paged out to swap. But while I don't have any hard data, I imagine that depending on the workload, there can be a punch of pages that are read during initialization, or a one-off workload, and never being read or freed up afterwards. Just try activating a swap file, and see if it gets any usage, despite memory pressure being low.
  - lokar 5d ago
    When we looked it was always tiny
lotharcable 5d ago
In the distant past there was plenty of times I tried to fix dying web servers by logging in and restarting a rogue process or cleaning up a memory leak... only to have my SSH session and shell sessions being repeatedly killed by OOMs. Not as big of a problem as it used to be. Both because OOM killer has gotten better and also web servers are such a commodity that remotely cycling them isn't going to cause a outage and is the quickest and cleanest way to get them back into production.

SoftTalker 5d ago

The old rule of thumb used to be 2x actual RAM for your swap file/partition size. That's probably not right with today's RAM sizes but I'm not sure what the current rule is. I just go with the Ubuntu installer default but I don't know if that's just a fixed number or computed in some way from amount of RAM available.

Sohcahtoa82 5d ago
> The old rule of thumb used to be 2x actual RAM for your swap file/partition size. Which was always a dumbass rule that made no logical sense. Like, I remember a time when I had 4 GB of RAM and had my swap set to 8 GB. Then I upgraded to 16 GB of RAM. Theoretically, I shouldn't even need a swap file anymore, since my old setup would max at 12 GB and yet I never had OOM problems, but that "rule of thumb" would dictate that I should increase my swap to 32 GB.
- al_borland 5d ago
  This is why they went on to say it doesn’t make sense with modern RAM sizes. I remember when I first came across this rule when getting into Linux for the first time. If memory serves, I had 256MB of RAM, so I set swap for 512MB, which seems perfectly cromulent.
lotharcable 5d ago
Some of that was driven by people wanting hibernation to be reliable. The other part was that it kinda matched the money you were spending on the machine. The guy with 128MB of ram could likely afford to spend the extra disk space on a swap partition then the guy stuck with just 32MB.

lokar 5d ago

Read only pages (most of libraries and binaries) get “paged out” to the file they came from, not swap. (They obviously don’t page out, they are just discarded and read again when needed)

anyfoo 5d ago
Yes, only dirty (i.e. modified) pages profit from getting paged out to swap. But while I don't have any hard data, I imagine that depending on the workload, there can be a punch of pages that are read during initialization, or a one-off workload, and never being read or freed up afterwards. Just try activating a swap file, and see if it gets any usage, despite memory pressure being low.
- lokar 5d ago
  When we looked it was always tiny

lotharcable 5d ago

In the distant past there was plenty of times I tried to fix dying web servers by logging in and restarting a rogue process or cleaning up a memory leak... only to have my SSH session and shell sessions being repeatedly killed by OOMs. Not as big of a problem as it used to be. Both because OOM killer has gotten better and also web servers are such a commodity that remotely cycling them isn't going to cause a outage and is the quickest and cleanest way to get them back into production.