The OutRider Computing Journal
A free monthly column for users, administrators, programmers and hobbyists who use UNIXlike Operating Systems.
Home | Search | Site Map | Feedback | Subscriptions
| The OutRider Computing JournalA free monthly column for users, administrators, programmers and hobbyists who use UNIXlike Operating Systems. Home | Search | Site Map | Feedback | Subscriptions |
Not too long ago, OutRider had a column about memory. This column will look at swap space allocation for small workstations to low end enterprise size systems (ranging anywhere from 32MB to 50GB). This is because I do not have experience beyond those ranges and when dealing with architectures beyond that range, you are looking at network wide load balancing etc., all of which is beyond the scope of this document.
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. This is 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 this 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. This column will examine four methods:
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 this practice 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).
This particular method 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 this method in a great deal of trade journals and books (actually I have seen this 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 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:
This 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 ssystem, 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
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
As you can see, creating and undoing swap space is relatively simple [ 4 ].
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 usually something like this:
swapon -p
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 your particular UNIX system interacts with swap space.