dtrace discuss - Sep 2006 - re timing shell script run

Hi
I am timing the running of various sh scripts on my system and use the 
following, question is this the best way of doing this?
Basically tracking execve of sh scripts  and then catching the exit.
( basically tracing the time an app spends executing sh scripts, called 
via execve)
Just for my own piece of mind that this is correct way of doing this.

-----
#!/usr/sbin/dtrace -qs
syscall::exec*:return
/execname == "sh"/
{
   self->start=timestamp;
}

fbt::exit:entry
/self->start/
{
    @alltimes[probefunc]=sum(timestamp - self->start);
    self->start=0;
}
-----

Hi Enda,

This seems reasonable, but you might want to use the proc:::exec-success and
proc:::exit probes as a more stable way of achieving the same end. I''m
not
sure why you''re keying the aggregation by probefunc, but
there''s nothing
wrong with that per se. Are you concerned with the sh scripts themselves
exec''ing?

Obviously sh is single-threaded, but if someone is planning on applying
the same methodology to a multi-threaded application, you might want to
store the start times in a global associative array keyed by pid since
a process can initiate an exit from a thread other than the initial one.

Adam

On Mon, Sep 25, 2006 at 05:42:29PM +0100, Enda O''Connor ( Sun Micro
Systems Ireland) wrote:
> Hi
> I am timing the running of various sh scripts on my system and use the 
> following, question is this the best way of doing this?
> Basically tracking execve of sh scripts  and then catching the exit.
> ( basically tracing the time an app spends executing sh scripts, called 
> via execve)
> Just for my own piece of mind that this is correct way of doing this.
> 
> -----
> #!/usr/sbin/dtrace -qs
> syscall::exec*:return
> /execname == "sh"/
> {
>   self->start=timestamp;
> }
> 
> fbt::exit:entry
> /self->start/
> {
>    @alltimes[probefunc]=sum(timestamp - self->start);
>    self->start=0;
> }
> -----
> 
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Adam,

Just to be clear, if you use proc:::exit, you don''t need to worry about
using a global associative array, since the exit is going to be from 
some thread within the process.

Also, I was wondering about Enda''s specific concern with
"execve".
Maybe all execs was what was really meant, but suppose someone wanted to 
restrict themselves to a finer granularity than just exec or exece, like 
just "execle" calls: would you have to use an fbt probe to get this
done?

Chip

Adam Leventhal wrote:
> Hi Enda,
>
> This seems reasonable, but you might want to use the proc:::exec-success
and
> proc:::exit probes as a more stable way of achieving the same end.
I''m not
> sure why you''re keying the aggregation by probefunc, but
there''s nothing
> wrong with that per se. Are you concerned with the sh scripts themselves
> exec''ing?
>
> Obviously sh is single-threaded, but if someone is planning on applying
> the same methodology to a multi-threaded application, you might want to
> store the start times in a global associative array keyed by pid since
> a process can initiate an exit from a thread other than the initial one.
>
> Adam
>
> On Mon, Sep 25, 2006 at 05:42:29PM +0100, Enda O''Connor ( Sun
Micro Systems Ireland) wrote:
>   
>> Hi
>> I am timing the running of various sh scripts on my system and use the 
>> following, question is this the best way of doing this?
>> Basically tracking execve of sh scripts  and then catching the exit.
>> ( basically tracing the time an app spends executing sh scripts, called
>> via execve)
>> Just for my own piece of mind that this is correct way of doing this.
>>
>> -----
>> #!/usr/sbin/dtrace -qs
>> syscall::exec*:return
>> /execname == "sh"/
>> {
>>   self->start=timestamp;
>> }
>>
>> fbt::exit:entry
>> /self->start/
>> {
>>    @alltimes[probefunc]=sum(timestamp - self->start);
>>    self->start=0;
>> }
>> -----
>>
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>     
>
>

Chip Bennett writes:
> Just to be clear, if you use proc:::exit, you don''t need to worry
about
> using a global associative array, since the exit is going to be from 
> some thread within the process.
Enda''s script used ''self'', which may refer to a
different thread than
the one that invokes proc::exit:.

-- 
James Carlson, KISS Network                    <james.d.carlson at
sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

James Carlson wrote:
> Chip Bennett writes:
>   
>> Just to be clear, if you use proc:::exit, you don''t need to
worry about
>> using a global associative array, since the exit is going to be from 
>> some thread within the process.
>>     
>
> Enda''s script used ''self'', which may refer to a
different thread than
> the one that invokes proc::exit:.
>   
I guess I was assuming that all threads in the process would fire 
proc:::exit, no matter who exited, but if that''s not true, your right, 
an alternate thread issuing the exit would never be seen by the exit 
clause, or even if the protective predicate wasn''t present,
there''d be
no way to connect to the original thread''s variable.

So use proc:::lwp-exit, and only the one that matches the predicate will 
execute.

Chip

On Mon, Sep 25, 2006 at 01:57:36PM -0500, Chip Bennett
wrote:
> So use proc:::lwp-exit, and only the one that matches the predicate will 
> execute.
Right, but that doesn''t actually answer the question that''s
being asking
"when does this _process_ exit".

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Adam Leventhal wrote:
> On Mon, Sep 25, 2006 at 01:57:36PM -0500, Chip Bennett wrote:
>   
>> So use proc:::lwp-exit, and only the one that matches the predicate
will
>> execute.
>>     
>
> Right, but that doesn''t actually answer the question
that''s being asking
> "when does this _process_ exit".
>
> Adam
>   
Right, because we don''t know when that thread is going to exit with 
respect to the process.  OK, I think I''ll go back to my little corner 
and do my own work for a while.  ;-)

Chip

Hi
Thanks, this works fine, I changed the aggregation key as well, thanbks 
for the info, it giving me reasonale timings for my sh scripts, I''m not
concerned with the actual execing of the scripts just the time it takes 
the app to execute multiple sh scripts overall as a percentage of 
execution time.


Enda

Adam Leventhal wrote:
> Hi Enda,
> 
> This seems reasonable, but you might want to use the proc:::exec-success
and
> proc:::exit probes as a more stable way of achieving the same end.
I''m not
> sure why you''re keying the aggregation by probefunc, but
there''s nothing
> wrong with that per se. Are you concerned with the sh scripts themselves
> exec''ing?
> 
> Obviously sh is single-threaded, but if someone is planning on applying
> the same methodology to a multi-threaded application, you might want to
> store the start times in a global associative array keyed by pid since
> a process can initiate an exit from a thread other than the initial one.
> 
> Adam
> 
> On Mon, Sep 25, 2006 at 05:42:29PM +0100, Enda O''Connor ( Sun
Micro Systems Ireland) wrote:
> 
>>Hi
>>I am timing the running of various sh scripts on my system and use the 
>>following, question is this the best way of doing this?
>>Basically tracking execve of sh scripts  and then catching the exit.
>>( basically tracing the time an app spends executing sh scripts, called 
>>via execve)
>>Just for my own piece of mind that this is correct way of doing this.
>>
>>-----
>>#!/usr/sbin/dtrace -qs
>>syscall::exec*:return
>>/execname == "sh"/
>>{
>>  self->start=timestamp;
>>}
>>
>>fbt::exit:entry
>>/self->start/
>>{
>>   @alltimes[probefunc]=sum(timestamp - self->start);
>>   self->start=0;
>>}
>>-----
>>
>>
>>_______________________________________________
>>dtrace-discuss mailing list
>>dtrace-discuss at opensolaris.org
> 
>