Opened 7 years ago

Closed 6 years ago

#2839 closed enhancement (wontfix)

add dtrace probe hooks into BIND 10 (in the performance critical path)

Reported by: cas Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: Unclassified Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: needinfo Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


dtrace is a dynamic tracing tool pioneered at SUN and now available on Solaris, MacOS X and FreeBSD. There are also ports to Linux.


dtrace is a very good tool to find bottlenecks and the cause of performance issues in production deployments. dtrace probes in BIND 10 would minimize the (performance) impact of doing a dtrace session on BIND 10.


Change History (8)

comment:1 Changed 7 years ago by vorner

I'm not against dtrace (and I didn't study about what the probes are). But I'd like to point to the oprofile project, which uses the hardware support in CPU. In case of AMD CPU, you can get very accurate results of what part of code is the bottleneck (accurate to separate machine instructions) and the reason to it (you can ask to measure run time of the instructions, number of cache misses, number of waits for locks, etc). And all that without performance impact.

Unfortunately, that is a linux-only tool.

comment:2 Changed 7 years ago by cas

I found
"An Overview of Software Performance Analysis Tools and Techniques: From GProf to DTrace"

and from the author of oprofile: (

I wrote OProfile, and I currently use DTrace daily, and I can assure you that you are wrong when you claim they do the same thing."

OProfile is useful for measuring system-wide resource consumers (for example, you can see what pieces of code are causing cache misses in the kernel when your apache process is in the kernel etc, or which user processes take up the most CPU time).

DTrace can also do something similar (though it needs a little more work yet). But DTrace does a LOT more than this. Imagine a system-wide (kernel, binaries, libraries) 'strace', where you can trivially choose what to print out, and what parts to strace, and under what circumstances. DTrace does even more than that.

OProfile can't tell you exactly why your system call is returning EINVAL. OProfile can't tell you why your application is causing cross-calls. OProfile can't tell you what processes are writing to what files, in real time. OProfile can't debug race conditions.

OProfile is a profiler: it does its job and nothing more. DTrace is, essentially, an instrumentation suite; one of its abilities is to function as a simple profiler.

You won't really get a notion of why DTrace is so useful until you try it

Both tools have their use cases, but they are different.

About Dtrace probes:
Adding DTrace probes to your applications

Putting developer-defined DTrace probe points in an application

Oracle DTrace Wiki

Userland DTrace support on FreeBSD

comment:3 Changed 7 years ago by cas

One important aspect of Dtrace is that it works in un-modified production environments: no special compile, no special kernel, no kernel headers needed, no compiler on the production machine.

This property is very important when troubleshooting issues on specific customer deployments.

comment:4 Changed 7 years ago by vorner

The argument that each one is different seems like a very good one (you talked about profiling and performance first, which probably confused me).

However, oprofile doesn't need much changes to environment too. It only needs driver module for the performance counters in CPU (which can be installed and loaded at runtime) and few utility programs. No need to recompile the kernel or the measured programs.

comment:5 Changed 7 years ago by jinmei

And what's the specific task?

comment:6 Changed 7 years ago by shane

  • Milestone New Tasks deleted

comment:7 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:8 Changed 6 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check

Closing ticket.

Note: See TracTickets for help on using tickets.