6

I have found the DTrace intriguing but have personally failed to see a use-case that allow me to get information that I cannot get otherwise anyway without using DTrace.

Hence, I would like to hear what I have overlooked. What can I do on my vmware OpenIndiana build 148 with DTrace that can make a difference when creating stand-alone applications and Java EE web applications (most of which communicate heavily with a legacy backend using sockets)?

Non-trivial Dtrace scripts are very welcome.

Nishant
  • 54,584
  • 13
  • 112
  • 127
Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347

1 Answers1

6

I had some good experiences with DTrace.

I had a client running our Java code on a production server running 24x7. We had some performance issues with the applications. It was impossible to stop the JVMs in order to attach the profiler. Moreover the behavior was not present in our lab under the same load.

We solved the issue using DTrace with the JVM related probes as I could attach it to the running JVMs and the overhead introduced was minimal (1.3% on a Netra T2000 SPARC machine).

The bonus of the method was that all the debugging was done via a dial-up (33kbps) line to the customer's lab. It is almost impossible to run any other profiler/debugger with this constraints (JDWP is quite verbose for this bandwidth). With my DTrace script I filtered only what it was interesting for me.

For some hints see: http://java.dzone.com/articles/java-profiling-dtrace?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+javalobby/frontpage+(Javalobby+/+Java+Zone)

http://download.oracle.com/javase/6/docs/technotes/guides/vm/dtrace.html

I have adapted those scripts http://blogs.oracle.com/ahl/date/20050418#dtracing_java

Another big plus are the aggregated values that can be easily used to create custom statistics.

But, if you have appropriate conditions, everything can be done easier with othe tools. DTrace is very powerfull but it targets more bare-metal conditions (maybe DLight project would help).

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
Daniel Voina
  • 3,185
  • 1
  • 27
  • 32
  • Not so easy to describe. The applications were for a telco. They were event driven SIP applications. 1st: The SIP sessions were kept in a map. On heavy loads, there were some calls never ending due to the fact that new incoming calls were blocking the BYE messages to the current ones. DTrace showed me the race conditions. 2nd: They were creating huge ammounts of string objects due to parsing of SIP messages. I have spotted the hottest points on the app reducing the string creation and helping the GC. – Daniel Voina Mar 08 '11 at 20:49