On Thu, 2009-10-15 at 07:11 -0700, Bruce Miller wrote:
> I am sorry that I missed your most recent messages in the thread on
> Bug 295741. I found them last night. I have stopped restarting kdm
> every few hours and will reply to the bug thread with the results.
>
Good to know, look forwards to seeing them.
> I am puzzled by your comment that you "do not believe that this shows
> a memory leak, merely a usual increase of heap size due to excessive
> repeated use". The excess does not arise from the problem between
> keyboard and chair; it is arising from something occurring within the
> installed software which is beyond [this] user's control. How can I
> help trace the source of the excess?
>
I didn't mean to imply user error either.
An artefact of the way that memory management in Linux works is that
applications have to request additional memory when they need it, but
that it is difficult to return that memory when they don't need it
anymore.
Here's a (hopefully layman summary why). Memory exists in a single map
called the heap, which the application splits up into the difference
uses.
[XXXXXXXXXX]
When it needs more, it extends the size of the heap:
[XXXXXXXXXX ]
And begins to allocate from that
[XXXXXXXXXXXXXXXX]
If it now frees a region of memory, it's relatively rare that it's the
most recently allocated thing (at the top of the heap)
[XX XXXXXXXXXX]
So it can't simply shrink the heap. It could try and defrag it, but
that's an insanely expensive and error-prone operation (especially if an
array crosses the divide).
Thus since it's rare that it's the top of the heap being freed, and hard
to defrag the heap, applications never bother. (They do try and re-use
the gaps though)
(When I say applications, I really mean the allocator in the common C
library.)
So long-term usage of a machine will show ever-increasing memory usage.
But that's ok, it's a game.
This isn't *real* memory, it's virtual memory.
Linux (in co-operation with the MMU on your processor) keeps track of
which pages you're *actually* using. This is why there are two numbers
in "ps":
VSZ (Virtual Size) - how big it would be if it actually used all the
memory claimed
RSS (Resident Set Size) - how much memory it's actually using right now
For me, D-Bus might have a VSZ of 24MB, but it's RSS is under 2MB:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
102 928 0.0 0.0 24320 1916 ? Ss Oct14 0:05
dbus-daemon --system --fork
In fact, Linux pretty much ignores the virtual size, it doesn't even
need to be backed by virtual memory (so-called overcommit).
A nice fun game is to add up all the VSZ fields:
warcraft scott% ps aux | awk 'BEGIN { vsz = 0; } /[0-9]/ {vsz += $5;}
END { print vsz; }'
VSZ 12078188
ie. I'm apparently using 12 GB of virtual memory <g>
The massif output you gave looks like D-Bus has had so many requests
that it's had to increase its heap to deal with them. There's no real
evidence of a run-away leak there.
That might be just time-related though, in order to tell you need to let
it run for a while. In the case of a leak, you tend to see one
particular allocation consuming 90% plus of the allocated memory.
That's a leak - because the memory concerned hasn't been marked freed,
so can't be re-used by the application.
Scott
--
Scott James Remnant
[email protected]
--
dbus-daemon memory leak
https://bugs.launchpad.net/bugs/295741
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
