SUMMARY - Swap- which type to use ??

From: Wayne Sweatt <sweatt_at_dps.state.nm.us>
Date: Fri, 24 Jan 1997 15:30:06 -0700

 From the responses that I received, the major theme was: Running
the deferred type of swap was fine and would increase available swap
.. BUT.. if you NEVER want to go down due to a system critical process
being killed off due to lack of swap space, then you had better run in
immediate mode.

  Now, since I have sent this question out and read
the replys, I am assuming that deferred swapping runs blind
to the available swap space and puts swapping before idle processes,
whereas immediate swapping looks ahead before starting a new process
and will not start the process if it cannot reserve adequate swap space.
 If I have this ideal of DU internal system theory wrong, please someone
correct me !

 Thanks to all !!

Here are the responses (edited):

 Number 1:

DU's reputation as a swap hog seems to be the result of 32 bit apps that have been
quickly ported tothe Alpha, but whos internal logic has never been cleaned up. As
a result they seem to allocate huge blocks of memory. As you get newer applications
that have been written with true 64 bit platforms in mind, I think you will see
your swap comming back ito reason. That is conjecture on my part, but the apps that
keep running into artifical 32 bit limits (file size, max accessable memory, etc) on my
Alphas are also the swap hogs....

In the meantime, a 3:1 ratio of swap to RAM seems to work well on Alphas for most
applications.

The choice of immediate vs deferred is up to you. Immediate is a lot more conservative
and will ensure that your processes will run. With deferred, it is possible to get
caught short.

Tom

--
+--------------------------------+------------------------------+
| Tom Webster                    
 
 Number 2:
  As a practical matter, If you fill up the swap
space on a regular basis, you need to add another disk, and/or more
memory anyway.  So, if you can afford the chance of the system crashing
because it runs out of swap, then by all means, use deferred mode.  My
experience is that many systems will run on the edge of enough space for
a long time and not have any problems.  When you run out of space,
processes start getting killed.  If you can not risk that, then you need
to take the plunge and add more space.
-cliff
 Number 3:
 It is *quite* a swap hog.  We use defered here, and my systems run up to
10 times physical memory in swap.  Never have come anywhere near that, but
I had the space and got tired of the 'swap stink' I was forever getting
from the kernel.
 Richard Eisenman                                               
 Number 4:
 I switched to deferred after seeing similar messages, and things have been 
operating fine under that method. 
 
 
Elaine Lolos
 Number 5:
 I used lazy swap for a while, but then went back to eager swap. (i.e.
/sbin/swapdefault present). When using lazy swap and you run out of swap
(i.e. use that last page too...) then the system will start killing
processess at random. Losing inetd or portmap isn't really nice....
If you want to play around with swap, then install LSM, as DU can swap on
LSM devices, too. Then running advfs on top of LSM gives you ultimate
flexibility.
 Harald Lundberg 
 Number 6:
 Deferred swap has one serious limtation.  If you run out of page/swap
space, the kernel will start killing off "idle" processes to free up
space.  In some versions "idle" can something interesting.  And in
extreme conditions, idle is whatever isn't running at the time.  The
value of deferred is that the system virtual memory limit becomes
the sum of physical memory and page/swap space.  In immediate, the
system virtual memory limit is the amount of page/swap space.
If you can accurately predict the page/swap usage and trust that
nobody will ever try to use more than there is, deferred is great.
If this is a system used by students, get more page/swap space
and stick with immediate.  Somebody *will* figure out how to run the
system out of space, just to see what dies.
 

Received on Fri Jan 24 1997 - 23:39:23 NZDT