[comp.unix.sysv386] out of swap space??

aed@netcom.COM (Andrew Davidson) (04/24/91)

Hi 
I am currently trying to port an application from a sun sparc station
to SCO ODT UNIX. I seem to get some weird run time core dumps. I
talked to the orginal authour of the code, and was told that this
might because my system is running out of swap space?

HOW BIG SHOULD MY SWAP BE? I have 8megs of ram

ARE THERE ANY TOOLS TO HELP ME MANAGE / MONITOR MY SWAP SPACE?

thanks in advance Andy

-- 
-----------------------------------------------------------------
                  "bede-bede-bede Thats all Folks"
				Porky Pig
Andy Davidson
Woodside CA.
aed@netcom.COM
-----------------------------------------------------------------

mark@loki.une.oz.au (Mark Garrett ) (04/24/91)

From article <1991Apr23.214037.16410@netcom.COM>, by aed@netcom.COM (Andrew Davidson):
> HOW BIG SHOULD MY SWAP BE? I have 8megs of ram
	As a general rule for reasonable performace 2 to 3 times your real
memory ie. 16 to 24Mb swap for 8Mb ram
	What your should be doing however is have a look at the amount of
swap that your system requires and buy 1/2 to 1/3 that much ram. ie. its no
good haveing 24Mb swap if your average demand is >= 24Mb . 
	I have a DEC VAX with 32Mb ram and 64Mb swap interleaved across
to drives. If you have more than one drive it should help haveing the swap
split across them in this way.

> 
> ARE THERE ANY TOOLS TO HELP ME MANAGE / MONITOR MY SWAP SPACE?
	Dont now bout sysv386, there is for BSD so sysv should have them ?
-- 
Mark Garrett 			Internet:	mark@loki.une.oz.au
 University of NewEngland	ACSnet:		mark@loki.une.oz
	Northern Rivers		VAX/VMS PSI:	psi%0505266222011::mark
Lismore NSW Australia		Phone:	 	+61 (066) 203859

cpcahil@virtech.uucp (Conor P. Cahill) (04/24/91)

aed@netcom.COM (Andrew Davidson) writes:

>I am currently trying to port an application from a sun sparc station
>to SCO ODT UNIX. I seem to get some weird run time core dumps. I
>talked to the orginal authour of the code, and was told that this
>might because my system is running out of swap space?

If you don't get any messages on the console, I find it unlikely that 
the core dumps are being cause by running out of swap space.  Not 
impossible, just unlikely.

>HOW BIG SHOULD MY SWAP BE? I have 8megs of ram

My general rule of thumb is 2x your memory (or 16mb for your system).  Of
course, this depends upon the number and type of programs you inted 
to run and the real amount of memory you have.

>ARE THERE ANY TOOLS TO HELP ME MANAGE / MONITOR MY SWAP SPACE?

sar(1) will help you monitor it. (and will also tell you if you ran out
of swap space).

Do the following:

	sar -r 2 1000 > /tmp/sar.log 2>&1 &

Then run the application until it dies.

Review the sar output and if the freeswp had dropped to near zero, you
ran out of space.  If freemem dropped to near zero, you ran out of memory
and started swapping.

Note that it is unlikely that either one will actually get to zero, they
will just get real small.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

rfarris@rfengr.com (Rick Farris) (04/24/91)

In article <1991Apr23.214037.16410@netcom.COM> aed@netcom.COM (Andrew Davidson) writes:

> HOW BIG SHOULD MY SWAP BE? I have 8megs of ram

It depends, but 16 MB wouldn't be a bad place to start.


> ARE THERE ANY TOOLS TO HELP ME MANAGE / MONITOR MY SWAP SPACE?

sar -r

For a discussion of 'sar -r' and the rest of the sar tools,
see "System Performance Tuning" by Mike Loukides, a Nutshell
handbook from O'Reilly and Associates.

And why are you SHOUTING AT US?


