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/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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
