Re: BUG #3881: lo_open leaks memory

Sorry, I forgot to mention:

When we were building the test case, we ran a lot of experiments with 1
GB of shared buffers, and were taking a clear performance hit anytime
the shared buffers seemed to hit the 1GB barrier. Increasing the shared
buffer size to 2GB, improved performance significantly (since the query
now "fits" in shared memory). This seems to contradict the conclusion
that the problem is only a result of the way top is reporting.

Regards,

Michael A.

Tom Lane wrote:
> Okay, I ran this with about 900MB of shared buffers (about as much as I
> thought I could make it without descending into swap hell ...) and there
> is no memory leak that I can see.  What I *do* see is that the process
> size as reported by "top" quickly jumps to 900MB plus and then sits
> there.  This is not a memory leak though, it is just a side effect of
> the way "top" reports usage of shared memory.  Basically, a shared
> buffer starts getting charged against a given process the first time
> that process touches that buffer.  Your test case involves reading a lot
> of blocks of pg_largeobject and that results in touching a lot of
> buffers.
>
> So basically I don't see a problem here.  If you are noticing a
> performance issue in this area, it may indicate that you have
> shared_buffers set too large, ie, using more RAM than the machine
> can really afford to spare.  That leads to swapping which drives
> performance down.
>