--
Rick Farris  RF Engineering POB M Del Mar, CA 92014  voice (619) 259-6793
rfarris@rfengr.com     ...!ucsd!serene!rfarris      serenity bbs 259-7757

aed@netcom.COM (Andrew Davidson) (04/25/91)

In article <1991Apr24.123035.4193@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>aed@netcom.COM (Andrew Davidson) writes:
>
>>I am currently trying to port an application from a sun sparc station
>>to SCO ODT UNIX. I seem to get some weird run time core dumps. I
>>talked to the orginal authour of the code, and was told that this
>>might because my system is running out of swap space?
>
>If you don't get any messages on the console, I find it unlikely that 
>the core dumps are being cause by running out of swap space.  Not 
>impossible, just unlikely.

One of the minor problems with ODT1.0 is that the xterm can not be a
console. For example on a sun running the mit X distribution xterm -C
?? sets the xterm to be the console. becuase I do not have a console
all errors are redirected to /dev/null. I will try sending them to a
log file instead

-- 
-----------------------------------------------------------------
                  "bede-bede-bede Thats all Folks"
				Porky Pig
Andy Davidson

shwake@raysnec.UUCP (Ray Shwake) (04/25/91)

mark@loki.une.oz.au (Mark Garrett ) writes:

>From article <1991Apr23.214037.16410@netcom.COM>, by aed@netcom.COM (Andrew Davidson):
>	As a general rule for reasonable performace 2 to 3 times your real
>memory ie. 16 to 24Mb swap for 8Mb ram

	While this may be the optimum in a given case, as a rule of thumb it
	lacks logic. It implies that, when increasing memory one should also
	increase swap, which is nonsense.

>	What your should be doing however is have a look at the amount of
>swap that your system requires and buy 1/2 to 1/3 that much ram. ie. its no
>good haveing 24Mb swap if your average demand is >= 24Mb . 

	This gets closer to a logical connection. Note your maximum
	anticipated demand. A reasonable fraction of that (say 1/4 - 1/2)
	should be RAM; the rest would be swap. As available RAM approaches
	anticipated demand, one can *decrease* that allocated for swap,
	and put it to better use. As a rule, one is safer over-estimating
	anticipated demand.


-----------  
uunet!media!ka3ovk!raysnec!shwake				shwake@rsxtech

terry@jgaltstl.UUCP (terry linhardt) (04/26/91)

In article <1991Apr24.123035.4193@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> aed@netcom.COM (Andrew Davidson) writes:
> 
> >I am currently trying to port an application from a sun sparc station
> >to SCO ODT UNIX. I seem to get some weird run time core dumps. I
> >talked to the orginal authour of the code, and was told that this
> >might because my system is running out of swap space?
> 
> 
> >HOW BIG SHOULD MY SWAP BE? I have 8megs of ram
> 
> My general rule of thumb is 2x your memory (or 16mb for your system).  Of
> 
I've often wondered where the recommendation that 2 - 3x real memory should
be made available to swap comes from? Wouldn't this depend upon
whether or not the system is swapping at all? For instance, let's
say you have 48 meg of memory, and no swapping. Does this mean
I should tie up 100 - 150 meg of disk space for swap? Also, isn't
there less need for swap space with paging systems?

I would like to see some thoughts on the validity of these
rule-of-thumb recommendations. Not saying they are wrong, but would
like to know the justification behind them.

-- 
|---------------------------------------------------------------------|
|  Terry Linhardt      The Lafayette Group      uunet!jgaltstl!terry  | 
|---------------------------------------------------------------------|

jay@metran.UUCP (Jay Ts) (04/26/91)

In article <1991Apr24.123035.4193@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
> aed@netcom.COM (Andrew Davidson) writes:
>
> >ARE THERE ANY TOOLS TO HELP ME MANAGE / MONITOR MY SWAP SPACE?
> 
> sar(1) will help you monitor it. (and will also tell you if you ran out
> of swap space).

