Re: Generic Monitoring Framework Proposal

Tom Lane wrote:

>Robert Lor <Robert(dot)Lor(at)Sun(dot)COM> writes:
>
>
>>The main goal for this Generic Monitoring Framework is to provide a
>>common interface for adding instrumentation points or probes to
>>Postgres so its behavior can be easily observed by developers and
>>administrators even in production systems.
>>
>>
>
>What is the overhead of a "probe" when you're not using it? The answer
>had better not include the phrase "kernel call", or this is unlikely to
>pass muster...
>
>
Here's what the DTrace developers have to say in their Usenix paper.
"When not explicitly enabled, DTrace has zero probe effect - the system
operates exactly as if DTrace were not present at all."

http://www.sun.com/bigadmin/content/dtrace/dtrace_usenix.pdf

The technical details are beyond me, so I can't tell you exactly what
happens internally. I can find out if you're interested!

>
>
>>For DTrace, probes can be enabled using a D script. When the probes are not enabled, there is absolutely no performance hit whatsoever.
>>
>>
>
>If you believe that, I have a bridge in Brooklyn you might be interested
>in.
>
>What are the criteria going to be for where to put probe calls? If it
>has to be hard-wired into the source code, I foresee a lot of contention
>about which probes are worth their overhead, because we'll need
>one-size-fits-all answers.
>
>
>
I think we need to be selective in terms of which probes to add since
we don't want to scatter them all over the source files. For DTrace,
the overhead is very minimal, but you're right, other implementation for
the same probe may have more perf overhead.

>>arg1..arg5 = Any args to pass to the probe such as txn id, lock id, etc
>>
>>
>Where is the data type of a probe argument defined?
>
>
It's in a .d file which looks like below:

provider pg_backend {

probe fsync__start(void);
probe fsync__end(void);
probe lwlock__acquire (int, int);
probe lwlock__release(int);
...

}

Regards,
Robert