> 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 <t...@sss.pgh.pa.us> wrote: > Theron Luhn <the...@luhn.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 >