Also, there is u386mon, from the net.  It displays memory in use and swap
space used in "near real time".  It's more entertaining than sar, and
easier to use, but not as definitive.

sar is better, but u386mon is more fun :-)

(Also, note that the current version of u386mon dumps core on ISC 2.2
systems if you try to access the process screen.  On at least one system,
anyway...)

Jay Ts, Director
Metran Technology
uunet!pdn!tscs!metran!jay

cpcahil@virtech.uucp (Conor P. Cahill) (04/26/91)

terry@jgaltstl.UUCP (terry linhardt) writes:

>I've often wondered where the recommendation that 2 - 3x real memory should
>be made available to swap comes from? Wouldn't this depend upon
>whether or not the system is swapping at all? For instance, let's
>say you have 48 meg of memory, and no swapping. Does this mean
>I should tie up 100 - 150 meg of disk space for swap? Also, isn't
>there less need for swap space with paging systems?

100MB of disk sounds like a lot to waste, but in a system with 48MB you
are probably going to have something like 1 or 2 GB, so 100MB looks
much smaller in that context.

You do not want to run out of swap space.  If that means you over-configure
a bit, so be it.

>I would like to see some thoughts on the validity of these
>rule-of-thumb recommendations. Not saying they are wrong, but would
>like to know the justification behind them.

And I'm not saying they are right.  However, with those rules of thumb and
some guessing as to the intended load, I have never had a system that I 
configured run out of swap.  It's a small price to pay for some real sanity.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

cpcahil@virtech.uucp (Conor P. Cahill) (04/27/91)

aed@netcom.COM (Andrew Davidson) writes:

>One of the minor problems with ODT1.0 is that the xterm can not be a
>console. For example on a sun running the mit X distribution xterm -C
>?? sets the xterm to be the console. becuase I do not have a console
>all errors are redirected to /dev/null. I will try sending them to a
>log file instead

Now I may be showing my ignorance wrt SCO, but most 386 unix X products 
start up the X display on a VT (i.e. not the console).  Switching the
VT to the console will enable you to see if any messages appeared there.

Of course, while you are looking at the console you can't see/access you 
X application, but at least it provides a mechanism that allows you 
to access the console.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 

witr@rwwa.COM (Robert Withrow) (04/27/91)

In article <1991Apr26.142301.6486@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
|100MB of disk sounds like a lot to waste,
... and
|You do not want to run out of swap space.  If that means you over-configure
|a bit, so be it.

Disk space is wasted only if it really *is* wasted, i.e. unused.  If
you need 100 MB of swap space then using 100MB is not wastefull.

On the on the other hand, you must recogonize that the required size
of the swap space is a function of many variables, only one of which
is the size of memory.  This I would not blindly follow any rule that
says that ``swap space should be 2-3 times the size of memory''.
There are a number of implicit assumptions in this sort of rule that
are ulikely to be true in many systems.  The same can be said for the
sizes of various kernel parameters.  

Things to consider:

  1) the true ``minimum size'':  e.g. in SVR4 the minimum size of swap
space == size of memory, due to the swapping algorithms.

  2) memory requirements of your workload.

  3) the number of (simultaneous) users.

  4) the criticality of the workload (i.e. what harm would be caused
by running out of swap space). In single user configurations, the harm
caused is often not more than annoyance and some wasted time.  In
multiuser production environments it would likely result in expensive
loss of productivity.

  5) The use that could be made of the disk space if it were not used
for swapping.

As a data point, I have found that with 16MB of memory, in a
workstation (e.g. single user with uucp, network, and program
development workload [with X windows]) environment, 1.5 x memory is
perfectly adequate for the swap space (using SVR3.2 and SVR4).  In
fact, I think the swap space could be made even smaller and I would
still not have any problems.

The bottom line is: there is no simple formula to refer to.

