Re: memory fields from getrusage()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: memory fields from getrusage()
Date: 2017-06-11 01:31:25
Message-ID: 25050.1497144685@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> This comment from ~1996 says:
> https://doxygen.postgresql.org/postgres_8c_source.html
> 4421 * the only stats we don't show here are for memory usage -- i can't
> 4422 * figure out how to interpret the relevant fields in the rusage struct,
> 4423 * and they change names across o/s platforms, anyway. if you can figure
> 4424 * out what the entries mean, you can somehow extract resident set size,
> 4425 * shared text size, and unshared data and stack sizes.

> .. is that really (still) the case for supported platforms? I'm hoping that in
> 2017 one can just call getrusage() if autoconf says it's okay ??

We already do call getrusage(). The point of that comment is that the
contents of the resulting struct rusage are not very well standardized.
POSIX says only

The <sys/resource.h> header defines the rusage structure that includes
at least the following members:

struct timeval ru_utime user time used
struct timeval ru_stime system time used

(seems the same in 1997 and 2008 text). So the existing code has already
got its neck stuck way out in terms of portability. Maybe you could push
it further, but I bet you'll find that the situation isn't any better than
it was at the time that comment was written.

It's entirely possible that we could simplify the code some, because
I suspect that Windows is the only remaining platform that doesn't
HAVE_GETRUSAGE. But that in itself doesn't mean we can use any more
fields than we do now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2017-06-11 02:25:36 Re: Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog
Previous Message Alvaro Herrera 2017-06-11 00:22:24 Re: Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog