Re: Generic Monitoring Framework Proposal

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Theo Schlossnagle <jesus(at)omniti(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Lor <Robert(dot)Lor(at)Sun(dot)COM>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Generic Monitoring Framework Proposal
Date: 2006-06-19 23:39:35
Message-ID: 449735B7.5040504@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Theo Schlossnagle 2006-06-19 23:48:55 Re: Generic Monitoring Framework Proposal
Previous Message Theo Schlossnagle 2006-06-19 23:36:27 Re: Generic Monitoring Framework Proposal