-- 
---
 Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA
 Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM

bill@bilver.uucp (Bill Vermillion) (04/28/91)

In article <455@jgaltstl.UUCP> terry@jgaltstl.UUCP (terry linhardt) writes:

>In article <1991Apr24.123035.4193@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:

  
>> >HOW BIG SHOULD MY SWAP BE? I have 8megs of ram
    
>> My general rule of thumb is 2x your memory (or 16mb for your system).  Of
   
>I would like to see some thoughts on the validity of these
>rule-of-thumb recommendations. Not saying they are wrong, but would
>like to know the justification behind them.

And of course rule-of-thumb doesn't always apply.   

These are from memory last week.

Docs on the Lotus 123 for Unix/Xenix package say something like

4 Meg of Ram Required ( and then goes on to say more is better).

And it want about 10 megs of swap, but would prefer 24 megs.
In this instance,  the package seems to infer that anywhere from 3 to 6
times your memory would be good - if you had minimum ram.  It indicates int
he package that is needs a lot of swap space.

It also said it wouldn't run on a '486.  (Just threw that in - and
wondering exactly how they wrote the code that will make it not work on a
'486.  - argh!)


-- 
Bill Vermillion - UUCP: uunet!tarpit!bilver!bill
                      : bill@bilver.UUCP

phillip@BARTAL.COM (Phillip M. Vogel) (04/28/91)

In article <1991Apr23.214037.16410@netcom.COM> aed@netcom.COM (Andrew Davidson) writes:
>
> HOW BIG SHOULD MY SWAP BE? I have 8megs of ram

I would like to add a word or so to this thread, based on a
'learning experience' that I had a while back.

Make your swap space AT LEAST as large as you ever expect your
ram to get.  My system originally had 4 megs of ram, and the ISC
installation script suggested something like 5 meg of swap space.
Later on, I added another 4 meg of ram, and some more swap space
on a second drive.  Everything was fine until the kernel paniced
for some reason I've since forgotten, and dumped core.

When the kernel dumps core, it puts the core dump into the swap
area ON THE PRIMARY DISK. Well, 8 megs of core dump into 5 megs
of disk space sort of leaked out and trashed my root filesystem.
Live and learn. This one surely was not in TFM.
	Phillip
--
Phillip M. Vogel, President             | #include "/disclaimers/std.h"
Bartal Design Group, Inc.               | Domain: phillip@bartal.com
318 Marlboro Road, Englewood, NJ 07631  | (201)567-1343   FAX:(201)568-2891

terry@jgaltstl.UUCP (terry linhardt) (04/28/91)

In article <306@raysnec.UUCP+, shwake@raysnec.UUCP (Ray Shwake) writes:
+ +	As a general rule for reasonable performace 2 to 3 times your real
+ +memory ie. 16 to 24Mb swap for 8Mb ram
+ 
+ 	While this may be the optimum in a given case, as a rule of thumb it
+ 	lacks logic. It implies that, when increasing memory one should also
+ 	increase swap, which is nonsense.

I would agree with this
+ 
+ 
+ 	This gets closer to a logical connection. Note your maximum
+ 	anticipated demand. A reasonable fraction of that (say 1/4 - 1/2)
        ^^^^^^^^^^^^^^^^^^^ 
 
 And how does one calculate anticipated demand?

-- 
|---------------------------------------------------------------------|
|  Terry Linhardt      The Lafayette Group      uunet!jgaltstl!terry  | 
|---------------------------------------------------------------------|

mike@bria.UUCP (Michael Stefanik) (04/28/91)

In an article, phillip@BARTAL.COM (Phillip M. Vogel) writes:
>Make your swap space AT LEAST as large as you ever expect your
>ram to get. 

Actually, I would take this number and double it.  I wouldn't think
about configuring our smallest machines with less than 8M of swap.
Take your physical memory, at half that again, and then double the
whole thing.  That means that an 8M system would have 24M of swap.
You won't go wrong when you bump up your core (which, with only 8M,
hopefully will be done shortly :-)

