Re: Performance monitor

From: Karl DeBisschop <karl(at)debisschop(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Justin Clift <aa2(at)bigpond(dot)net(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance monitor
Date: 2001-03-08 03:32:48
Message-ID: 20010307223248.G21416@miles.debisschop.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2001.03.07 22:06 Bruce Momjian wrote:
> > I think Bruce wants per-backend data, and this approach would seem to
> only
> > get the data for the current backend.
> >
> > Also, I really don't like the proposal to write files to /tmp. If we
> want a
> > perf tool, then we need to have something like 'top', which will
> > continuously update. With 40 backends, the idea of writing 40 file to
> /tmp
> > every second seems a little excessive to me.
>
> My idea was to use 'ps' to gather most of the information, and just use
> the internal stats when someone clicked on a backend and wanted more
> information.

My own experience is that parsing ps can be difficult if you want to be
portable and want more than basic information. Quite clearly, I could just
be dense, but if it helps, you can look at the configure.in in the CVS tree
at http://sourceforge.net/projects/netsaintplug (GPL, sorry. But if you
find anything worthwhile, and borrowing concepts results in similar code, I
won't complain).

I wouldn't be at all surprised if you found a better approach - my
configuration above, to my mind at least, is not pretty. I hope you do find
a better approach - I know I'll be peeking at your code to see.

--
Karl

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2001-03-08 03:34:03 RE: WAL & SHM principles
Previous Message Mikheev, Vadim 2001-03-08 03:27:13 RE: Proposed WAL changes