From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Denis Perchine <dyp(at)perchine(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Performance monitor |
Date: | 2001-03-13 15:56:58 |
Message-ID: | 200103131556.KAA14202@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Denis Perchine <dyp(at)perchine(dot)com> writes:
> >>> Small question... Will it work in console? Or it will be X only?
> >>
> >> It will be tck/tk, so I guess X only.
>
> > That's bad.
>
> tcl/tk is cross-platform; there's no reason that a tcl-coded
> performance monitor client couldn't run on Windows or Mac.
>
> The real problem with the ps-based implementation that Bruce is
> proposing is that it cannot work remotely at all, because there's
> no way to get the ps data from another machine (unless you're
> oldfashioned/foolish enough to be running a finger server that
> allows remote ps). This I think is the key reason why we'll
> ultimately want to forget about ps and go to a shared-memory-based
> arrangement for performance info. That could support a client/server
> architecture where the server is a backend process (or perhaps a
> not-quite-backend process, but anyway attached to shared memory)
> and the client is communicating with it over TCP.
Hard to say. 'ps' gives some great information about cpu/memory usage
that may be hard/costly to put in shared memory. One idea should be to
issue periodic 'ps/kill' commands though a telnet/ssh pipe to the
remote machine, or just to the remote X display option.
Of course, getrusage() gives us much of that information.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-03-13 16:01:07 | Re: Performance monitor |
Previous Message | Tom Lane | 2001-03-13 15:52:27 | Re: problem with fe/be protocol and large objects |