Wandering Thoughts archives

2017-02-03

What it's sensible to use a bunch of Unix swap space for

I've long written that you don't want too much swap space because if you try to actively use more RAM than your machine actually has, swap space basically just gives you more rope. Your machine is not going to perform very well (or at all) while things are busy frantically paging memory in and out, so it's usually better to just have things fail immediately. But there are sensible uses for decent amounts of swap space, even if they're relatively rare, and today I feel like trying to run them down.

First off, you almost always want a bit of swap space configured even if you never plan to use it, generally something on the order of a few hundred megabytes up to a gigabyte. The sad reality of life is that many Unix kernels contains code that simply assumes that you have some amount of swap space, even just a bit (partly because very few kernel developers even try to test with no swap set up). If you have no swap space configured at all, this code can malfunction in various unhappy ways. Feeding your system 256 MB or 512 MB for swap is a small price to pay to avoid running into these corner cases.

But that's just a little space, not a bunch of it. So here are some uses for an appreciable amount of swap space that I can think of:

  • Hibernating a laptop or other machine that can do this (under some configurations).

  • If you have a memory based tmpfs /tmp or other scratch directory, which are increasingly popular and common (although I think it's a bad idea). If you have one and you expect to use much space in it and be under overall memory pressure, you probably want as much swap space as you ever expect something to use in your /tmp, and then probably some more for insurance.

    (Unfortunately there are likely to be a lot of programs that will write large files to /tmp under the right circumstances, especially if they get fed unusually large inputs. This is one reason I don't like tmpfs /tmp.)

  • If you have a system that insists on some relatively strong form of 'strict overcommit', where it wants to reserve RAM or swap space for almost all of the memory that your programs may potentially use, and you have programs that allocate a lot of memory that they don't touch. Here you're using a bunch of swap space to basically trick the system's memory accounting, so that it's happy letting programs allocate memory they'll never use.

  • If you have mostly inactive programs that use an appreciable amount of memory plus programs with occasional (or periodic) short term spike demands for most or almost all of the memory on the machine. With sufficient swap space, the spike demand will push everything else out to swap, run to completion, and then everything else will slowly wake up and page back in. You won't enjoy the system having to page back in a few gigabytes of memory, but it probably beats the alternatives (including splitting things out to separate machines).

    (Bonus points are awarded here if you have a scheduling system that actively SIGSTOPs or otherwise totally suspends the lower priority programs so that they don't even try to run during the demand spike.)

  • If you have programs with (significant) memory leaks and what they lose track of is dirty memory (as opposed to clean memory that they allocated but never touched). As leaked memory, the program is basically never going to touch it again, but as dirty memory it can only live in RAM or swap and clearly you'd rather have it live in swap.

  • If you have programs that use a lot of memory but touch most of it only very rarely, very slowly, or both. Unlike leaked memory, the program will look at this memory again at some point but in the mean time it wastes your valuable RAM, so you would rather page it out to swap space for now and then pay the performance impact of swapping it back in later.

    (At this point you're teetering on the edge. If you've misjudged how much memory the program will want to look at how fast, you can shove your overall system right into memory starvation and swap death.)

  • If the most important thing is that the system not crash, even if it's not doing very much else besides swapping madly. Such systems are probably doing their important work either in the kernel (using reserved memory) or in programs that are locked into memory, so that they keep going even while the rest of the system is more or less locked in swap death. This may or may not work very well in practice; among other issues, kernels often want memory themselves and so may get entangled in what theoretically is only 'unimportant' user space swap death.

As it probably shows from how I described these things, the further down the list you go the more dubious I get about how wise these hacks are (and I maintain that most of them are hacks). Generally you should have a pretty strong confidence that you know exactly what your overall system is going to do (and why).

(You can also be desperate and hoping that adding more swap space will let one of these cases limp along. If so, I hope that you have good monitoring so you can reboot entire machines if or when they fall over.)

unix/SwapLotsWhatFor written at 00:51:47; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.