Original Question:
I'm looking into doubling my RAM on some Sparc20s
and Ultra1 which are basically webservers that run
some resource intensive applications (including
Java). I've heard some mention that webservers
should be set up to be at least 3 times of RAM. I
was wondering what other people's experiences was in
setting up swap for webservers.
Since I'm doubling my RAM from 256MB to 512MB, how
necessary is it to also bump up my swap space? What
kind of problems may one encounter if one does not
increase swap space?
I wish to thank the following people for all their
suggestions:
Sean Ward <sdward@uswest.com>
Peter Polasek <pete@cobra.brass.com>
pshannon@Schwab.COM (Patrick Shannon)
Chris Marble <cmarble@orion.ac.hmc.edu>
Andrew M Townsend <ATOWNSEND@DOLETA.GOV>
Bob Fulwiler <bobf@colltech.com>
<MARC.NEWMAN@chase.com>
gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Daniel Dunn <dandunn@computer.org>
Matthew Stier <Matthew.Stier@tddny.fujitsu.com>
nobroin@esoc.esa.de (Niall O Broin)
Rich Kulawiec <rsk@gsp.org>
birger@sdata.no (Birger Wathne)
Casper Dik <casper@holland.Sun.COM>
Ian TCollins <itc1@scigen.co.uk>
hickey@nrlmry.navy.mil (Vince Hickey)
It turns out that it's not necessary at all for me to
add more swap. If I never ran out of virtual memory
before, it's unlikely it'll do so now once I add
256MB of virtual memory (assuming same mix of
processes). But even if the load increases, there's
256MB more to
play with.
That RAM to swap ratio thing, was an old Berkley-ism.
The older Berkley-based kernels (like SunOS 4.x and
before) would actually load the application into
memory and swap. The 2X+10% rule was to ensure that
the kernel had enough room to work with.
The Solaris 2.x (SunOS 5.x) kernel is SysV based, and
does not have this handicap. If you have enough
physical memory for your working set, you can even do
without swap space.
Someone mentioned that he generally used 2xRAM for
swap as performance seems to suffer if you try to use
much more virtual memory than that (remember, under
Solaris virtual memory = Physical+swap-/tmp. Don't
use /tmp unless you really need to.)
Someone suggested the following book:
Machine configuration issues, parameters, etc are
_the_ subject of a Prentice Hall book "Configuration
and Capacity Planning for Solaris Servers by Brian L.
Wong" ISBN 0-13-349952-9. It is about $45... a
GREAT BOOK!
Look for the swap space columns by Adrian Cockroft at
this web site:
http://www.sun.com/sunworldonline/common/swol-backissues-columns.html#perf
Some good references to get more info on the topic:
http://www.sun.com/sunworldonline/swol-12-1997/swol-12-insidesolaris.html
http://www.sun.com/sunworldonline/swol-01-1998/swol-01-insidesolaris.html
http://www.sun.com/sunworldonline/swol-10-1995/swol-10-perf.html
http://www.sun.com/sunworldonline/swol-04-1996/swol-04-perf.html
http://www.sun.com/sunworldonline/swol-05-1997/swol-05-perf.html
You have got 65MB swap. You can graphically see the
usage of the swap
memory using the '/usr/openwin/bin/wsinfo' command.
Under the BSD kernel (SunOS 4.x and before), virtual
memory equalled swap space. For every process
started, it was automatically put into swap. The 2X
+ 10% rule came into effect, to ensure that you had
sufficient swap for two complete images of physical
memory, plus some workspace to move things around.
(ie: Like the 10% overhead for filesystems,
accessable only by root.
The System V kernel however, defines virtual memory
as the sum of physical memory plus swap space. The
System V kernel only when it needs to. If you have
sufficient physical memory, you could run the system
without any swap space defined. (However, I recommend
that you change /tmp from a tmpfs to a ufs.)
Memory Tuning Summary
---------------------
This is an attempt at a nutshell overview of memory
tuning. Under SunOS, it is necessary to have twice
as much swap as there is RAM. This is no longer
required for Solaris. In fact, there is no need for
a swap device at all if the machine has more than
64Mb of memory (though getting a crash dump can be
problematic in this configuration).
The total amount of virtual memory (physical memory
and swap) required for a machine is dependent upon
the cumulative memory requirements of all processes.
When you run out of virtual memory, new processes can
not be started and running processes that execute
'mallocs' will fail.
Obviously, it is necessary to size the machine with
sufficient virtual memory capacity to avoid this
condition; however, the ratio of physical memory to
swap space required for reasonable performance is
completely dependent upon the characteristics of the
applications. If the processes use large amounts of
memory that is 'active' (i.e. frequently updated or
referenced), then a high ratio of physical memory to
swap will be required to deliver consistent
performance. If, however, the applications use large
amounts of memory, most of which is inactive,
then reasonable performance can be achieved with a
smaller physical memory to swap ratio. 'Rule of
thumb' guidelines for memory/swap sizing are useless
because the system requirements are completely
application
dependent.
Since you have added memory, the best measure of the
appropriateness of your configuration will be to
monitor the system under heavy load. You can use
'vmstat' to determine if you have enough virtual
memory capacity and also to evaluate whether the
'physical memory to swap space' ratio is high enough.
Typing 'vmstat 5 10' will collect statistics for 10
samples at 5 second intervals. If, for example, you
have 512 Mb of physical memory and 256 Mb of swap,
the output might look something like this:
% vmstat 5 10
procs memory page disk
faults
cpu
r b w swap free re mf pi po fr de sr s0 -- --
-- in sy cs
us sy id
0 0 0 9096 1064 0 13 0 1 1 0 0 1 0 0
0 158 171 51
3 1 96
0 0 0 494888 15376 0 1 0 0 0 0 0 3 0 0
0 413 599 222
13 4 83
0 0 0 494880 15368 0 0 0 0 0 0 0 3 0 0
0 382 675 193
10 3 87
0 0 0 494872 15352 0 0 0 0 0 0 0 5 0 0
0 409 530 186
13 3 85
0 0 0 494872 15344 0 0 0 0 0 0 0 3 0 0
0 342 447 172
11 2 87
0 0 0 495232 15672 0 46 0 0 0 0 0 11 0 0
0 436 711 188
12 4 84
: :
:
: :
:
Note that the first line in these results represents
a summary since last reboot and therefore should be
ignored. The remaining lines show the current
utilization at 5 second intervals. The server should
be under heavy load when the stats are taken.
The total of the 'swap' and 'free' columns is of
interest to determine whether you have enough total
memory capacity (physical and swap). The
example stats show 494888 Kb + 15376 Kb = ~ 510Mb of
available memory space. Since the total virtual
memory capacity is 768 Mb and 510 Mb of memory is
available, the 33% memory utilization ((768-510)/768)
indicates
the machine has plenty of capacity for the current
load. Adding more swap space to this system would be
a waste of disk space (although it would provide
additional capacity for heavier loads and also
provides
space for large crash dumps should they be needed).
In general, you should configure it so that you are
at less than 70 percent capacity under heavy loads
(this will allow sufficient headroom for unusual
conditions and runaway programs). You can also
determine the memory use ratio with the 'swap -s'
command.
The 'free', 'sr', and 'po' columns are of interest to
determine if you have a sufficient ratio of physical
memory to swap. If the 'free' size is above 12000
Kb, then can assume the machine has plenty of
physical memory without looking further because the
free memory size is above the threshold where the
kernel (with default settings) starts taking a strong
interest in looking for memory to page out. If the
free size is
smaller, the you should look at the 'sr' (scan rate)
column. If this value is above 20 or so, then it
indicates that there is a memory shortage and that
active memory will be paged out (the greater the
shortage, the higher the scan rate). Adrian
Cockcroft (Sun's performance guru) states that there
is not much reason to worry unless 'sr' exceeds 200.
We have found the limit to be much lower, I guess it
depends upon how mission critical the application is.
If you see
non-zero values in the 'w' column, this indicates
that the process is swapped out. This rarely occurs
in Solaris and is likely indicative of a severe
memory shortage.
The 'po' column indicates page outs. This column
should be low as well. Unfortunately, the page outs
recorded include both memory and file paging, so it
more difficult to distinguish the cause. If I see
high numbers (more than 50) here for sustained
periods and a low scan rate, then I look for programs
that are doing excessive file I/O.
In summary, you can add physical memory until the
'sr' rate goes to 0 under heavy load conditions.
Adding memory beyond this point will be money wasted;
however, it will give you extra capacity when real
world demands exceed those of your test case. The
above describes a cookbook method for memory tuning,
I have included an brief overview explaining the
virtual memory system and why memory has such a large
effect on performance in case you are not familiar
with the concepts.
virtual memory overview
-----------------------
The UNIX operating system uses 'virtual' memory to
extend the storage capacity of a machine beyond its
physical memory size. The usable memory capacity of
a server is the sum of its physical memory and disk
'swap' partition sizes. When a process is running,
the operating system places 'active' information in
physical memory and 'inactive' data in the disk
'swap' space. Although disk storage is hundreds of
times slower than physical memory, this mechanism
allows very high performance IF the machine has
enough physical memory space to store the 'active'
portion of data for all processes. If there is not
enough physical memory, system performance drops
significantly because
data access becomes reliant upon the very low
performance disk storage device. The virtual memory
system is key to minimizing the memory requirements
of the server.
Without this mechanism, most machines would need very
large physical memory sizes to run. As effective as
virtual memory is, however, the server must always
have enough physical memory to store the active
portion of data to maintain system performance.
--- Ju julienlim@rocketmail.com_________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:33 CDT