Re: Performance monitor

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Performance monitor
Дата
Msg-id 200103131556.KAA14202@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Performance monitor  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Performance monitor  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
> Denis Perchine <dyp@perchine.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Performance monitor
Следующее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: RE: xlog loose ends, continued