Remember, a machine with less than 16 is too damn lean!
-- 
Michael Stefanik, MGI Inc, Los Angeles | Opinions stated are never realistic
Title of the week: Systems Engineer    | UUCP: ...!uunet!bria!mike
-------------------------------------------------------------------------------
If MS-DOS didn't exist, who would UNIX programmers have to make fun of?

marc@dumbcat.sf.ca.us (Marco S Hyman) (04/29/91)

In article <455@jgaltstl.UUCP> terry@jgaltstl.UUCP (terry linhardt) writes:
 > I've often wondered where the recommendation that 2 - 3x real memory should
 > be made available to swap comes from? Wouldn't this depend upon
 > whether or not the system is swapping at all? For instance, let's
 > say you have 48 meg of memory, and no swapping. Does this mean
 > I should tie up 100 - 150 meg of disk space for swap?

Hmmm.  I seem to remember that Berkeley UNIX allocates swap space at exec time
to ensure a process can be swapped out later. (I can't verify this right
now... it may be a false statement.)  If true, you'll have to allocate that
disk space even if it's never used.  I just looked thru Bach's "The Design of
the UNIX Operating System" and don't see a similar requirement for System V.
I wonder about System V Release 4, though.  Does anybody know?

 >  Also, isn't there less need for swap space with paging systems?

When a process is swapped only the active pages are written to the swap
device.  The swapped out process is placed in a state "ready to run but
swapped."  These processes are not swapped back into memory in their entirety
-- they are allowed to page fault back in off of the swap device.

-- 
// marc
// home: marc@dumbcat.sf.ca.us		pacbell!dumbcat!marc
// work: marc@ascend.com		uunet!aria!marc

garyb@gallium.uucp (Gary Blumenstein) (04/30/91)

In article <17@metran.UUCP> jay@metran.UUCP (Jay Ts) writes:
>
>(Also, note that the current version of u386mon dumps core on ISC 2.2
>systems if you try to access the process screen.  On at least one system,
>anyway...)

Not here.  u386mon runs fine in all screens.  25 line, 43 line, in an xpcterm
window with color, w/o color, and on a virtual terminal.  Mine is version
2.00.

- Gary
-- 
Gary M. Blumenstein
garyb@gallium.UUCP

jackv@turnkey.tcc.com (Jack F. Vogel) (05/02/91)

In article <455@jgaltstl.UUCP> terry@jgaltstl.UUCP (terry linhardt) writes:

>I've often wondered where the recommendation that 2 - 3x real memory should
>be made available to swap comes from? Wouldn't this depend upon
>whether or not the system is swapping at all? For instance, let's
>say you have 48 meg of memory, and no swapping. Does this mean
>I should tie up 100 - 150 meg of disk space for swap? Also, isn't
>there less need for swap space with paging systems?
 
I think people are often unaware, due to its name, "swap" device that this
space serves a dual role. It is not only a place to store "swapped" processes
it is also where the pager (vhand) writes pages that it steals. When demand
on real memory reaches a certain low water mark, the pager examines all user
processes and "steals" pages that haven't been referenced for a while. This
means it writes that page to the swap device and then returns the underlying
page frame to the free pool. When the system is properly configured, the
pager should do all the work, swapping shouldn't occur, the swapper (sched)
should only be invoked because the pager simply can't keep enough memory
free by stealing.

So, a more technical algorithm for determining required swap space might be
'the total virtual memory demand on the system' or 'the sum of the resident
sets of all processes running on the system'. This value should be equal
to your main memory + swap space. How do you determine this value? Well,
that's why they come up with simple "rules of thumb" :-}!

Disclaimer: These opinions are my own, not necessarily my employer's.


-- 
Jack F. Vogel			jackv@locus.com
AIX370 Technical Support	       - or -
Locus Computing Corp.		jackv@turnkey.TCC.COM

