On Tue, Jun 22, 2010 at 6:22 PM, tester <solaris.ident...@gmail.com> wrote:
> Thanks Mike.
>
>> Is it unresponsive only when dtrace is running or
>> normally?
>
> It becomes unresponsive after starting Dtrace.
[snip]
>
> This time I was able to get some o/p from the script otherwise with load I 
> have not seen script o/p.  Now you can imagine the state of the system if the 
> initail load was 10-15.
>
> Please let mw know if you need more details.

Hmmm... it looks like you are just having troubles with the enabled
probes being to heavy.  My approach would be to try to reduce the
amount of data that is being collected.  You could try:

- Use a lower frequency in your profile provider.  That is, switch
profile-397 to something like profile-113.
- Reduce the number of stack frames from 40 to 10.
- Try tracing only one thread at a time.

For the last suggestion, you can probably figure out which are the
interesting/busy threads with:

prstat -mLc -n 10 1 5

You should be able to observe one thread (tid - the part after the /
at the end of the line in prstat output) at a time with...

profile-113
/pid == 18900 && tid == 123/
{
 @[jstack(10,1024)] = count()
}

tick-5s {
  trunc(@,10);
  printa(@);
  trunc(@);
}


Perhaps if you share the output of "prstat -mLc -n 10 1 5" when the
unexpected load exists something will jump out.  For example, if we
see a large amount of %sys, it may be worthwhile looking at the
syscall provider.

You may also want to take a look at tools that are java-specific.  I
haven't had a need to try these, but a quick search reveals
http://profiler.netbeans.org/ which looks interesting.

Also, I haven't had much of a chance to compare the performance of
jstack vs. ustack.  It could be that you are seeing a performance hit
due to the JVM saying "256 CPUs?  Ahh, you must want 256 garbage
collection threads!"  Using ustack() instead of jstack() may be
lighter weight (I've had good success with ustack(5) at profile-997 on
a pretty busy T5240 debugging JNI calls).  I suspect a similar
approach may point out heavy GC activity.

http://www.c0t0d0s0.org/archives/6617-About-Java,-parallel-garbage-collection-and-processor-sets.html

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org

Reply via email to