Unix folklore: your swap should be twice your RAM

May 13, 2007

There is a persistent general belief that your minimum swap size should be two times the amount of memory your system has (sometimes it is the recommended swap size). Much like the myth of multiple sync commands, it stems from a bit of history carried forward without full understanding.

The original Research Unix up through V7 did not have paged virtual memory (I believe that PDP-11s may have lacked the hardware for it); when it ran short of memory, it swapped out an entire process. Paged virtual memory came into Unix when UC Berkeley moved V7 to the new DEC VAX series (to mark the occasion they renamed the kernel image to /vmunix).

Now, there are two ways of allocating swap space for pages of virtual memory: you can do it when you first allocate the page to a process, or you can do it only when you have to swap the page out. The drawback of the first method is that it limits the system's total virtual memory to the amount of swap space you have; the drawback of the second method is that it is quite hard to make sure that you don't overcommit your swap space.

(If you overcommit your swap space, you may someday be forced to swap out a page of virtual memory only to find that you have nowhere to put it. Bad things generally ensue, such as random programs being killed.)

UCB used the simpler and more conservative method of allocating swap in 4.x BSD, and this carried on into pretty much every commercial Unix derived from BSD, including DEC Ultrix and Sun's SunOS. As a result, these systems had to have more swap space than you had physical RAM, and the recommended starting point was generally put as 'twice as much swap space as you have memory'. As usual, most of the people who repeated the piece of advice did not bother explaining why.

Since the flaw of the simple approach is so obvious and irritating, any number of people got to work on overcoming it and by the mid 90s most Unixes had better swap allocation that removed the BSD limitation. But by this point the advice had been amplified into common folklore, which is why you still hear it today, probably at least ten years after it's been applicable.

Comments on this page:

From at 2007-05-14 14:55:36:

When Solaris took over from SunOS, the removal of the swap space limitation was one of the big advantages. However, what it did upon overcommit was a mystery. In the days of Solaris 2.1, we were happy if it booted at all, so nobody bothered to investigate what happened under a non-trivial load.

In the recent times, Linux kernel 2.4 in all incarnations had an annoying design problem which caused deadlocks when swap was not big enough. It was pretty much the worst of all worlds, with overcommit and OOM killer and the requirement for humongous swap. Oh, and also it could only take so much swap (like... 8 segments 1GB each or something like that).

This issue was only fixed by 2.6.12, IIRC. Red Hat shipped 2.6.9 with worst of it fixed by careful backports for RHEL 4. SuSE AFAIK shipped a 2.6.9 or 2.6.10 based SLES with Andrea's fixups, so they also allowed reduced swap.

Written on 13 May 2007.
« Weekly spam summary on May 12th, 2007
Sizing your swap space (part 1) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun May 13 20:58:03 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.