|
Home > Archive > Unix Programming > February 2004 > free() and memory usage
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 |
free() and memory usage
|
|
| concern 2004-02-28, 2:33 pm |
| Hi all,
On a linux box, there are several instances of my application running for
different purposes, testing/QA... I also running my own test instance
"myapp" on it. During working hours, the "size" in top of myapp is easily
grow and seems no uplimit; after working hour, with same input, the size
will remain around a certain amount, means:
on working hours(myapp was a little slower):
the test client sent 100 requests to myapp, the "size" would grew to 26mb.
after:
the test client sent exactly 100 same content(ensure same processing
routains) request to myapp, size aroud 16mb.
No memleak when checked with valgrind and mtrace() in above 16mb case (the
26mb case needs the working day though).
Here goes my questions:
1) the size of top constantly grows means a leak?
2) if free() of glibc doesn't (always?) return the memory to OS, is this
behave can be affected by process' current running env or time(how long the
process holds the resource) related?
3) what are other possible reasons for above different "size" with same
inputs/outputs to a process?
Thanks in advance
-sean
| |
| Sean Burke 2004-02-28, 5:34 pm |
|
"concern" <conern@somewhere.net> writes:
> Hi all,
>
> On a linux box, there are several instances of my application running for
> different purposes, testing/QA... I also running my own test instance
> "myapp" on it. During working hours, the "size" in top of myapp is easily
> grow and seems no uplimit; after working hour, with same input, the size
> will remain around a certain amount, means:
> on working hours(myapp was a little slower):
> the test client sent 100 requests to myapp, the "size" would grew to 26mb.
> after:
> the test client sent exactly 100 same content(ensure same processing
> routains) request to myapp, size aroud 16mb.
>
> No memleak when checked with valgrind and mtrace() in above 16mb case (the
> 26mb case needs the working day though).
>
> Here goes my questions:
> 1) the size of top constantly grows means a leak?
> 2) if free() of glibc doesn't (always?) return the memory to OS, is this
> behave can be affected by process' current running env or time(how long the
> process holds the resource) related?
> 3) what are other possible reasons for above different "size" with same
> inputs/outputs to a process?
Lots of applications have a memory use patterns where
they grow over time, but eventually plateau at some
constant long-term level.
First, note that free() does not return memory to the
OS, only marks that block as free in your process's
heap. Over the long term, free areas in your heap
become intermingled with areas that are in use,
which limits the ability of malloc() to merge small
free blocks into larger blocks. Over time, the heap
becomes more "fragmented", and therefore larger,
until an equilibrium is reached.
Applications that have leaks never reach equilibrium,
but continue to grow indefinitely. Note however that
not every program that grows indefinitely has leaks.
For example, if you allocate memory and store pointers
to those blocks in a list or table, and fail to free
them after they are no longer needed, tools like Purify
(and, I assume, valgrind) won't report them as leaks,
since to all appearances they are still in use.
In rarer cases, a set of memory blocks that contain
circular chains of reference to one another will also
escape detection, since each block will appear to be
used by the other.
-SEan
| |
| those who know me have no need of my name 2004-02-28, 7:34 pm |
| in comp.unix.programmer i read:
>1) the size of top constantly grows means a leak?
not necessarily.
>2) if free() of glibc doesn't (always?) return the memory to OS, is this
>behave can be affected by process' current running env or time(how long the
>process holds the resource) related?
gnu libc only returns memory to the o/s when there is a sufficiently large
block. see the documentation for more information.
>3) what are other possible reasons for above different "size" with same
>inputs/outputs to a process?
something is different it would seem. find those differences.
--
a signature
|
|
|
|
|