Re: Generic Monitoring Framework Proposal
От | Robert Lor |
---|---|
Тема | Re: Generic Monitoring Framework Proposal |
Дата | |
Msg-id | 4498340B.30700@sun.com обсуждение исходный текст |
Ответ на | Re: Generic Monitoring Framework Proposal (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
Greg Stark wrote: >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. > > > lwlock_acquire is just an example. I think once we decided to down this path, we can solicit ideas for interesting probes and put them up for discussion on this alias whether or not they are needed. I think we need to have two categories of probes for admins and developers. Perhaps the probes for admins are more important since, as you said, the developers already know which function does what, but I think the low-level probes are still useful for new developers as there behavior will be documented. >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?" > > > Completely agree. Regards, Robert
В списке pgsql-hackers по дате отправления: