I am on Solaris 8 and I'm trying to monitor a process for memory
utilization to check for memory leaks.

I am using ps,  Should I be looking at rss (resident set size) or vsz
(total size in virtual memory)?  ... and what is the difference?

any help is appreciated.

-Corey Goldberg

On Tue, 8 Jun 2004, Corey_G wrote:

> I am using ps,  Should I be looking at rss (resident set size) or vsz
> (total size in virtual memory)?  ... and what is the difference?

The latter.  Resident set size (as its name suggests) is the amount
of the process' virtual memory that is resident in RAM (as opposed
to paged out on disk).  The total virtual memory usage is the RSS
plus whatever has been paged out.

Note that a process that keeps increasing in size is not necessarily
indicative of a memory leak.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

> Resident set size (as its name suggests) is the amount
> of the process' virtual memory that is resident in RAM (as opposed
> to paged out on disk).  The total virtual memory usage is the RSS
> plus whatever has been paged out.

thanks!

> Note that a process that keeps increasing in size is not necessarily
> indicative of a memory leak.

ok.. then how would i detect a memory leak? (the process is a C++ program)

and why would a process continually grow in size?

-Corey

> Resident set size (as its name suggests) is the amount
> of the process' virtual memory that is resident in RAM (as opposed
> to paged out on disk).  The total virtual memory usage is the RSS
> plus whatever has been paged out.

thanks!

> Note that a process that keeps increasing in size is not necessarily
> indicative of a memory leak.

ok.. then how would i detect a memory leak? (the process is a C++ program)

and why would a process continually grow in size?

-Corey

On Tue, 8 Jun 2004, Corey_G wrote:

> ok.. then how would i detect a memory leak? (the process is a C++ program)

They can be difficult to track down, but some tools include
libumem (newer version of Solaris 9 (and S10) only), watchmalloc.so,
and 3rd party checkers.  I think one is called Purify.

You might use truss (or dtrace) to see if mallocs have a corresponding
free.  Also, if you have access to the source, a code inspection
might bring any memory leaks to light - although if it's a big
program, this could be quite a daunting task!

> and why would a process continually grow in size?

Memory that is free()ed is not actually returned to the OS
until the process terminates, so many cycles of allocating
and freeing progressively bigger chnks of memory will cause
the process to grow.

It is also possible that a process' data set size grows.
Consider nscd or BIND on a busy server that does lots of
name look ups.  After a few days' service, these processes
can become quite large.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Rich Teer wrote:
> On Tue, 8 Jun 2004, Corey_G wrote:
> 
> 
>>ok.. then how would i detect a memory leak? (the process is a C++ program)
> 
> 
> They can be difficult to track down, but some tools include
> libumem (newer version of Solaris 9 (and S10) only), watchmalloc.so,
> and 3rd party checkers.  I think one is called Purify.
> 
> You might use truss (or dtrace) to see if mallocs have a corresponding
> free.  Also, if you have access to the source, a code inspection
> might bring any memory leaks to light - although if it's a big
> program, this could be quite a daunting task!
> 
> 
>>and why would a process continually grow in size?
> 
> 
> Memory that is free()ed is not actually returned to the OS
> until the process terminates, so many cycles of allocating
> and freeing progressively bigger chnks of memory will cause
> the process to grow.
> 
> It is also possible that a process' data set size grows.
> Consider nscd or BIND on a busy server that does lots of
> name look ups.  After a few days' service, these processes
> can become quite large.
> 


A colleague of mine has just submitted a troubleshooting document to 
sunsolve on using lubumem to track down memory leaks. Once it's gone 
through it's reviews it should be in the public collection (I would 
certainly hope not much more than a week). Keep an eye out for 
troubleshooting document 76774 "Troubleshooting userland memory leaks 
with libumem(3LIB)"


alan.
-- 
Alan Hargreaves
Senior Technical Support Specialist/VOSJEC Engineer
Product Technical Support (APAC)
Sun Microsystems