What are the parameters/arguments of 'ps' command can be used to track
whether there are memory leaks from a process in its long run?

In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
 qazmlp1209@rediffmail.com (qazmlp) wrote:

> What are the parameters/arguments of 'ps' command can be used to track
> whether there are memory leaks from a process in its long run?

Look at the SZ column of the long format.  If it's consistently 
increasing, it *may* indicate a memory leak.  It could also be a result 
of the program constantly adding new data to its memory (e.g. a name 
server caching more responses as time goes on).

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
 Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
>  qazmlp1209@rediffmail.com (qazmlp) wrote:
> 
> > What are the parameters/arguments of 'ps' command can be used to track
> > whether there are memory leaks from a process in its long run?
> 
> Look at the SZ column of the long format.  If it's consistently 
> increasing, it *may* indicate a memory leak.  It could also be a result 
> of the program constantly adding new data to its memory (e.g. a name 
> server caching more responses as time goes on).

It was my understanding that the only way to detect leaks is to 
'instrument' the application with a memory leak detector like Purify.  
I'm not aware of any tools that work for Java since that's not compiled 
code.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...

On 1 Jan 2004 19:35:44 -0800, qazmlp <qazmlp1209@rediffmail.com> wrote:
> What are the parameters/arguments of 'ps' command can be used to track
> whether there are memory leaks from a process in its long run?

If your application can be easily ported to x86 Linux, you might try 
using Valgrind to find leaks.


-- 
Scott Lacy Smith  <scottlacysmith@qwest.net>
   "Nullus Anxietas" 

In article <vilain-3994C3.22200301012004@comcast.ash.giganews.com>,
 "Michael Vilain <vilain@spamcop.net>" wrote:

> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
>  Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
> >  qazmlp1209@rediffmail.com (qazmlp) wrote:
> > 
> > > What are the parameters/arguments of 'ps' command can be used to track
> > > whether there are memory leaks from a process in its long run?
> > 
> > Look at the SZ column of the long format.  If it's consistently 
> > increasing, it *may* indicate a memory leak.  It could also be a result 
> > of the program constantly adding new data to its memory (e.g. a name 
> > server caching more responses as time goes on).
> 
> It was my understanding that the only way to detect leaks is to 
> 'instrument' the application with a memory leak detector like Purify.  

