Re: Generic Monitoring Framework Proposal

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Generic Monitoring Framework Proposal
Дата
Msg-id 87d5d34zeg.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Generic Monitoring Framework Proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > What would be useful is instrumenting high level calls that can't be traced
> > without application guidance. For example, inserting a dtrace probe for each
> > SQL and each plan node. That way someone could get the same info as EXPLAIN
> > ANALYZE from a production server without having to make application
> > modifications (or suffer the gettimeofday overhead).
> 
> My bogometer just went off again.  How is something like dtrace going to
> magically get realtime information without reading the clock?

Sorry, I meant get the same info as EXPLAIN ANALYZE minus the timing.

I'm not familiar with DTrace first-hand but I did have the impression it was
possible to get timing information though. I don't know how much overhead it
has but I wouldn't be surprised if it was lower for a kernel-based profiling
elapsed time counter on Sun hardware than a general purpose gettimeofday call
on commodity PC hardware.

For example it could use a cpu instruction counter and have hooks in the
scheduler for saving and restoring the counter to avoid the familiar gotchas
with being rescheduled across processors.

-- 
greg



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Generic Monitoring Framework Proposal
Следующее
От: Wade Klaver
Дата:
Сообщение: Initdb segfaults during "initializing pg_authid"