Hacker News new | ask | show | jobs
by AlTobey 4374 days ago
My recommendation for any server with enough RAM is to disable swap. This works on just about every system whether swap is configured or not.

That said, on my Linode I have swappiness=1 and a few GB of swap on the SSD since it is memory-constrained.

In any case, I've been running vm.swappiness=0 or 1 on nearly every machine I touch for many years now and have yet to see any problems. Swap is almost always a bad idea on modern machines.

Thanks for reading!

3 comments

I strongly disagree, and prefer the swappiness at the default level with a modestly sized swap file (1-2GB). There are lots of poorly behaved applications that will allocate RAM that they never touch again. If you turn down swappiness you end up wasting that RAM which could be better used for disk cache.

I currently have 1.2GB of swap in use on a machine that is not doing any active swapping at all; that's 1.2GB more space for caching.

[edit for spelling]

Agreed. I'm not sure if the author of the original article really understands how modern operating systems deal with memory. The point of swapping pages to disk is to avoid hitting the disk in the long run.

See: http://archive.today/FKlQ

Except thats not what causes problems in practice. You get problems with swap when your working set size exceeds your RAM. You'll always be hitting the disk as long as the offending application keeps using too much memory, and it slows down the entire system not just that one application. When you try to SSH in/log in that requires reading files from disk (or swapping things back in) which can take quite a while due the backlog caused by swapping.

If you ran out of memory and malloc returned NULL that would be better, however a lot of applications rely on overcommit so there is no good answer:

* you can run with RAM + as much swap to make all applications happy and overcommit off, and accept the long delays caused by swapping

* run with just RAM, overcommit on and no swap, and accept that your applications may be killed by the OOM killer anytime

As has been stated several times in this thread, the "swappiness" factor is not about over-committing RAM. It's about giving the kernel the freedom to say, "Hey, these pages in RAM have not been used in a long, long time. I'll swap them to disk so I can use that RAM for things that will speed things up more, like disk caching."

This is independent of applications whose working set size exceed that of physical memory.

Yeah my reply was to the "disable swap" part of the discussion, not the swappiness one.
Disabling swap means setting swappiness to 0; I'm not sure how you can talk about "disabling swap" without talking about swappiness.
> If you turn down swappiness you end up wasting that RAM which could be better used for disk cache.

Except the downside of turning swap off is that you (possibly) don't cache your disk as aggressively, but the downside for having too much swap is that ill-behaved programs can grind your entire system to a halt for minutes/hours at a time by having too big of an active dataset. We're talking multiple seconds of latency, where you can't get anything done.

For me that's way too big of a downside for gaining a few extra MB of disk cache. I'd rather have it OOM right away.

ulimit
It should be noted that memory is still in your swap even if it's read back to memory, it only gets deleted upon the memory being rewritten. So that figure isn't telling you how much data is exclusively in swap.
There are lots of poorly behaved applications that will allocate RAM that they never touch again.

If you only run applications you wrote yourself, you can prevent this behavior.

I do a lot of dev work on a machine that has 12 cores and 96 GB of RAM and I currently have swappiness set to 85.

96 GB would be plenty of memory for what I need to do--mostly I benefit from lots of filesystem caching. BUT--there's another user of this system and he does most of his work using Matlab. For the stuff he's doing, Matlab routinely sucks down 10s of gigabytes of memory. And it may stay that way for days at a time.

Without swapping, Matlab will happily sit on all that memory indefinitely, whether it's doing anything or not. Meanwhile, everything I do takes ages because of the paltry amount of memory left for FS caching.

With swapping, I can get some of that memory back for FS cache when Matlab isn't being used, and it makes a huge difference.

I'd agree with you only if you'd agree with me that:

There can never be enough RAM. ;)