Re: Generic Monitoring Framework Proposal
От | Greg Stark |
---|---|
Тема | Re: Generic Monitoring Framework Proposal |
Дата | |
Msg-id | 87irmv52py.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | Re: Generic Monitoring Framework Proposal (Robert Lor <Robert.Lor@Sun.COM>) |
Ответы |
Re: Generic Monitoring Framework Proposal
Re: Generic Monitoring Framework Proposal |
Список | pgsql-hackers |
Robert Lor <Robert.Lor@Sun.COM> writes: > Yes, I'm proposing user-space probes (aka User Statically-Defined Tracing - > USDT). USDT provides a high-level abstraction so the application can expose > well defined probes without the user having to know the detailed > implementation. For example, instead of having to know the function > LWLockAcquire(), a well documented probe called lwlock_acquire with the > appropriate args is much more usable. It seems pointless to me to expose things like lwlock_acuire that map 1-1 to C function calls like LWLockAcquire. They're useless except to people who understand what's going on and if people know the low level implementation details of Postgres they can already trace those calls with dtrace without any help. 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). It's one thing to know "I seem to be acquiring a lot of locks" or "i'm spending all my time in sorting". It's another to be able to ask dtrace "what query am I running when doing all this sorting?" or "what kind of plan node am I running when I'm acquiring all these locks?" -- greg
В списке pgsql-hackers по дате отправления: