Re: [HACKERS] memory fields from getrusage()
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] memory fields from getrusage() |
Дата | |
Msg-id | CA+TgmobD65pYq0mAt+kpqTzvnkuLV88G6Ae3pM_MJfd8PCa5Kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] memory fields from getrusage() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] memory fields from getrusage()
|
Список | pgsql-hackers |
On Sat, Jun 10, 2017 at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. It might be worth adding platform-specific code for common platforms. I checked macOS X 10.10.5 (Yosemite) and a Linux system (hydra, old Fedora release) and they seem to list identical fields for struct rusage, which is good as far as it goes, but Linux documents a bunch of the interesting fields (ru_ixrss, ru_idrss, ru_isrss, ru_nswap, ru_msgsnd, ru_msgrcv, ru_nsignals) as unused, and apparently returns ru_maxrss in kilobytes where macOS reports it in bytes. It seems like it would be a good idea to install code specific to Linux that displays all and only those values that are meaningful on Linux, and (less importantly) similarly for macOS. Linux is such a common platform that reporting bogus zero values and omitting other fields that are actually meaningful does not seem like a very good plan. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: