Rick Moen, rick@linuxmafia.com
Fri, 28 Dec 2007 16:31:39 -0800

----- Forwarded message from Rick Moen <rick@linuxmafia.com> -----

Date: Thu, 27 Dec 2007 21:16:21 -0800
To: svlug@lists.svlug.org
From: Rick Moen <rick@linuxmafia.com>
Subject: Re: [svlug] recommended percentage swap on 400G drive

Quoting Darlene Wallach (freepalestin@dslextreme.com):

> Is there a percentage of the disk size I should calculate for
> swap?

The amount of desirable swap on your system, and its placement, really isn't directly related to disk size (except in the "you have to have X amount of space in order for allocating Y from it to be reasonable" sense): It's more related to total system physical RAM than anything else, and secondarily to your usage patterns with that RAM (number of active apps, RAM footprint of each of those).

The rule of thumb on all *ixes that you'll see quoted ad nauseam is that total swap space should generally be somewhere from 1.5x to 2 or 3x total physical RAM.[1] If your system has multiple physical hard drives, all of which are roughly similar in overall speediness, then ideally you want to put some swap on each physical drive -- max no. being 32 ;-> -- so that the (fairly intelligent) swapper process can split the necessary seeking[2] activity between them, for best performance through parallelism. By contrast, if any of the drives is markedly slower[3], it's still worth putting some swap on it, but you'd want to specify a lower swap priority to the swapper process. (See "man 2 fstab" or "man 8 swapon" for details.)

Ideally, you would also want to physically place the swap partitions between other partitions in a manner calculated to (you hope) reduce average seek time by keeping the heads in the general vicinity more often than not.

As if all this detail wasn't enough to contend with, it turns out that Linux swap files (as opposed to partitions) are a contender again. They were common in very early Linux days, but fell out of favour when it emerged that swap partitions yielded much better performance. However, it turns out that, with the 2.6.x kernel series, swap files once again have competitive performance, and might be worth using. See: http://lkml.org/lkml/2006/5/29/3

[1] This is an OK rough heuristic, but obviously doesn't fit all usage models. In general terms, you want enough swap so that you're very unlikely to get tasks killed by the out-of-memory killer for lack of virtual memory, even when your system is heavily loaded. Too much swap really only wastes disk space, which is relatively cheap and plentiful, so most people are wise to err slightly on the side of overallocation.

Theoretically, if you had huge gobs of RAM, e.g., 64GB RAM, in relation to your usage, some would argue that you should have no swap (and certainly not 128GB of it!), since you're basically never going to need to swap out files or processes at all. But actually, memory pages managed in virtual memory don't always back files at all, as Martin Pool points out in the page you cited (http://sourcefrog.net/weblog/software/linux-kernel/swap.html).

This whole field remains debatable in many areas, because real-world usage is difficult to model, theoretical knowledge is a fallible guide to reality, and available documentation is a bit poor and obscure (with the notable exception of Mel Gorman's book), so intuition and plausible but non-definitive theories are common.

[2] Seeking is the process of moving the drive heads between concentric tracks, and is by orders of magnitude the slowest operation a hard drive needs to do. Therefore, anything that reduces seek time or average seek distance will considerably improve virtual-memory performance and extend HD life.

[3] Including for interface reasons, e.g., being USB-connected.

----- End forwarded message -----