|
Home > Archive > Unix Programming > November 2004 > RSS keeps increasing...Memory leaks??
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 |
RSS keeps increasing...Memory leaks??
|
|
| qazmlp 2004-11-25, 2:50 am |
| RSS(resident set size) of the process keeps increasing. Can we
consider that as an indication for memory leaks in the process?
| |
| Casper H.S. Dik 2004-11-25, 2:50 am |
| qazmlp1209@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
--
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 2004-11-25, 7:50 am |
| Casper H.S. Dik wrote:
> qazmlp1209@rediffmail.com (qazmlp) writes:
>
>
>
>
> 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
| |
| Yong Huang 2004-11-25, 5:53 pm |
| qazmlp1209@rediffmail.com (qazmlp) wrote in message news:<db9bbf31.0411250055.56d7f8c1@posting.google.com>...
> 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
| |
| Rich Teer 2004-11-25, 5:53 pm |
| 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.)
--
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
| |
|
| Rich has a point there.
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.teer@rite-group.com> wrote in message news:<Pine.SOL.4.58.0411250934221.24690@zaphod>...
> On Thu, 25 Nov 2004, qazmlp wrote:
>
>
> 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.)
| |
| Gary Schmidt 2004-11-25, 8:46 pm |
| 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.
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 2004-11-25, 8:46 pm |
| Gary Schmidt wrote:
> Nick Landsberg wrote:
> [SNIP]
>
> 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-)
>
--
"It is impossible to make anything foolproof
because fools are so ingenious"
- A. Bloch
|
|
|
|
|