"swap" partition leads to instability?
matthew at FreeBSD.org
Sun May 26 10:57:45 UTC 2013
On 26/05/2013 09:58, M. V. wrote:
> hi everyone,
> I have a 24/7 network server/gateway with FreeBSD-8.2 on a SSD drive. it's partitioned as normal (/ , /tmp, /var , /usr and swap) for a long time now. But recently I heard from a FreeBSD expert that I shouldn't have swap partition for my server, and having swap partition could make my server unstable. this was so strange for me, and I searched a lot but couldn't find a reason for this claim.
> so my question is simple:
> - could having a "swap" partition, be a bad thing for my FreeBSD server? and if so, why and in what conditions?
Having a swap partition is absolutely standard for server or workstation
class machines, and should be implemented as a matter of course. Even
if the machine has much more memory than it would generally ever use and
so have no actual need to swap.
About the only circumstances where you wouldn't want swap is if you were
creating an embedded appliance and eg. didn't have any writable disk
space. That's pretty extraordinary and as such a system would have to
be heavily customized over stock FreeBSD anyhow, so not having swap
would fade into insignificance compared to the other changes that would
Why is swap needed? Nowadays, memory is sufficiently cheap and system
boards are capable of loading so much of it, that the only sensible
strategy is to have more physical RAM than is required to keep your
normal application load working. So a swap partition should not be
routinely involved in swapping memory pages back and forth.
Even so, idle pages can be swapped out -- there's no point in having an
unreferenced memory page sitting in RAM taking up space that could be
used productively by an active process. A small amount of swap usage
like this is standard. A large amount of swap usage like this indicates
you need to switch to using better written software.
Swap is also useful to buffer against unexpected spikes in memory usage.
Sure, performance generally nosedives once a system starts actively
swapping, but that may be a better outcome than the alternative if there
is no swap capacity available: which is for the kernel to start killing
off processes in an attempt to reduce memory pressure.
Finally, swap is used as the place to record kernel state in the event
of system crashes. You could use any otherwise unused disk partition
for that, but swap is traditional. This is where the hoary old recipe
of 'swap = twice ram' came from, although nowadays what with minidumps
and the generally larger amounts of RAM in use you don't need to provide
anything like as much as that.
If you're bothered by having a few GiB of disk allocated as swap but
basically idle, then look into tmpfs or mdmfs for /tmp -- that will let
you make productive use the space while still keeping the ability to
save crashdumps if needed.
Some caveats about where to put a swap area:
* If your system is under memory pressure, then your swap area can be
extremely active. In these circumstances putting swap on a SSD card or
other device with a limited number of write-cycles is not a good choice.
* If you are using ZFS, and again, if you are under memory pressure,
then putting swap on a ZFS can lead to a deadlock where the system needs
to allocate more memory to deal with an out-of-memory condition. In
this case, it is recommended to create a separate swap partition not
managed by ZFS.
Otherwise, swap can go anywhere. A dedicated partition will give better
performance than swapping to a file, but file-backed swap is handy if
you need to add swap in a hurry.
For resilience, mirror swap partitions in pairs -- gmirror(8) is a good
tool for that. Don't try using any of the higher RAID levels for swap
areas -- their performance characteristics are not a good match to the
sort of IO a swap area does.
For best performance, you should spread swap areas over as many disk
spindles as possible. You can create numerous swap areas and the system
will automatically stripe any IO across them.
Dr Matthew J Seaman MA, D.Phil.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 268 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions