March 2000
Managing swap space and requirements.
Having a solid reference point is perhaps the best possible situation an administrator can find themselves in. An instance when this might occur might be if one is transferring a particular set(s) of software and function(s) from an older architecture to a newer one. In that particular instance, the manufacturers [ 1 ], user groups and vendors all will usually have sets of comparisons about the differences between one system versus another and (if you are lucky) information about particular application [ 2 ] needs where swap space is concerned.
Another way to beat the problem to the punch is to attempt to test out a particular set of applications on a system before completing the configuration of a newer one; a much more difficult situation to be in, but I have actually been there as it were, it worked out for the best.
One thing I have consistently discovered is when I do have the occasion to test an application prior to deployment, or I already have a reference point, every single time (so far that is) I have grossly overestimated my needs. I believe it is because I do not fully take into account faster bus speeds etc. and a small degree of incredible luck. I can only hope all of my fellow administrators are as haplessly fortunate as I have been, however, by the same token, suddenly the extra resources get swallowed up by unforeseen projects or events in general. In the end it all seems to balance out.
There are several methods for determining the amount of swap space you need. Four methods are:
Of course, the last one is not a stand alone method, but it deserves special attention.
In a nutshell, (RAM x 2). For instance, if you had 24GB of memory, 48GB of swap space. While in practice it generally works, it is not always the most efficient. Some flavors of UNIX take special advantage of swap space, while others may not. A system may not even need any (although that is definitely a rarity - it is always a good idea to have some).
A particular method that can be helpful, but it requires a great deal of research. To coin a phrase from a popular movie:
"The sheer logistics of it are mind boggling"
Which can certainly be true of determining swap space needs based on:
I think you get the picture.
All is not lost, however. Upon further investigation, one can find all sorts of information to help them make a well informed decision about swap space requirements. Here are a couple of suggestions:
By far the easiest method is to size from a given reference point. The applied method of doing this is actually somewhat tricky, however, you will find the method in a great deal of trade journals and books (actually I have seen it in several books).
There is a deviation of this method that works on systems that are not yet online (i.e. the system you are about to put online). Simply setup a grossly oversized temporary swapfile to hold you over until you create the swap partition(s).
Basically you have a bunch of knowns, these knowns are how much memory your system will require when running x applications with n instances, following is the exact method:
The method, however, is not full proof. There are instances when a certain architecture will simply require what might seem like more than you will ever use.
As I mentioned earlier, no method is full proof (or fool proof as it were). There are instances when even the old Ram x 2 will not suffice. The reason for this is some applications (databases in particular) are designed to make use of swap in some sort of special way. That being the case, the normal rules may not apply. Additionally, there is always the unforeseen additions and loads that come into play.
Finally, having an initmate knowledge of your systems helps. As an example, had I known the precise bus architecture on a new system, I might have saved some money by not getting the amount of RAM I did initially.
We have covered the methods of determining swap space requirements, next we will examine the definitions of swapfiles and partitions, the pros and cons of each and how to set them up.
A swap partition is a predefined and allocated disk area that is
used only for swapping. A swapfile is, as it intuitively sounds, a
file that does the same job, however, it can grow to the size of
the partition it resides on. With that in mind, creating a swapfile
on say a /usr partition may not be the wisest
idea.
Swapfiles are best employed as a temporary holdover measure, or as I mentioned above, a temporary device for determining swap partition needs. A swapfile may also work well on a small workstation, otherwise, the keyword to remember here is temporary.
The syntax for activating a swapfile is pretty simple:
swapon filename
For example, if we made a temporary swapfile called
/var/swapthis:
swapon /var/swapthis
Allocating a swap partition varies from UNIX system to system,
however, the most common command to create swap space is the
mkswap command. In the following example, I am
creating a swap partition on a logical volume in volume group
00:
mkswap /dev/vg00/lvol04
Activating swap partitions is similar to files, using the logical volume example, the syntax would look like so:
swapon /dev/vg00/lvol04
Turning off swap uses the swapoff command. Using
the swapfile example, the command would look like so:
swapoff /var/swapthis
Swap space performance can be enhanced (or worsened) by altering priorities. On some systems, there may be multiple swap partitions on different devices. Since priority is based upon "first come first serve" by default. So, you may have an instance where you would want to alter default priorities because of a new disk installation etc. The syntax is usually something like:
swapon -p priority
With the priority being a number. In most cases, the higher the number, the higher the priority.
Swap partitions are disks, keeping that in mind, many principles that one might apply to disks can also be apoplied to swap space. Using RAID or striping in general can increase performance. Try to allocate swap partitions near the beginning of a drive etc.
Any performance issue can never be fully examined in a short column, as I stated earlier, this applies to small to low end enterprise systems. Even so, there will be instances where this particular column may have missed the mark. I highly recommend visiting newsgroups, consulting local documentation and manuals to learn more about how your particular UNIX system interacts with swap space.