Slashdot Mirror
Solaris DTrace To Be Ported to FreeBSD
daria42 writes "It looks like Sun's famous Dynamic Tracing tool - one of the best features in Solaris 10 - is getting ported to FreeBSD. Sun open-sourced the code back in January and it has been picked up by FreeBSD developer Devon O'Dell. The tool provides insanely great advanced performance analysis and debugging features for server software. Good to see some result come out of the Sun open-sourcing process." From the article: "O'Dell told ZDNet Australia the aim of the project -- which commenced a month ago -- was that all scripts and applications that utilised DTrace under its native Solaris environment should be able to run in FreeBSD with no changes. While FreeBSD's existing ktrace function was similar to DTrace, it was limited in scope, according to O'Dell. 'FreeBSD implements a somewhat similar facility for dynamically instrumenting syscalls for any given application,' he said."
The article doesn't say whether the program will be released under the BSD license (unlikely) or whether it will remain under the CDDL. The latter seems most likely.
I'm not sure how this benefits Sun, but something as awesome as this, I'm willing to assume it's altruism, and I appreciate it.
Nothing great was ever achieved without enthusiasm
I have seen the use of this tool, and seriously, it rocks. There is no other tracing tool to compare with this. So, I am very eager to hear any news about this being ported to Linux, as not many people use FreeBSD ;-)
"In questions of science the authority of a thousand is not worth the humble reasoning of a single individual."
It looks like a really useful tool. I wonder what the performance penalty is when the tool is turned off.
Do you need to instrument the calls you expect to profile? If so, how can you avoid taking that performance hit when deciding whether to perform the profiling or not, even when the profiler is off? It's still got to check the profiler level each time, doesn't it?
Jesus saved me from my past. He can save you as well.
This has been working on Linux sometime in 2004
The official reason is that it wasn't release was because Linus didn't want the BSD folks using it, but the real reason is the Department of Homeland security didn't want the BSD folk to find the last bug in their release.
Thats what I just head right now. (Thanks, voices)
I've seen it before, fairly often. Perhaps a bit of an exaggeration, but still - commonly used.
Google shows 229,000 hits for "insanely great" (as a phrase).
Welcome to, umm, Geek English!
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
For we that don't have a clue what DTrace is, here's what the has to say: DTrace allows to do performance tuning with applications and troubleshoot production systems--all with little or no performance impact. DTrace provides improved visibility into kernel and application activity, giving the user operational insights with which they can make performance gains..
The no performance penalty sounds really cool to me.
--
Superb hosting 4800MB Storage, 120GB bandwidth, $7,95.
Picaday! Soon to be open "Picture of the day web".
Hosting 20G hd, 1Tb bw! ssh $7.95
"insanely great" is well known. In fact, it's in the Jargon File
Igor Presnyakov stole my hat
A tool like this could really aid in finding all the bottlenecks. Benchmarks have become an embarrassment for FreeBSD as of late, and it is really sad to see that FreeBSD has fallen so far behind. Hopefully this could start to turn things around.
It seems like everywhere I look I've heard comments about how great DTrace is, so to see it ported to FreeBSD really makes me happy. I do have a couple of questions about it though, simply going in line with the announcements over the last couple days.
1) Considering the fact that we are currently going through the Beta's for FreeBSD 6, I am curious how, if at all, a fully implemented DTrace would help the devs with tracking down and solving the current beta problems. From my current understanding, it seems that it could be a great help with tracking down and solving the current show-stoppers. Can someone clarify this for me?
2) I have also read an article somewhere where a DTrace dev showed how easy it was to track down a memory leak in a small program. With Gnome currently going on a memory reduction kick, would a fully featured DTrace be able to help with finding these memory problems? I realize that comparing Gnome with a small application is ridiculous so I can't expect it to magically find these problems in just a few minutes, but could it help? Also, if DTrace helped to find these problems on versions ported to FreeBSD, would they easily be ported back into the main linux-based version of Gnome?
Any feedback would be appreciated because from what (admittedly little) I've read, it seems that DTrace could help on these fronts, but I'm really not 100% sure that it would.
"You look so different now, but looks can be deceiving." -- Snuff
As the guy porting DTrace, I want to clear up a few questions that appear frequently in the comments here. First, though, please be kind to the blog -- it's hosted on our (OffMyServer's) network, which is on a T1. I dunno how bad it got when the story was posted, but just for reference, it'd be nice to not have our network connection die.
:)
FAQ #1 seems to be about the license. Obviously, the CDDL is `viral' in the sense that changes in the code need to be provided under the same terms of the CDDL. In my understanding, this applies only to files in which modifications take place. Extension of something CDDL by adding extra files seems to not require those files to be released under the CDDL. That said, this is a porting effort, and most of the changes I will make will be inside CDDL-licensed files. Thus, anything imported will be under the CDDL. This does not require anything external files to be under the CDDL and thus it can be shipped with FreeBSD without `infecting' other files.
FAQ #2 seems to be whether Sun is happy about this or not. If you have read the article, you would have seen that I've been encouraged to work on this by Sun kernel engineers. Whether Sun as a whole is happy about this is not known to me, but everybody involved in getting it this far has been, so I'm not terribly worried about the rest.
FAQ #3 is about performance incurrences. Certain aspects of DTrace incur performance penalties, but only when DTrace is running. DTrace by itself is a library and a userland tool. All instrumentation is done dynamically and when DTrace is not instrumenting something, no performance hits happen whatsoever. When it is running, we have several advantages to other tools because (unlike e.g. truss) we are instrumenting single processes. Processes which are not being instrumented will not take any performance hits other than the fact that they have a bit less CPU usage since DTrace is instrumenting something.
How do you not take a performance penalty when the profiler is off? You must be root to run DTrace. When you instrument functions inside an application, this is done on-the-fly by rewriting the code that is being executed. When it is not being executed, nothing is being rewritten and it's not even looking to rewrite something. It's just some code resident in memory (in fact, modules are even loaded as needed). It sounds like it might be prone to security flaws, but keep in mind that this has been working in production for a while now.
When will this be in Linux? I don't know. I won't be working on it. I challenge _you_ to do this
Is this vaporware? No. I'm continuing development from about a week off (since I lost my development machine) this evening.
Feel free to ask more questions, I'll try to address them as I see them. But please refrain from bad-mouthing Sun or myself out of spite, jealousy, or whatever. I know it's fun to troll (if you're a troll), but the rest of us really don't appreciate it.
--Devon
www.sitetronics.com/wordpress