Recommended Swap Size Summary

Hello All;



Firstly thanks to ALL who replied.



This is indeed a wonderful list!



Original Problem

------------------------



I wanted a rule of thumb or some sort of guideline to assist me in
estimating the initial size of the primary swap area residing on the root
disk.





Summary

---------------



Most agreed that the swap size depends on the application being used.



Generally most agreed that the old rule of thumb, 2 x actual RAM is no
longer in force and has not been in force since SVR4 became available.



General agreement here is that the swap size should be determined by
application(s) requirement and the sufficient space to hold a kernel core
dump.



Matthew Stier and Jeff Woosley gave a detailed account of the swap space
requirement under a Berkeley Kernel and one running a SVR4 kernel. In
summary, SVR4 kernel do not even require swap.



Jeff Woosley further pointed out that since core dumps are most usually
compressed, one does not even need a 1 x RAM swap size.



Some subsequently suggested 1 x RAM or at the very least enough for the
kernel core dump.



John Christian suggested = physical RAM size for systems with less than 64
Gbyte RAM and = to < RAM size for systems above 64 Gbyte RAM. But mainly his
opinion is inline with the rest i.e. application sizing and performance
requirements determines swap size.



Quite a few insisted on a maximum of 4 to 8 Gbyte swap space irregardless of
huge RAM sizes. Anything else would be a waste of space. Rich Teer (author
of Solaris Systems Programming) suggested a 4 Gbyte swap size or enough
space to hold a kernel core dump. Mr. Teer also commented that with todays
large boot disk sizes, one can afford to be generous with swap space
(something I agree with).



JV711 suggested looking at the Sun Blue Print Performance Oriented System
Administration. While interesting and enlightening, it did not give a
concrete answer either. Nevertheless, Im attaching relevant portions of the
Blue Print below for easy reference.



Properly Size Swap

Properly sizing swap can be a trade-off because having too much or too
little swap

space can cause problems. At a minimum, sizing swap to be too large wastes
disk

space. A more serious problem, however, is that sizing swap to be too large
can

cause hard-pageout1 to occur too easily. The other problem, not allotting
enough

swap space, can cause the system to run out of virtual memory before it runs
out of

physical memory. Physical memory is too expensive to waste by not having
enough

swap disk to use it all.

In addition to balancing these types of trade-offs, you need to be able to
recognize

when swap is improperly sized. Because neither situation (having too much
nor too

little swap space) prints a simple message to the console like Swap too
small, look,

instead, for memory allocation errors or somewhat obscure messages such as

cannot fork, or not enough memory as signs that swap is improperly
sized. You

will never see the message Swap too large, even though it can happen,



Deciding How Much Space to Add

While it is simple to adjust swap by adding or removing disk partitions or
logical

volume manager volumes, it is not simple to calculate how much space to add.
Your

decision depends on the application and on the details of the running
environment.

Because the application might have tunables to adjust the working set size,
it is often

better to keep a lid on the requests by keeping the swap size down. This
allows the

application specialist to quickly recognize a need to resize swap and to
change

configuration parameters to reduce the working set size without having to
look at

swap and vmstat(1M) outputs.

As memory density grows, the definition of wasted memory needs to grow, as
well.

You might get to a point when it is not worth struggling to recover larger
and larger

amounts of memory. When you look at wasted memory, do so with a threshold
set in

cost rather than in megabytes. What looks like a wasted 100 megabytes of
memory,

on one hand, can alternatively be viewed as a cheap insurance policy when
you

consider the potential for it to help you avoid performance problems.



Sizing Swap

Because of the implementation of swap in the Solaris OE, the time-honored
rule of

thumb to size the swap device at two to three times the size of real memory
is no

longer accurate. These values each need to be reduced by at least one.
Sizing swap at

one to two times real memory is a good starting point, but even that is too
large for

systems with very large amounts of physical memory. Depending on the
application,

very large memory is used only by programs that have higher than traditional
ratios

of working set size to total size.



Starting with the Solaris 9 OE, you can use the mdb(1M) command to analyze
the

free memory and swap requirements much more easily and accurately than you

could in earlier releases of the OE.



The freemem statistic, which shows up in vmstat(1M) (in the memory free
column)

and in other monitors, is much more useful for memory sizing in the Solaris
8 OE

and later versions than it was in earlier versions. The freemem statistic no
longer

includes memory used by a file that is a valid copy of the on-disk file, and
has no

processes mapping. These pages are available to be used for new processes on
all

versions of the Solaris OE kernel. In earlier versions, these pages were
considered to

be used. In the Solaris 8 OE and later, the free memory statistic doesn't
include these

pages and, therefore, it m





Warmest Regards

Steven Sim







Fujitsu Asia Pte. Ltd.
_____________________________________________________

This e-mail is confidential and may also be privileged. If you are not the
intended recipient, please notify us immediately. You should not copy or use
it for any purpose, nor disclose its contents to any other person.

Opinions, conclusions and other information in this message that do not relate
to the official business of my firm shall be understood as neither given nor
endorsed by it.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers