I thought he was talking about the 70x result, not the 1 billion result. Quoting from the 70x benchmark:
For this test, 3 machines were used:
Intel Core 2 Quad Core @2.83 GHz; 8 Gbytes RAM; single, multi-threaded data node (ndbmtd)
Intel Core 2 Quad Core @2.83 GHz; 8 Gbytes RAM; single, multi-threaded data node (ndbmtd)
4 Core Fedora VM running on VirtualBox on Windows 7, single MySQL Server
It looks like the AQL feature has pushed work from that MySQL-on-VirtualBox-on-Windows-7 system to the pair of data nodes with 8 GB RAM, and found it runs 70x faster. It doesn't say how much RAM the MySQL server had, what the data nodes were running, or why it was running in that virtualized environment in the first place. I can't say I'm surprised that offloading work from such a place has has provided a big win. It may be more interesting to see the result from a more typical setup, such as MySQL running on a baremetal OS.
This depends on the lunar regolith deposition rate, which I've seen quoted as 1 cm per 2-3 million years. Imagine Tranquility Base - which has over 100 man made artifacts on the surface (http://spacegrant.nmsu.edu/lunarlegacies/artifactlist.html) - in one million years from now, with half a centimeter of dust. This makes the lunar surface a time capsule of past activity (provided the site doesn't get wiped out by an asteroid impact), in a way that the Earth isn't. We've yet to photograph the surface at high enough resolution to really know what's there.
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.
Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3;-). But this issue is about more than just that.
I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.
This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.
Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.
Probably the most clear and undenyable feature that is unique to OpenSolaris/Solaris is DTrace.
DTrace lets us examine just about anything, with minimal impact on the system. It's way cool, and other OSes have nothing that is close (for details covering the Linux Trace Toolkit (LTT), DProbes, K42 and Kerninst see the USENIX paper.
DTrace solves disk I/O by PID, network activity by PID, elapsed and on-cpu times for syscalls, libcalls and user funcs, and much more.
DTrace is great if you are a programmer with a little kernel knowledge, but if not you may find the DTraceToolkit helpful - it is a collection of ready-to-roll scripts.
For a list of many OpenSolaris features with screenshots, see the OpenSolaris Guide.
fine. use QWERTY, get sore hands, and maybe it will hurt too much to post such nonscense.
Lets see, would I use a keyboard that is designed for ergonomics and speed? or one that is designed to stop metal arms from jamming in a 19th century typewriter?
Brendan
(been using DVORAK for around 8 years, and can still easily type on QWERTY - though I prefer not to)
DTrace is the first of it's kind, I've introduced it to dozens of people and it is quite a challenge to understand what it is.
Maybe the closest tool is truss (Solaris) or strace (Linux), which are invaluable troubleshooting tools.
DTrace goes much, much further. It can examine system calls, library functions, user functions; for each call it can fetch nanosecond timestamps, retrieve values from kernel memory, user memory, print stack backtraces, gather statistics... It has minimal system impact, and can trace inside the code of software that has never heard of DTrace before.
It is good news to sysadmins who want to understand performance problems with their systems (or any other behaviour).
It is bad news for developers who are rotton programmers and for software companies who peddle poorly written software (and may have done so for years). DTrace can expose problems in their source code, source code they previous would have hit compile and then assumed was hidden.
... so DTrace may well be very good news for the IT industry in general.
It automates capturing application data, eg HTTP or FTP, and can replay data: eg telnet, X11 or VNC. plus lots more. It's useful to highlight the need for encryption, or as a general networking tool.
Chaosreader is still beta (0.94) by the time it's more robust and optimised it will be released as 1.00. http://chaosreader.sourceforge.net
Slashdot Mirror
It looks like the AQL feature has pushed work from that MySQL-on-VirtualBox-on-Windows-7 system to the pair of data nodes with 8 GB RAM, and found it runs 70x faster. It doesn't say how much RAM the MySQL server had, what the data nodes were running, or why it was running in that virtualized environment in the first place. I can't say I'm surprised that offloading work from such a place has has provided a big win. It may be more interesting to see the result from a more typical setup, such as MySQL running on a baremetal OS.
This depends on the lunar regolith deposition rate, which I've seen quoted as 1 cm per 2-3 million years. Imagine Tranquility Base - which has over 100 man made artifacts on the surface (http://spacegrant.nmsu.edu/lunarlegacies/artifactlist.html) - in one million years from now, with half a centimeter of dust. This makes the lunar surface a time capsule of past activity (provided the site doesn't get wiped out by an asteroid impact), in a way that the Earth isn't. We've yet to photograph the surface at high enough resolution to really know what's there.
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.
Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3 ;-). But this issue is about more than just that.
I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.
This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.
Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.
DTrace lets us examine just about anything, with minimal impact on the system. It's way cool, and other OSes have nothing that is close (for details covering the Linux Trace Toolkit (LTT), DProbes, K42 and Kerninst see the USENIX paper.
DTrace solves disk I/O by PID, network activity by PID, elapsed and on-cpu times for syscalls, libcalls and user funcs, and much more.
DTrace is great if you are a programmer with a little kernel knowledge, but if not you may find the DTraceToolkit helpful - it is a collection of ready-to-roll scripts.
For a list of many OpenSolaris features with screenshots, see the OpenSolaris Guide.
"I don't think so."
fine. use QWERTY, get sore hands, and maybe it will hurt too much to post such nonscense.
Lets see, would I use a keyboard that is designed for ergonomics and speed? or one that is designed to stop metal arms from jamming in a 19th century typewriter?
Brendan
(been using DVORAK for around 8 years, and can still easily type on QWERTY - though I prefer not to)
Maybe the closest tool is truss (Solaris) or strace (Linux), which are invaluable troubleshooting tools.
DTrace goes much, much further. It can examine system calls, library functions, user functions; for each call it can fetch nanosecond timestamps, retrieve values from kernel memory, user memory, print stack backtraces, gather statistics... It has minimal system impact, and can trace inside the code of software that has never heard of DTrace before.
It is good news to sysadmins who want to understand performance problems with their systems (or any other behaviour).
It is bad news for developers who are rotton programmers and for software companies who peddle poorly written software (and may have done so for years). DTrace can expose problems in their source code, source code they previous would have hit compile and then assumed was hidden.
Brendan
Chaosreader is opensource!
It automates capturing application data, eg HTTP or FTP, and can replay data: eg telnet, X11 or VNC. plus lots more.
It's useful to highlight the need for encryption, or as a general networking tool.
Chaosreader is still beta (0.94) by the time it's more robust and optimised it will be released as 1.00.
http://chaosreader.sourceforge.net