One of the most useful toolkit which gives Sun Solaris a bit of an edge in system administration is DTrace. DTrace toolkit is a collection of scripts which help a Solaris system administrator to do an extensive check of the system , track down performance problems across many layers of software and tune the performance of the running processes. Dtrace has been built using the D programming language which has a lot of semblance with awk.
Work had been going on in porting this toolkit to FreeBSD. And now John Birrell and his team who have been working on this project claim to have reached a major milestone in porting this rather powerful toolkit to FreeBSD. The basic DTrace infrastructure is in place and of the 1039 DTrace tests that Sun runs on Solaris, 793 now pass on FreeBSD.
Linux system administrators do not have the luxury of such a powerful integrated toolkit and have to do with a small number of individual programs to achieve some of those tasks. Too bad, DTrace has been released under CDDL licence. Else someone would have started a project to port DTrace to Linux too by now.
3 comments:
"DTrace toolkit is a collection of scripts..."
Scripts? The scripts and commands are just the user-visible portion of DTrace that's used to control the tracing. Maybe they are the only part ported to BSD, but the real meat of Solaris DTrace is built into the Solaris kernel.
--Jim
@Jim
You may be right about the meat of Solaris DTrace being built into the Solaris kernel. But then FreeBSD and Solaris share a common link as they are both derived from BSD. Also from the freeBSD site, I quote
"We've got the following providers:
- dtrace
- profile
- syscall
- sdt
- fbt
As of today, loading those providers on a GENERIC kernel gives 32,519 probes."
So really, it is not necessary to port all the tools to freebsd. FreeBSD already has those. Only the scripts have to be ported.
The DTrace 'framework' is spread from the build system (CTF tools) to the user-land libdtrace and dtrace(1) and then into the kernel with the dtrace device and other providers, plus the hooks in the kernel code where required.
So the 'meat' is actually on both sides of the user-kernel boundary.
The D scripts are just a convenient way of using the dtrace(1) client, so you can regard the scripts as a toolkit and dtrace(1) as a shell and compiler all in one.
On FreeBSD, the 'make buildworld' that we all use to build the entire operating system has been updated to run the CTF tools where required. That is, for every object, library, program, kernel module and the kernel itself.
dtrace(1) and libdtrace are mostly complete, except for the process library functionality.
In the kernel, the providers listed above are mostly complete. There are still a few things that need to be ported.
As an example of something that can be done on the FreeBSD DTrace port right now: fbt:kernel:intr_execute_handlers:entry will let you inspect the registers in the trap frame on every interrupt.
In fact I can even run the 'make buildworld' with the source code NFS mounted and all entry FBT probes enabled (fbt:::entry). OK, the build slows down a bit, but the system works perfectly.
Post a Comment