RSS keeps increasing...Memory leaks??
qazmlp
consider that as an indication for memory leaks in the process?
Casper H.S. Dik
>RSS(resident set size) of the process keeps increasing. Can we
>consider that as an indication for memory leaks in the process?
The working set is the memory actually being used; if at the same
the SIZE grows, then the program is consuming more and more
memory; that may indicate a memory leak but it may just as well
indicate an actual need for memory.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Nick Landsberg
> qazml...@rediffmail.com (qazmlp) writes:
>
>
>>RSS(resident set size) of the process keeps increasing. Can we
>>consider that as an indication for memory leaks in the process?
>
>
> The working set is the memory actually being used; if at the same
> the SIZE grows, then the program is consuming more and more
> memory; that may indicate a memory leak but it may just as well
> indicate an actual need for memory.
>
> Casper
True, Casper
However, for a well-designed long-lived
process that should level off after a period
of time given a constant offerred load.
Initially, RSS grows pretty steeply,
the more gradually, then even more gradually
and then levels off.
If the load is constantly increasing, then
it stands to reason that the RSS will be
increasing more or less with the same slope
(if graphed). I would suggest to qazmlp to
track both the offerred load and the RSS
of the process for 48-72 hours. If it hasn't
stabilized by then, that's usually (but not
always) an indication of a memory leak somewhere.
NPL
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
qazmlp
> qazml...@rediffmail.com (qazmlp) writes:
>
> >RSS(resident set size) of the process keeps increasing. Can we
> >consider that as an indication for memory leaks in the process?
>
> The working set is the memory actually being used; if at the same
> the SIZE grows, then the program is consuming more and more
> memory; that may indicate a memory leak but it may just as well
> indicate an actual need for memory.
'ps -p <processId> -o rss, vsz, pmem' reports the following.
RSS VSZ %MEM
77592 1022288 2.6
77656 1022288 2.6
77688 1022288 2.6
77704 1022296 2.6
77704 1022296 2.6
77728 1022296 2.6
77728 1022296 2.6
77728 1022296 2.6
77760 1022296 2.6
77768 1022296 2.6
77776 1022296 2.6
As we can see above, RSS keeps increasing, but VSZ remains stable. Can
we conclude here that things are Ok i.e there are no memory leaks?
Apart from that:
The outputs for SZ and '-o vsz' seem to be same, except that, SZ
reports in terms pages and vsz in terms of KB. Am I right?
Yong Huang
> RSS(resident set size) of the process keeps increasing. Can we
> consider that as an indication for memory leaks in the process?
It depends on for how long it keeps increasing. I usually look at the
heap segment of the process virtual memory (pmap <pid> | grep heap).
Once we were using Opentext's Livelink software. In one version, the
daemon process always crashes about two hours after startup, quite
predictably. I can see the heap segment growing at a constant rate and
very frequent brk() calls in truss output. Later they reported a
memory leak bug and fixed it.
Yong Huang
qazmlp
>
> >RSS(resident set size) of the process keeps increasing. Can we
> >consider that as an indication for memory leaks in the process?
>
> The working set is the memory actually being used; if at the same
> the SIZE grows, then the program is consuming more and more
> memory; that may indicate a memory leak but it may just as well
> indicate an actual need for memory.
Also, how about the reliability of the output given by 'pmap <pid> |
grep heap'.
Can we consider it as a leak, if the heap size keeps growing?
Btw, can there be any other cause for memory leaks? If yes, the above
way may not be complete, I suppose. Could somebody clarify?
Overall, it is ambiguous about what Simple Solaris commands to use to
find out whether there are leaks are not(rather than using tools)? Is
there any descriptive paper providing complete information on it?
Rich Teer
> RSS(resident set size) of the process keeps increasing. Can we
> consider that as an indication for memory leaks in the process?
The RSS of a process with a memory leak will indeed grow.
But so will that of a process that DOESN'T, under the right
circumstances.
Memory that is free()ed is not returned to the kernel, so if
you allocate and free increasing amounts of memory, your RSS
will increase. Or you might just be caching data in memory
and don't free it deliberately by design. (To me, a memory
leak is an unintentional thing.)
--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-group.com/rich
Mark
We need to remember that traditional malloc() free()
calls are library calls and not system calls. That
means free() may not return the memory immediately to
the system.
[You can tune your malloc application to return memory
immediately to system by modifying its cache size to zero.
You can do that either on a system-wide basis or on a per
program basis. Refer man malloc]
Steve
Rich Teer <rich...@rite-group.com> wrote in message news:<Pine.SOL.4.58.0411250934221.24690@zaphod>...
Gary Schmidt
[SNIP]
> If the load is constantly increasing, then
> it stands to reason that the RSS will be
> increasing more or less with the same slope
> (if graphed). I would suggest to qazmlp to
> track both the offerred load and the RSS
> of the process for 48-72 hours. If it hasn't
> stabilized by then, that's usually (but not
> always) an indication of a memory leak somewhere.
>
48-72 hours may be nowhere near long enough.
With one of the products I work on it can take weeks for the memory
usage to stabilise, because there are things it does
weekly/fornightly/monthly.
Cheers,
Gary B-)
--
Speaking strictly for myself.
Nick Landsberg
> Nick Landsberg wrote:
> [SNIP]
>
>> If the load is constantly increasing, then
>> it stands to reason that the RSS will be
>> increasing more or less with the same slope
>> (if graphed). I would suggest to qazmlp to
>> track both the offerred load and the RSS
>> of the process for 48-72 hours. If it hasn't
>> stabilized by then, that's usually (but not
>> always) an indication of a memory leak somewhere.
>>
> The time it takes is really dependent on exactly what it does.
Absolutely. Good point!
>
> 48-72 hours may be nowhere near long enough.
>
> With one of the products I work on it can take weeks for the memory
> usage to stabilise, because there are things it does
> weekly/fornightly/monthly.
I normally deal with transaction processing apps and
was thinking mostly of those. I usually leave the
periodic stuff to another process, but that's a design
decision which everyone needs to make for themselves
based on the app.
>
> Cheers,
> Gary B-)
Bigdakine
>From: Rich Teer rich...@rite-group.com
>Date: 11/25/04 7:37 AM Hawaiian Standard Time
>Message-id: <Pine.SOL.4.58.0411250934221.24690@zaphod>
>
>On Thu, 25 Nov 2004, qazmlp wrote:
>
>> RSS(resident set size) of the process keeps increasing. Can we
>> consider that as an indication for memory leaks in the process?
>
>The RSS of a process with a memory leak will indeed grow.
>But so will that of a process that DOESN'T, under the right
>circumstances.
>
>Memory that is free()ed is not returned to the kernel, so if
>you allocate and free increasing amounts of memory, your RSS
>will increase. Or you might just be caching data in memory
>and don't free it deliberately by design. (To me, a memory
>leak is an unintentional thing.)
So to what extent is free'd memory used by subsequent allocation calls?
For example if I free 1M of memory, but then at a later time, I need it again,
and allocate for 1M, will the process not consume that 1M that was free'd or
will it grab more?
Or does this depend on a few factors?
Stuart
Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up requires a creationist"
"Creationists aren't impervious to Logic: They're oblivious to it."
Rich Teer
> So to what extent is free'd memory used by subsequent allocation calls?
As much as possible.
> For example if I free 1M of memory, but then at a later time, I need it again,
> and allocate for 1M, will the process not consume that 1M that was free'd or
> will it grab more?
Assuming nothing else has happened memory wise between the free and the
second malloc, the memory will likely be reused. But when you free that
1MB of memory, the size of your process does NOT decrease by 1MB.
> Or does this depend on a few factors?
To a degree, yes. If you allocate other memory between the free and
the re-malloc of 1MB, it's possible that the malloc routines have
used up some of the space, so it would have to grab some more from
the kernel.