From: Doggy \(tru64\) (tru64dog@yahoo.com)
Date: Wed Jul 24 2002 - 13:26:50 EDT
Original Question
====================
> First of all, I have read documents about RAM and
SWAP
> space and I'm still confused on what to look at if I
> want to get accurate information about process
memory
> utilization. Do I want to look at swap space or RAM,
> or both? I have a program that will die once it
> exceeds a certian threshold of memory or paging. So,
I
> want to either write a script or find the proper ps
> command that will indicate when a process, or child
of
> a parent process, to indicate its stats on memory or
> paging--preferrably in percentage units. So when it
> hits a certian percentage, I can incorporate that in
> my script to warn me.
>
>
> To all of you that recommended the system monitoring
> tool, "Big Brother". THANK YOU! Then I want to
> incorporate this request into Big Brother, but thats
> another bridge to cross. My main objective in this
> email is to the first paragraph. Thanks in advance.
>
=====================
I would like to thank Alan from CPQ, Jerry, and Kat
from MINDiq
The answers are below:
"ps u" will tell you how much virtual and real memory
the
process is using. You can vary the amount it can use
of available swap by using the "limit" command (at
least
in the C shell). You haven't said how much you need;
you may need to add swap. Or convert to lazy swap if
you never actually swap and have enough real memory.
- Jerry Berkman, UC Berkeley
=============
RSS or RSZ ( Resident Stack Size) = Physical Memory
VSS or VSZ = virtual stack size = virtual pages = swap
usage
The two headings above should help. They very from
system to system
whether it is S or Z at the end. But all Unixs are
the same. The
"ulimit" settings can cause something to crash also.
You might want to
double check you aren't limiting it there.
Hope this helps,
Ciao
Kat
MindIQ
=======================
At the most gross level, process memory usage is
represented
by two values; virtual memory and real memory. The
virtual
memory of the process is the total memory space it
could
use if every page were resident at once. Processes
rarely
need to use all their memory and the kernel will keep
the
idle pages from taking up real memory. The real
memory
is what the process is actually using.
Some memory can be shared with other processes and I
think
Tru64 UNIX aggressively tries to share as much as
possible.
Program instructions, commonly called "text", are
easily
shared with other instances of the same program, so
there
may only be a single copy of the text pages of a
program.
Data is often assumed to be read-only, until actually
changed, which means there only needs to be a single
copy
of that initially. Process and thread stacks are
probably
assumed to be unshared, but real pages are only
allocated
as needed.
ps(1) with appropriate options (I use aux) will show
the
virtual and real memory usage of a process. There
may be
options that will show this per-thread, but I don't
really
know for sure.
No volume of paging should cause a program to die, so
that
shouldn't be a problem. A shortage of real memory
should
also not cause a program to fail. If may run very
poorly
having to page or swap, but it will continue to run.
Programs do have limits on the amount of virtual
memory
they're allowed to have, these limits controlled by
system
configuration parameters. There are separate
parameters
for stack and data space. The parameters have two
values;
maximum and default. The default can be raised to
the
maximum using commands built into most shells. The
usual
choice are limit and ulimit.
Your symtom of a program dying sounds like a program
reaching
the virtual memory for stack or data and then
failing. During
runtime this can be cause by a lot of recursion using
stack data
or dynamic memory allocation using data space.
Nearly every page of stack and data needs to have
page/swap
space reserved for it in the default page/swap
reservation
mode. Running out of page/swap space will also cause
programs
to fail as they try to create more virtual memory. I
think
text can always be paged back in from the original
executable,
so it doesn't need explicit page/swap space. Virtual
memory
created with the mmap(2) system call can provide its
own
page/swap space, not using the rest of the system's.
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:47 EDT