Theron Luhn <theron@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/e09522d524354d96d297b153d1479c13#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
