Slashdot Mirror
Oracle To Bring Dtrace To Linux
mvar writes "Dtrace co-author Adam Leventhal writes on his blog about Dtrace for Linux: 'Yesterday (October 4, 2011) Oracle made the surprising announcement that they would be porting some key Solaris features, DTrace and Zones, to Oracle Enterprise Linux. As one of the original authors, the news about DTrace was particularly interesting to me, so I started digging. Even among Oracle employees, there's uncertainty about what was announced. Ed Screven gave us just a couple of bullet points in his keynote; Sergio Leunissen, the product manager for OEL, didn't have further details in his OpenWorld talk beyond it being a beta of limited functionality; and the entire Solaris team seemed completely taken by surprise. Leunissen stated that only the kernel components of DTrace are part of the port. It's unclear whether that means just fbt or includes sdt and the related providers. It sounds certain, though, that it won't pass the DTrace test suite which is the deciding criterion between a DTrace port and some sort of work in progress.'"
If you want Dtrace and ZFS, just go with FreeBSD. You get pf and jails thrown in for the effort.
OEL for SPARC has already been announced.
This is a great technology story - even if only for one version of Linux so far. DTrace will bring tremendous value for troubleshooting and performance analysis, and is a technology I use (almost) every day.
For example, yesterday I had a CPU bound workload with an unexpected level of variation, and used DTrace to measure the effect of CPU thread affinity and interrupt activity on that workload. I used DTrace to pull the runtime along with other details: number of scheduling events for that thread, along with the CPUs that the thread ran on; also, for preemption, the pre-emptor thread (to see why) along with both its user-level and kernel stack traces; also the interrupt thread and device. I fairly quickly showed that the runtime variation was caused by network interface interrupts from an entirely different application. This analysis would take quite a lot longer without DTrace, and may be prohibitively difficult to complete.
Many of my uses of DTrace are much more straightforward than that; including identifying file system latency for applications, application response time, and CPU dispatcher queue latency. I've listed many more examples in the DTrace book (http://www.dtracebook.com). It should be a great resource of ideas for those looking to use DTrace on Linux - since the hardest part for people has been knowing where to start, given the ability to see everything.
And why do you want to keep the raid and LVM stack?
If you're creating a filesystem and you can make it aware of its own backing storage (and adjust stuff like block size - cause you know, there are disks with 4K sectors now), and have it manage caching by itself (and thus, be aware of how much memory the has, and how much of it is actually RAM and not virtual), and have it check for redundancy and do online checks and repairs - which you realize it's just awesome if you ever try to do fsck on a 20TB filesystem (and because it knows how much data it's actually used, have it only check what's used, instead of blindly regenerating blank space for an array of disks). And variable strip size, and thin provisioning, CoW and free snapshots and clones, and a lot of other stuff ZFS does because it doesn't need to "respect its elders" LVM and md.
You obviously haven't had to use both in anger. SystemTap is another "me too" project like so many things on Linux, where the only people saying it's as good are the people who haven't used the product it's an imitation of. Oh, and then there's the RMS type who will say it's "better because freedom has value" or something to that effect. Doesn't help you when you're actually trying to tune an application for performance.
Yeah, Solaris has some pretty awesome features, but at the end of the day all that may be irrelevant in the face of Market Pressures. Sun for many years shot themselves in the foot by failing to deliver useful tools for things like patching/updating, mass installation of Solaris servers (yes, there is jumpstart/wanboot, but it is clearly deficient), and failing to deliver a decent native volume manager (ZFS) until Too Late, and then not having it support root filesystems until Way Too Late.
The reality of Solaris is that there are all these features that look awesome in theory, until you actually have to implement them and discover the practical implications. Take Zones. Zone sounds great, in theory. But, ever tried to patch a server with zones? It's a nightmare. And heaven help you if you actually have a server with zones from multiple, different apps and you need to get outage windows from all the different app groups in order to patch. Or LDoms. Again, they sound awesome. That is, until you realize that there are no tools to manage migrations when a server goes down hard (the most common case for which you would want to do a migration!) So, you end up having to write a bunch of scripts to duplicate LDom xml files etc. to do this, because Sun/Oracle didn't really think through how their technology would be used in a real environment. I also use AIX virtualization technology, and it's much better, and VMWare (which is what we use for Linux servers) blows them both out of the water.
Things like this are why a lot of major companies, including the one I work at, are leaving Solaris as fast as they can. The reality is that it takes twice as many SA's per server on Solaris as it does for any other platform, we have lower virtualization densities, and it therefore costs a lot more money to run. For the kind of money we're talking about, we can deal with a few echoes in the interface for SAN's.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1