Problem with adding more swap !

[Lowell Gilbert]

Jerry McAllister <jerrymc at clunix.cl.msu.edu> writes:

> Well, if you can spread it across multiple controllers, it can
> speed things up.

Right.

>                   But, generally I think that swap is used in
> a serial manner, eg the first chunk gets used up before the 
> next one is started, etc.

That's wrong.  See the Handbook section titled "Swap Partition".
http://www.freebsd.org/handbookconfigtuning-initial.html#SWAP-DESIGN

>                            So, that would mean that you would
> want to put only a little on the boot drive (you need some there
> for special occasions) and most of the rest on another drive
> and another controller if you can.

Because FreeBSD tries to "stripe" the usage across all of the swap
space, you're best off giving it space on all of the disks.  However,
if your disks are not all the same speed, you're better off sticking
to the fastest ones for swap space.

>                                      Compared to the CPU, disk
> access is rather slow, so anything you can do to spread out
> the work across more than one disk tends to speed things up.

That's true, but also note that swap partition usage is faster than
regular disk usage, so it can be useful even for clean pages.

> But, if you are the only one using the machine and that is 
> mostly for one activity at a time you probably won't notice
> any difference.

There's one exception to this:  the *most* useful case for optimizing
swap is where a single task has a working data set that doesn't fit in
memory.  In that case, every little bit of speed you can tweak out of
swap access will improve results substantially.  Of course, additional
RAM would help even more.


The one other thing to note about swap space is that you can't do a
kernel dump unless you have a partition big enough to hold it.  The
easiest way to guarantee that's available is to leave a swap partition
bigger than your RAM.  But if you need to, you can always limit the
amount of RAM your kernel is using to just under the size of the
largest available partition, so that's not necessarily critical either.

Good luck.