From: Steven Sim (steven.sim@faplccc.net)
Date: Sat Feb 05 2005 - 00:44:10 EST
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
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:07 EDT