On Thu, May 20, 2010 at 7:46 AM, tester <solaris.ident...@gmail.com> wrote:
> Hello,
>
> We had a situation on a t5140 running solaris 10 where the load average
> from prstat were 20-25,30-40,60-80. We ran a simple dtrace cmd to capture the
> jstack using the pid provider using the PID from prstat. That action pushed
> the 1 minute load average to 120. Not only that we were not able to get any
> o/p, the system became unresponsive to SSH sessions. Ctrl-C were ignored for
> atleast 30 seconds. Some other simple dtrace one liners to aggregate syscalls
> per PID also resulted in the same behaviour. Any dtrace action during that
> time pushed the load significantly. I would like to believe that is an case
> operator error than dtrace issue. Please let us know if we missed something
> or if there are tunables in those situations.
>
> dtrace cmd used
> dtrace -n 'pid1234:::ent...@[jstack()] = count()}'
> and some other simple dtrace one liners to aggegate syscalls/pid.
>
The pid provider is fairly heavyweight. What's more, you've
instrumented every single function in that process (including all
libraries.) This is going to have a significant performance impact on
the application, and probably on the server itself, if the application
is the main thing running there.
A much better way to get what you want is the following:
profile-397
/ pid == 1234 /
{
@[jstack()] = count();
}
This will give you a feel for where the application is spending all of
its time, but it does it in a far more lightweight manner. Doing it
this way has a secondary benefit in that it can identify hot spots
inside functions. Your original script will only tell you how often
particular functions are entered and says nothing about how much time
is spent in those functions.
Chad
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
