+1 for having an API better than GDB to make a process emit a memory usage dump. This is my top non-crash cause for use of GDB in production.
On Mon, Jun 23, 2014 at 07:21:22PM +0200, Andres Freund wrote: > On 2014-06-23 10:07:36 -0700, Tom Lane wrote: > > Andres Freund <and...@2ndquadrant.com> writes: > > > I wonder if it'd make sense to allow a signal to trigger a memory > > > context dump? I and others more than once had the need to examine memory > > > usage on production systems and using gdb isn't always realistic. > > > I wonder if we could install a signal handler for some unused signal > > > (e.g. SIGPWR) to dump memory. SIGPWR is not widely available. Apart from SIGUSR1 and SIGUSR2, using a portable signal risks colliding with the standard use thereof. > > > I'd also considered adding a SQL function that uses the SIGUSR1 signal > > > multiplexing for the purpose but that's not necessarily nice if you have > > > to investigate while SQL access isn't yet possible. There's also the > > > problem that not all possibly interesting processes use the sigusr1 > > > signal multiplexing. I don't know whether to be interested in cases where SQL access is unavailable. If those cases are important, an idea for achieving it without leaning on unportable or already-used signals is to define SIGUSR2 as a second multiplexer that uses files instead of shared memory. You'd send the signal with something like this: : >$PGDATA/procsig/$targetpid.memdump kill -USR2 $targetpid (This would probably require first converting the existing autovacuum use of SIGUSR2 to the shared memory procsig mechanism.) > > The closest approximation that I think would be reasonable is to > > set a flag that would be noticed by the next CHECK_FOR_INTERRUPTS > > macro. So you're already buying into the assumption that the process > > executes CHECK_FOR_INTERRUPTS fairly often. Which probably means > > that assuming it's using the standard sigusr1 handler isn't a big > > extra limitation. If it's acceptable to require SQL access and exclude would-be target processes that detach from shared memory, I favor an approach using the shared memory SIGUSR1 multiplexer. Bringing all the processes that do use shared memory into agreement about the use of SIGUSR1 feels like a valuable step forward. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
