Re: Understanding Postgres Memory Usage

> 9.3.which? We do fix memory leaks from time to time ...

9.3.14

> If it's not an outright leak, it's probably consumption of cache space.
> We cache stuff that we've read from system catalogs, so sessions that
> touch lots of tables (like thousands) can grow due to that. Another
> possible source of large cache consumption is calling lots-and-lots of
> plpgsql functions.

I have a reasonable number of tables (around 50) and very few plpgsql
functions.

> If the same query, repeated over and over, causes memory to continue
> to grow, I'd call it a leak (ie bug). If repeat executions consume
> no additional memory then it's probably intentional caching behavior.

Here's the results of that:
https://gist.github.com/luhn/e09522d524354d96d297b153d1479c13

So kind of a combination of the two: Memory usage increases up to a
certain point but then plateaus. So... cache? It's ~100MB increase,
though, which seems an excessive amount. What could be taking up that much
cache?

— Theron

On Thu, Aug 25, 2016 at 9:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Theron Luhn <theron(at)luhn(dot)com> writes:
> > I have an application that uses Postgres 9.3 as the primary datastore.
>
> 9.3.which? We do fix memory leaks from time to time ...
>
> > Some of these queries use quite a bit of memory. I've observed a
> > "high-water mark" behavior in memory usage: running a query increases
> the
> > worker memory by many MBs (beyond shared buffers), but the memory is not
> > released until the connection is closed.
>
> Hm. I'm not familiar with smem, but assuming that that USS column
> really is process-private space, that definitely looks bad.
>
> If it's not an outright leak, it's probably consumption of cache space.
> We cache stuff that we've read from system catalogs, so sessions that
> touch lots of tables (like thousands) can grow due to that. Another
> possible source of large cache consumption is calling lots-and-lots of
> plpgsql functions.
>
> If the same query, repeated over and over, causes memory to continue
> to grow, I'd call it a leak (ie bug). If repeat executions consume
> no additional memory then it's probably intentional caching behavior.
>
> regards, tom lane
>