My original questions were:
How much memory could I expect to use in a process before paging starts if no
other user processes are running on the system? How can I increase the amount
of usable physical memory? (Except reducing the size of the kernel and other
running processes.)
What does the VSZ and RSS that ps displays for [kernel idle] REALLY mean? The
VSZ for [kernel idle] can get VERY large!
Does lazy/eager swap have any impact on this?
-------------
I got four answers. Two of them misunderstood my question about RSS and VSZ for
[kernel idle]. I was wondering what the numbers for [kernel idle] meant, not
what the names RSS and VSZ meant. (I got no good answer to this one.)
To the other questions I got one mail from Paul E. Rockwell that was really
good. It is included below. Thanks to the others who responded:
Gyula Szemenyei
Nick Hill
Knut Helleboe
/Mats
---------------
> Excuse me for wasting your bandwidth with my questions!
>
> How much memory could I expect to use in a process before paging starts if no
> other user processes are running on the system? How can I increase the amount
> of usable physical memory? (Except reducing the size of the kernel and other
> running processes.)
>
Other than adding real memory and tuning the UBC (but you have to be careful
about this!!) there isn't a whole lot you can do to increase available physical
memory. Things you can do are:
Eliminate unused kernel options
Properly size system parameters (maxusers is a big one, if oversized it
can eat a bit of memory).
Tune the UBC metadata buffer cache size (in the kernel config file, it's
called bufcache - I don't remember what the sysconfigtab entry is called
right off hand). It's defaulting to 3%. If you don't run a lot of users
and/or you use AdvFS extensively, you can probably drop this to 1%. Note that
this cache is for the UFS metadata only - data blocks come out of the UBC
- and it really doesn't have to be more than 3% except in a few cases
like an NFS server system serving a large number of clients.
Upgrading to 3.2C might help as well. There are additional kernel options
that have been made optional in this release (such as LVM and SLIP) that
you can get rid of if you aren't using them.
Don't run unnecessary processes. For example, don't bring up the X window
system on a 2100's graphics console - use a serial console instead.
X isn't tiny. Any GUI adminstration can be done from any other workstation
or X terminal.
>
> Does lazy/eager swap have any impact on this?
No it should not. This only controls how/when the system allocates swap area,
not when it's actually used in paging.
>
> I use 2100-machines with 1-3 CPUs and 128-512 MB memory. I'm running on 3.0B.
> On a 2-CPU machine with 512 MB memory I have only managed to allocate 390 MB
> before paging starts. (No filesystem activity.)
Starting to page is not such a bad idea. Other processes will not give up
pages until a available memory drops below a defined threshold value. So,
they may have stuff in their RSS that hasn't been used for a while.
Once the available memory threshold has been crossed, the system then attempts
to regain memory by paging out unused portions of other processes. until the
number of available pages is above the threshold.
Where you get into a problem is if you've oversubscribed real memory so badly
that the system is constantly paging. For example, if your program uses
so much RSS that the system has to page in other processes/daemons when
your time slice is up. So the paging happens again when your process gets
it's time slice back.
You may be able to control some of the paging behaviour if it's caused by
the Unified Buffer Cache (UBC) gaining too much of the available memory before
the demands of the anonymous VM (heap) of your program starts. UBC parameters
are documented in the performance tuning manual included with Digital UNIX.
But beware: UBC tuning can backfire since not only are data blocks kept there,
but text pages (also known as program code) as well. Caveat emptor.
Remember, nothing helps virtual like real.
--------
+---------------------------+tm Paul E. Rockwell
| | | | | | | | UNIX Sales Support Consultant
| d | i | g | i | t | a | l | Digital Equipment Corporation
| | | | | | | | 500 Enterprise Drive
+---------------------------+ Rocky Hill, CT 06067
Internet: rockwell_at_rch.dec.com Phone: (203)258-5022
---------------
===============================================================================
Mats G Karlsson E-mail: atomaka_at_ato.abb.se (__)
ABB Atom AB MEMO: ABB.SEATO.ATOMAKA (oo)
Avd: AUD Tel: +46 (0)21 347762 \/-------\
S-721 63 Vasteras Fax: +46 (0)21 347088 || | \
Sweden ||---W|| *
===============================================================================
Received on Tue Oct 10 1995 - 11:40:14 NZDT