Theron Luhn <theron@xxxxxxxx> writes: >> 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. Doesn't sound like a lot ... >> 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? Hmm. I find it mighty suspicious that the USS, PSS, and RSS numbers are all increasing to pretty much the same tune, ie from very little to circa 100MB. I think there is a decent chance that smem is not doing what it says on the tin, and in fact is including shared memory consumption in "USS". In which case the apparent leak just corresponds to the process gradually touching more and more of the shared buffer arena. (If your shared_buffers settings is not somewhere near 100MB, then this theory breaks down.) It would be worth using plain old top to watch this process. We have enough experience with that to be pretty sure how to interpret its numbers: "RES minus SHR" is the value to be worried about. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
