Kbase 17822: Tools used to monitor memory utilization on Solaris 2.x
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/12/1998 |
|
Tools used to monitor memory utilization on Solaris 2.x
When analyzing process memory utilization, a V8 Progress client
executable in most cases, using a PS listing, will report a larger
amount of memory being utilized than previously in V7.x
In Version 8 Progress changed the way we attach to shared memory per
Sun's recommendations to improve performance. Within the SHMAT()
call to address shared memory, we added the SHM_SHARE_MMU flag
set to TRUE to take advantage of virtual memory resources in
addition to memory itself so that the same shared memory is shared
among processes. A side-affect of this flag shows that the SZ
of the PS command, where virtual address space is reported, will now
include the shared segments created by the database broker that
the Progress clients are mapped to. This does in no way indicate
the process is now using more real memory but will make it more
difficult to calculate what is real memory and what is virtually
mapped to real memory(in pages).
A process' stack is divided into several categories:
1. TEXT - this is the executable's code, which can be shared or can
be pure text loaded into memory. See man pages for SIZE and FILE
commands on how to determine the size of pure vs shared text.
2. DATA - this is static data that was created when the executable
was linked.
3. STACK - this is a data area that grows as one function calls
another and shrinks when a function returns.
4. HEAP - this is a data area which expands when malloc is called.
It does not shrink when free is called. Instead the freed memory is
held in a free list so that it can be reused by later malloc calls.
In addition to these, there are shared memory segments created by
the Progress database broker, such as shared libraries, C runtime
libraries, etc. Since all this memory is virtual, the total virtual
size of a process can be much larger than the physical memory on the
system. the tools that one uses to look at processes can give very
different interpretations of what is real and what is virtual.
For example, a client process connected to a database broker started
with a -B 1000, where the OS file system blocksize is 1K, would
display a PS listing with a SZ of 5446.
The SZ field shows the size(in pages) of the swappable process's image
in main memory. However, due to the way we address memory in V8.x
the shared memory segments are now included. Please keep in mind that
the Progress executable size increased between V7 and V8.
-B 1000 * (1024bytes) = approx. 1024K = size of shared segment
Progress V8.2C - Note the SZ column of 5446
# ps -elf | grep _progres
F S UID PID PPID C PRI NI ADDR SZ WCHAN
STIME TTY TIME CMD
8 S user2 21387 21362 0 99 20 f5e12670 5446 f5cdb14e
11:46:33 pts/16 0:01 /usr2/82B/dlc/bin/_progres db8
Progress V7.3E - Note the SZ column of 1603
# /bin/ps -elf | grep _progres
8 S user2 10641 10618 2 61 20 f606ecc8 1603 f644c866 15:58:28 p
ts/14 0:01 /usr2/73E/dlc/bin/_progres db7
*NOTE* /usr/proc/bin/pmap is a supported utility from Sun MicroSystems
that will break down each process's stack including executable text,
heap, stack, virtual address space, etc.
For more information on how to calculate how much memory a process
utilizes, please refer to the below links or contact SUN Technical
Support.
1. Sizing up memory in Solaris - SunWorld - March 1998
http://www.sun.com/sunworldonline/
swol-03-1998/swol-03-perf.html
2. You want to also pick up Adrian Cockcroft's cool little
performance tool which monitors the whole system, CPU, and memory.
3. The SE Performance Toolkit - Release 3.0
http://www.sun.com/sun-on-net/performance/se3/
Progress Software Technical Support Note # 17822