On Mon, 2006-06-19 at 19:36 -0400, Theo Schlossnagle wrote:
The idea of having intelligently placed dtrace probes in Postrgres
would allow us
...
to troubleshoot[ing] obtuse production
problems. That, to me, is exciting stuff.
[paraphrased by SR]
I very much agree with the requirement
On Mon, Jun 19, 2006 at 05:14:15PM -0400, Chris Browne wrote:
[EMAIL PROTECTED] (Robert Lor) writes:
For DTrace, probes can be enabled using a D script. When the probes
are not enabled, there is absolutely no performance hit whatsoever.
That seems inconceivable.
In order to have a way
Robert Lor [EMAIL PROTECTED] 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
Greg Stark [EMAIL PROTECTED] writes:
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
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
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
Simon Riggs wrote:
This needs to work on Linux and Windows, minimum, also.
The proposed solution will work on Linux Windows if they similar
facility that the macros can map to. Otherwise, the macros stay as
no-ops and will not affect those platforms at all.
It's obviously impossible to
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
Motivation:
--
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. This framework will allow
Robert Lor [EMAIL PROTECTED] 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
On Jun 19, 2006, at 4:40 PM, Tom Lane wrote:
Robert Lor [EMAIL PROTECTED] 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
Tom Lane wrote:
Robert Lor [EMAIL PROTECTED] 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
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
[EMAIL PROTECTED] (Robert Lor) writes:
For DTrace, probes can be enabled using a D script. When the probes
are not enabled, there is absolutely no performance hit whatsoever.
That seems inconceivable.
In order to have a way of deciding whether or not the probes are
enabled, there has *got* to
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
On Jun 19, 2006, at 6:41 PM, Robert Lor wrote:
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
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
On Jun 19, 2006, at 7:39 PM, Mark Kirkwood wrote:
We will need to benchmark on FreeBSD to see if those comments about
overhead stand up to scrutiny there too.
I've followed the development of DTrace on FreeBSD and the design
approach is mostly identical to the Solaris one. This would mean
17 matches
Mail list logo
