SUMMARY: Swap Space

From: Darren Brechman-Toussaint (
Date: Sun Apr 28 1996 - 17:56:46 CDT

Firstly I would like to thank everyone who responded,

Justin Young <> (Kevin Sheehan) (Stephen Harris)
Phil Howle <>
Bill Reed <>
Brad Young <>
Fedor Gnuchev <>
Benjamin Cline <>
Sahir Siddiqui <> (Glenn Satchell)

My original post was :-

> What is the difference (performance/admin) between having swap
> space on it own disk partition and having swap in a file eg /swap/swap01

Responses were as follows :-

If you mean versus having swap on its main local disk0 versus an external
disk. Generally very little depending on the speed of the drives and the
scsi connection. In fact we have several brand new 1.05GB drives on some
IPX's where the external swap is actually faster than the swap on the
local drives. Now, please don't nfs swap. You can do it if you have
fast machines and a fast (100MBps) network. However, if you have
everything that fast, you can afford to add a local drive for swap (smiles).

Depends on whether you are talking 4.x or 5.x in the first place, but
assuming the latter...

You will pay a penalty for getting to the blocks, as UFS is not
quite as efficient as straight raw disk. You can change the size
of a file, which is more difficult to do with the swap partition.

It really depends on which way you are using it - in 5.x, a private
page is either in core, or on disk. So you either use swap as substitute
memory (for small memory machines wanting to do a lot) or as a spill-over
for when you temprarily exceed phys mem (for large memory machines tweaked
to the last page :-).

The only other thing to worry about is the use of swap as a dump
partition, but that's a whole 'nother topic.

Partition is quicker because it's direct disk access. Swap file requires
access via the file system and so is slower.

swap on its own partition does not have to go through the unix
filesystem to talk to it. should therefore be quicker.

The recieved wisdom is that partition swap is better than filesystem
It should be faster because it doesn't have to go through the file
handling routines.
However, I read report from someone who had done controlled tests and
found the difference in speed was only some 10% or so.
Because of the admin convienence of increasing swap via a file this
would seem
preferable except for the most critical/server situations.
There is a good article on swap in SunWorld on-line.

Swap space on raw partitions is faster than on swap files. I have been told
by a Sun engineer that under 2.5 swapping on files is as quick as on
partitions, but I'm sceptical, although I have no evidence either way.
Multiple swap partitions on separate disks and controllers is quicker still.
Two swap partitions on the same spindle is a bad idea.
I generally prefer swap partitions, but more often than not, I've had to
resort to adding swap files to increase virtual memory. It's a pain to dump
data, repartition the disk, and then restore the data. It's a pain for
administrators and a major pain for the customer..

1st admin:

swap files are much easier to manage - no need for repartitioning.
You can add/decrease swap size as you need.

2nd performance:

a) swap file lives on a filesystem and thus can fall into internal cylinders
of the disk ( and they are much slower that those closer to the edge -
that is why / is slice a and swap is slice b).

b) from early expirience with IBM S/370 running VM/370 I always saw same
rule - keep paging device separate. Reason : OSes are very smart in
minimizing mechanical motion within swap (aka paging) device. As soon as
you mix other I/O with swap its performance degrades for evident reasons.
Unless you run on solid-state disks mechanical issues are present.

c) OS tends to put swap load evenly in case of several (prefered)swap
partitions (preferably on separate drives (which are preferably live on
separate interfaces)). As you see - high end is outlined.
 Now going to the low end.
What happens when you make several swap files (probably on one disk) :
megaseeks hit you back as OS tries to deliver you top performance,
especially so if drive is also hit by i/o intensive applications (nightmare).

Yet it is rather too luxurios to dedicate 2 extra esp's and 2 drives for
paging only. So I am using following layout:
server -
a)2 int drives with / /usr/ & other OS && SW ( read once per run
pattern) both have swap partition. Practically only I/O is swap -
application launching and /var accounting are negligible load in our case.
These sit on first esp.

b)External disks keep all application I/O intensive directories. This
includes links from /usr/local applications which want their data dir's
to be in /usr/local/ tree.
These sit on second esp.

stations -
have big swap partition, use cachefs for SW & OS components taken from
server and same for application dirs.

God, ti's a lenghty story. Hope it answers something.

There is a slight performance hit when using swap files. It varies
from (very roughly) 1% - 10% in Solaris 2. Since swap files can give
you a system configuration which is noticeably easier to administer and
document, and makes better use of the available disk space then the
performance hit may be worthwhile. It will not be acceptable in
situations where there is insufficient memory, disk bandwidth, and CPU
speed, or where there is other good reason for lots of paging to or from
the swap areas.

We use it all the time on our own desktops.

One other point - If you need to be able to take a system "core image"
(savecore dump) after a crash, then you MUST have a swap partition
of sufficient size to hold all of system RAM.
Otherwise, you can use a small (or no) swap partition with Solaris 2.

Swapping to a dedicated disk partition tends to be faster, since the OS
doesn't have to got through the filesystem code, but swapping to a file
can be much more flexible (easier to add/delete/change).

Swap partitions do not have UFS/VFS filesystem structures on them -
they are formatted to a swap filesystem which is optimized for that
If you create a file on an existing partition and use it for swap
space, all writes/reads to/from the swap file must be translated
to/from UFS/VFS file structure (inodes,etc). It introduces a slight
speed disadvantage (how small or large - I couldn't tell you...).
So, on new systems it is advantageous to create swap partitions, but
when you are trying to increase swap space on an existing system
without playing around with partitions, you could add swap space by
creating swap files.
Hope this helps - its just a brief outline...

A swap partition will use direct reads and writes to the disk: no overhead for
inodes, indirect blocks, etc.

If swapping to a file then every operation requiring swap must go
through the filesystem layer, which imposes additional overhead
compared to swapping to a raw device. Also wiht a file there is no
guarantee that the blocks in th efile will all be close together (in
fact with a large file you are almost guaranteed that the disk blocks
will be spread over the partition.

The advantage of course is that you can make and delete swap files
easily and on the flyu without having to reboot. This gives a lot of

Differences depend entirely upon the placement of the swap space
upon the disk. While partitions are typically (usually if set up
correctly) oriented to the exact cylinders and platters, files
are not always clustered together. The key is that the swap
file should not require the system to have to search the disk
for the addresses of various pieces of the file. If portions
are scattered over various cylinders, it takes a while to find
while if they are oriented to the cylinders and in contiguous
blocks, a partition and a file will be the same in performance.
The likelyhood of this happening however is slim on an already
worked on system. Newer systems will have a better chance since
they can have wide open, clean partitions.

What I have done:-

Originally the swap space was 555MB on one disk which also has /, /var,
/opt, /usr, /export on it all on seperate partitions.

This disk was becoming overloaded with resonable load ie load average was 6-8.

I have split the swap space into 3 ( 185MB each ) and placed them onto 3
seperate disks on 2 controllers.

Many thanks
Darren Brechman-Toussaint
Security Mailing Services

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:59 CDT