Okay, here's the output: https://gist.github.com/luhn/a39db625ba5eed90946dd4a196d12220
— Theron On Thu, Aug 25, 2016 at 12:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Theron Luhn <the...@luhn.com> writes: > >> 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. > > > Sure thing. https://gist.github.com/luhn/e09522d524354d96d297b153d1479c > 13#file-top-txt > > > RES - SHR is showing a similar increase to what smem is reporting. > > Hm, yeah, and the VIRT column agrees --- so 100MB of non-shared > memory went somewhere. Seems like a lot. > > If you have debug symbols installed for this build, you could try > doing > > gdb /path/to/postgres processID > gdb> call MemoryContextStats(TopMemoryContext) > gdb> quit > > (when the process has reached an idle but bloated state) and seeing what > gets printed to the process's stderr. (You need to have launched the > postmaster with its stderr directed to a file, not to /dev/null.) > That would provide a better clue about what's eating space. > > regards, tom lane >
