Re: Generic Monitoring Framework Proposal - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: Generic Monitoring Framework Proposal
Date
Msg-id 449735B7.5040504@paradise.net.nz
Whole thread Raw
In response to Re: Generic Monitoring Framework Proposal  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Generic Monitoring Framework Proposal  (Theo Schlossnagle <jesus@omniti.com>)
List pgsql-hackers
Jim C. Nasby wrote:
> On Mon, Jun 19, 2006 at 05:20:31PM -0400, Theo Schlossnagle wrote:
>> Heh.  Syscall probes and FBT probes in Dtrace have zero overhead.   
>> User-space probes do have overhead, but it is only a few instructions  
>> (two I think).  Besically, the probe points are replaced by illegal  
>> instructions and the kernel infrastructure for Dtrace will fasttrap  
>> the ops and then act.  So, it is tiny tiny overhead.  Little enough  
>> that it isn't unreasonable to instrument things like s_lock which are  
>> tiny.
> 
> If someone wanted to, they should be able to do benchmarking with the
> DTrace patches on pgFoundry to see the overhead of just having the
> probes in, and then having the probes in and actually using them. If you
> *really* want to see the difference, add a probe in s_lock. :)

We will need to benchmark on FreeBSD to see if those comments about 
overhead stand up to scrutiny there too.

I would think that even if (for instance) we find that there is no 
overhead on Solaris, those of us on platforms where DTrace is less 
mature would want the option of building without any probes at all in 
the code - I guess a configure option "--without-dtrace" on by default 
on those platforms would do it.

regards

Mark



pgsql-hackers by date:

Previous
From: Theo Schlossnagle
Date:
Subject: Re: Generic Monitoring Framework Proposal
Next
From: Theo Schlossnagle
Date:
Subject: Re: Generic Monitoring Framework Proposal