wes@harem.clydeunix.com (Wes Peters) (05/06/91)

In article <296@dumbcat.sf.ca.us>, marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
> Hmmm.  I seem to remember that Berkeley UNIX allocates swap space at exec time
> to ensure a process can be swapped out later. (I can't verify this right
> now... it may be a false statement.)  If true, you'll have to allocate that
> disk space even if it's never used.  I just looked thru Bach's "The Design of
> the UNIX Operating System" and don't see a similar requirement for System V.
> I wonder about System V Release 4, though.  Does anybody know?

It was there in Bach, just not under the heading "swap."  If you look under
the description of exec, the algorithm mentions that space is allocated for
each region in the executable file, and points you to the algorithm
'allocreg.'  This is essentially where 'swap' space, actually 'page' space
in paging systems, is allocated.

> When a process is swapped only the active pages are written to the swap
> device.  The swapped out process is placed in a state "ready to run but
> swapped."  These processes are not swapped back into memory in their entirety
> -- they are allowed to page fault back in off of the swap device.

I think System V.3 does this at fork/exec calls, too.  I remember hearing
somewhere about 'direct page-in,' i.e. when you fork or exec, the system
merely pages in the first executable page (or block of pages) and starts it;
the rest of the process is paged in as needed.  Supposed to make programs
start faster or something like that.

	Wes Peters
-- 
#include <std/disclaimer.h>                               The worst day sailing
My opinions, your screen.                                   is much better than
Raxco had nothing to do with this!                        the best day at work.
     Wes Peters:  wes@harem.clydeunix.com   ...!sun!unislc!harem!wes

tmh@prosun.first.gmd.de (Thomas Hoberg) (05/08/91)

In article <455@jgaltstl.UUCP>, terry@jgaltstl.UUCP (terry linhardt) writes:
|> In article <1991Apr24.123035.4193@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
|> > aed@netcom.COM (Andrew Davidson) writes:
|> > 
|> > >HOW BIG SHOULD MY SWAP BE? I have 8megs of ram
|> > 
|> > My general rule of thumb is 2x your memory (or 16mb for your system).  Of
|> > 
|> I've often wondered where the recommendation that 2 - 3x real memory should
|> be made available to swap comes from? Wouldn't this depend upon
|> whether or not the system is swapping at all? For instance, let's
|> say you have 48 meg of memory, and no swapping. Does this mean
|> I should tie up 100 - 150 meg of disk space for swap? Also, isn't
|> there less need for swap space with paging systems?

Nowadays when people talk about swapping, most of the time they really mean
paging. If I had to work with a machine that was swapping X-Servers and Clients,
I'd ask for twice may salary to make up for the mental abuse.

|> 
|> I would like to see some thoughts on the validity of these
|> rule-of-thumb recommendations. Not saying they are wrong, but would
|> like to know the justification behind them.
I'd say that the 2-3x ratio is from the old days when the average mini had 1MB
RAM and the disk to memory access ratio wan't quite as bad as it is now. Now if
it comes to the point where running processes steal pages from each others active
sets, you might as well switch it off. Today's rule of thumb is "it depends..."
It depends on the CPU, disk speed, main memory, number of users, types of
applications run, locality of reference, the day of the week and the mood of the
operator. I personally use 100-150% of what I have in main memory for swap space.
I don't make it less, because I want the system dumps to fit onto it. If the
paging is percetible, I add more RAM.
|> 
|> -- 
|> |---------------------------------------------------------------------|
|> |  Terry Linhardt      The Lafayette Group      uunet!jgaltstl!terry  | 
|> |---------------------------------------------------------------------|

-- 
----
Thomas M. Hoberg   | UUCP: tmh@bigfoot.first.gmd.de  or  tmh%gmdtub@tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or
+49-30-254 99 160  |         tmh@tub.BITNET