That's why I carefully said "may indicate a memory leak".  If the memory 
size isn't increasing, then you probably don't have a leak (if you do, 
it's presumably a very slow one).

> I'm not aware of any tools that work for Java since that's not compiled 
> code.

In the case of Java, you'd need to instrument the JVM itself.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

"Michael Vilain <vilain@spamcop.net>" writes:
> Barry Margolin <barmar@alum.mit.edu> wrote:
>>  qazmlp1209@rediffmail.com (qazmlp) wrote:

>> > What are the parameters/arguments of 'ps' command can be used to track
>> > whether there are memory leaks from a process in its long run?

>> Look at the SZ column of the long format.  If it's consistently 
>> increasing, it *may* indicate a memory leak.  It could also be a result 
>> of the program constantly adding new data to its memory (e.g. a name 
>> server caching more responses as time goes on).

>It was my understanding that the only way to detect leaks is to 
>'instrument' the application with a memory leak detector like Purify.  

That may be the way to *prove* that there is a memory leak.  However,
when I see a process with name "printd" (really "lp") using 187M of
memory, I can be pretty sure that it is mismanaging memory in some
manner.

I guess it is time to kill that process.

In article <bt3tng$e98$3@usenet.cso.niu.edu>,
 Neil W Rickert <rickert+nn@cs.niu.edu> wrote:

> >It was my understanding that the only way to detect leaks is to 
> >'instrument' the application with a memory leak detector like Purify.  
> 
> That may be the way to *prove* that there is a memory leak.  However,
> when I see a process with name "printd" (really "lp") using 187M of
> memory, I can be pretty sure that it is mismanaging memory in some
> manner.

Right, you have to understand the memory size in context.  To contrast 
with this example, a large Emacs process doesn't necessarily have a 
leak, it may just be because the user has lots of buffers.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

"Michael Vilain " wrote:
> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
>  Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> 
>>In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
>> qazmlp1209@rediffmail.com (qazmlp) wrote:
>>
>>
>>>What are the parameters/arguments of 'ps' command can be used to track
>>>whether there are memory leaks from a process in its long run?
>>
>>Look at the SZ column of the long format.  If it's consistently 
>>increasing, it *may* indicate a memory leak.  It could also be a result 
>>of the program constantly adding new data to its memory (e.g. a name 
>>server caching more responses as time goes on).
> 
> 
> It was my understanding that the only way to detect leaks is to 
> 'instrument' the application with a memory leak detector like Purify.  
> I'm not aware of any tools that work for Java since that's not compiled 
> code.

Yes it is.  Anyway, most implementations of Java have mark & sweep 
garbage collection, so memory leaks can't happen.  If you are concerned 
about leaks in the bytecode interpreter, you will have to follow Barry's 
suggestion, and instrument the JVM itself.

Jeff Schwab <jeffplus@comcast.net> writes:

> "Michael Vilain " wrote:
> > In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
> >  Barry Margolin <barmar@alum.mit.edu> wrote:
> >
> >>In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
> >> qazmlp1209@rediffmail.com (qazmlp) wrote:
> >>
> >>
> >>>What are the parameters/arguments of 'ps' command can be used to
> >>>track whether there are memory leaks from a process in its long
> >>>run?
> >>
> >> Look at the SZ column of the long format.  If it's consistently
> >> increasing, it *may* indicate a memory leak.  It could also be a
> >> result of the program constantly adding new data to its memory
> >> (e.g. a name server caching more responses as time goes on).

> > It was my understanding that the only way to detect leaks is to
> > 'instrument' the application with a memory leak detector like
> > Purify.  I'm not aware of any tools that work for Java since
> > that's not compiled code.
> 
> Yes it is.  Anyway, most implementations of Java have mark & sweep
> garbage collection, so memory leaks can't happen.  If you are
> concerned about leaks in the bytecode interpreter, you will have to
> follow Barry's suggestion, and instrument the JVM itself.

It's not impossible for there to be memory leaks in the JVM. It's
happened before. 

If a memory leak detector isn't available on the OP's platform, it
might be worth running the program under strace/truss/whatever and
grepping for malloc and free, then trying to match them up. Maybe mmap
too if JVM uses that for memory allocation.

Joe

joe@invalid.address wrote:

>>>It was my understanding that the only way to detect leaks is to
>>>'instrument' the application with a memory leak detector like
>>>Purify.  I'm not aware of any tools that work for Java since
>>>that's not compiled code.
>>
>>Yes it is.  Anyway, most implementations of Java have mark & sweep
>>garbage collection, so memory leaks can't happen.  If you are
>>concerned about leaks in the bytecode interpreter, you will have to
>>follow Barry's suggestion, and instrument the JVM itself.
> 
> It's not impossible for there to be memory leaks in the JVM. It's
> happened before.

Understood.  Even on a working platform with only reference-counted GC, 
leaks can happen.

In article <35idne2-6s3-QmiiRVn-hQ@comcast.com>,
 Jeff Schwab <jeffplus@comcast.net> wrote:

> Yes it is.  Anyway, most implementations of Java have mark & sweep 
> garbage collection, so memory leaks can't happen.

That would prevent leaks of the application data (assuming the GC works 
properly), but not the JVM's internal data, since the JVM itself is not 
written in Java.

Also, memory leaks can happen in GC'ed languages.  If the application 
keeps references to objects that it doesn't actually need any more, they 
won't become garbage.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

qazmlp1209@rediffmail.com (qazmlp) wrote in message news:<db9bbf31.0401011935.374f8f54@posting.google.com>...
> What are the parameters/arguments of 'ps' command can be used to track
> whether there are memory leaks from a process in its long run?

try "ps -l".

raghavendra.