Manfred Koizar <[EMAIL PROTECTED]> writes:
> On Wed, 10 Sep 2003 00:18:52 -0400, Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> I have a suspicion that there is no real leak, but
>> rather we are seeing some artifact of the way Linux' top(1) reports
>> memory usage.
> From my experience I can confirm that. I have looked a lot at top
> output when I benchmarked my heaptuple header changes last year. ISTM
> Linux accounts a shared memory page (for whatever a page is) to the
> memory usage of a process as soon as the process has touched that
> page.
But not otherwise, huh? Okay, that would explain things.
> 7.4 starts up with 1000 shared buffers by default, that is 8 MB of
> shared memory. Add some space for FSM, connections and other shared
> stuff, and 10 MB of shared memory is quite plausible.
In fact, according to ipcs, the default shared memory segment size for
CVS tip on Linux (RHL 8.0) is 10436608 bytes. I see that a freshly
started backend is shown as having SHARE 1896, but a large seqscan query
(which would cause it to touch all the shared buffers in fairly short
order) makes the report jump to 6500. This doesn't seem to quite square
with your explanation though --- surely the number should go to 8000 and
change? The man page for top says these numbers are in kilobytes ...
but if they were really measured in, say, 4K pages, then we'd be talking
about 26M of shared memory touched, which might be plausible when you
consider shared libraries. 2K pages would make the numbers even more
plausible, but that seems like an unlikely page size.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
