|
Home > Archive > Unix Programming > January 2004 > Finding memory leaks through ps command
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Finding memory leaks through ps command
|
|
| qazmlp 2004-01-23, 5:11 pm |
| 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?
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
qazmlp1209@rediffmail.com (qazmlp) wrote:
quote:
> 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
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
qazmlp1209@rediffmail.com (qazmlp) wrote:
quote:
> 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
| |
| Michael Vilain 2004-01-23, 5:11 pm |
| In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
Barry Margolin <barmar@alum.mit.edu> wrote:
quote:
> In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
> qazmlp1209@rediffmail.com (qazmlp) wrote:
>
>
> 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...
| |
| Scott Lacy Smith 2004-01-23, 5:11 pm |
| On 1 Jan 2004 19:35:44 -0800, qazmlp <qazmlp1209@rediffmail.com> wrote:quote:
> 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"
| |
| Michael Vilain 2004-01-23, 5:11 pm |
| In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
Barry Margolin <barmar@alum.mit.edu> wrote:
quote:
> In article <db9bbf31.0401011935.374f8f54@posting.google.com>,
> qazmlp1209@rediffmail.com (qazmlp) wrote:
>
>
> 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...
| |
| Scott Lacy Smith 2004-01-23, 5:11 pm |
| On 1 Jan 2004 19:35:44 -0800, qazmlp <qazmlp1209@rediffmail.com> wrote:quote:
> 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"
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <vilain-3994C3.22200301012004@comcast.ash.giganews.com>,
"Michael Vilain <vilain@spamcop.net>" wrote:
quote:
> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
> Barry Margolin <barmar@alum.mit.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'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).
quote:
> 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
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <vilain-3994C3.22200301012004@comcast.ash.giganews.com>,
"Michael Vilain <vilain@spamcop.net>" wrote:
quote:
> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
> Barry Margolin <barmar@alum.mit.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'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).
quote:
> 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
| |
| Neil W Rickert 2004-01-23, 5:11 pm |
| "Michael Vilain <vilain@spamcop.net>" writes:quote:
> Barry Margolin <barmar@alum.mit.edu> wrote:
[QUOTE][color=darkred]
[QUOTE][color=darkred]
[QUOTE][color=darkred]
>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.
| |
| Neil W Rickert 2004-01-23, 5:11 pm |
| "Michael Vilain <vilain@spamcop.net>" writes:quote:
> Barry Margolin <barmar@alum.mit.edu> wrote:
[QUOTE][color=darkred]
[QUOTE][color=darkred]
[QUOTE][color=darkred]
>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.
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <bt3tng$e98$3@usenet.cso.niu.edu>,
Neil W Rickert <rickert+nn@cs.niu.edu> wrote:
quote:
>
> 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
| |
| Jeff Schwab 2004-01-23, 5:11 pm |
| "Michael Vilain " wrote:quote:
> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
> Barry Margolin <barmar@alum.mit.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.
> 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.
| |
| joe@invalid.address 2004-01-23, 5:11 pm |
| Jeff Schwab <jeffplus@comcast.net> writes:
quote:
> "Michael Vilain " wrote:
[QUOTE][color=darkred]
>
> 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
| |
| Barry Margolin 2004-01-23, 5:11 pm |
| In article <bt3tng$e98$3@usenet.cso.niu.edu>,
Neil W Rickert <rickert+nn@cs.niu.edu> wrote:
quote:
>
> 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
| |
| Jeff Schwab 2004-01-23, 5:11 pm |
| "Michael Vilain " wrote:quote:
> In article <barmar-83AF75.23221001012004@netnews.attbi.com>,
> Barry Margolin <barmar@alum.mit.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.
> 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 2004-01-23, 5:11 pm |
| joe@invalid.address wrote:
quote:
>
> 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.
| |
| joe@invalid.address 2004-01-23, 5:12 pm |
| Jeff Schwab <jeffplus@comcast.net> writes:
quote:
> "Michael Vilain " wrote:
[QUOTE][color=darkred]
>
> 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
| |
| Jeff Schwab 2004-01-23, 5:12 pm |
| joe@invalid.address wrote:
quote:
>
> 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.
| |
| Barry Margolin 2004-01-23, 5:12 pm |
| In article <35idne2-6s3-QmiiRVn-hQ@comcast.com>,
Jeff Schwab <jeffplus@comcast.net> wrote:
quote:
> 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
| |
| Barry Margolin 2004-01-23, 5:12 pm |
| In article <35idne2-6s3-QmiiRVn-hQ@comcast.com>,
Jeff Schwab <jeffplus@comcast.net> wrote:
quote:
> 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
| |
| Raghavendra 2004-01-23, 5:12 pm |
| qazmlp1209@rediffmail.com (qazmlp) wrote in message news:<db9bbf31.0401011935.374f8f54@posting.google.com>...quote:
> 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.
| |
| Raghavendra 2004-01-23, 5:12 pm |
| qazmlp1209@rediffmail.com (qazmlp) wrote in message news:<db9bbf31.0401011935.374f8f54@posting.google.com>...quote:
> 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.
|
|
|
|
|