Re: [dtrace-discuss] track program time - need some guidelines
tester wrote: Hi, Need some dtrace pointers to track time spent by some programs. N processes with N threads each running on a multiprocessor system. What probes to use to decompose total run time to on-proc, sleep, io etc? Since it's a muliprocessor system, I am guessing that the toal units of time will be in the terms of " clock ticks" and so will be the break up. So for example on a 2X2Ghz system a program running for 10 sec has, theoretically 10*2*2*1024*1024 clock ticks potentially available. How to track how much of this the program is using (with a breakup of on-cpu and io wait etc) Or am I completely off on this with a different approach? Sounds like you want the Sun Studio performance analyzer to me... man collect Ryan ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] track program time - need some guidelines
Hi, Need some dtrace pointers to track time spent by some programs. N processes with N threads each running on a multiprocessor system. What probes to use to decompose total run time to on-proc, sleep, io etc? Since it's a muliprocessor system, I am guessing that the toal units of time will be in the terms of " clock ticks" and so will be the break up. So for example on a 2X2Ghz system a program running for 10 sec has, theoretically 10*2*2*1024*1024 clock ticks potentially available. How to track how much of this the program is using (with a breakup of on-cpu and io wait etc) Or am I completely off on this with a different approach? Also what will the additional impact of tracking such usage with Dtrace. Thanks -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Question about ID from trace
It's the ID of the probe, not the provider.
/jim
Andrea Cucciarre' wrote:
I guess that the ID you see it's the ID of the provider not the PID
On 07/10/09 16:01, Robert Alatalo wrote:
Hello,
Trying to track down what application is causing the system to
reboot by turning the uadmin system call's reboot into a panic, we
are running the following script:
-x-x- start of uadmin.d -x-x-
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::uadmin:entry
/arg0 == 1 && uid == 0/
{
panic();
}
syscall::uadmin:entry
{
trace("I am not root")
}
-x-x- end of uadmin.d -x-x-
We are getting a string of output:
dtrace: script '/usr/local/bin/uadmin.d' matched 2 probes
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
261 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
259 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
...
...
I thought that the ID should be a PID, but
# ps -ef|grep 8063
<>
Any suggestions on how to track down this rouge entity which is
futilely trying to do something with uadmin?
thanks,
Robert
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Question about ID from trace
I guess that the ID you see it's the ID of the provider not the PID
On 07/10/09 16:01, Robert Alatalo wrote:
Hello,
Trying to track down what application is causing the system to
reboot by turning the uadmin system call's reboot into a panic, we are
running the following script:
-x-x- start of uadmin.d -x-x-
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::uadmin:entry
/arg0 == 1 && uid == 0/
{
panic();
}
syscall::uadmin:entry
{
trace("I am not root")
}
-x-x- end of uadmin.d -x-x-
We are getting a string of output:
dtrace: script '/usr/local/bin/uadmin.d' matched 2 probes
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
261 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
259 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
...
...
I thought that the ID should be a PID, but
# ps -ef|grep 8063
<>
Any suggestions on how to track down this rouge entity which is
futilely trying to do something with uadmin?
thanks,
Robert
--
/\ Andrea Cucciarre'
\\ \ Systems Engineer
\ \\ /
/ \/ / /Sun Microsystems Italia SpA
/ / \//\ Viale Fulvio Testi, 327
\//\ / / 20162 Milano
/ / /\ /
/ \\ \ phone: 800 605228
\ \\ e-mail: andrea.cuccia...@sun.com
\/
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Question about ID from trace
On Fri, Jul 10, 2009 at 10:01 AM, Robert Alatalo wrote: > > We are getting a string of output: > > > dtrace: script '/usr/local/bin/uadmin.d' matched 2 probes > dtrace: allowing destructive actions > CPU ID FUNCTION:NAME > 258 8063 uadmin:entry I am not root > 258 8063 uadmin:entry I am not root > > I thought that the ID should be a PID, but > # ps -ef|grep 8063 > > <> > The ID is the probe ID, not the process ID. If you want the process ID, try, "trace(pid)". Or some variant of printf() where you explicitly access the pid variable. Chad ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] Question about ID from trace
Hello,
Trying to track down what application is causing the system to reboot
by turning the uadmin system call's reboot into a panic, we are running the
following script:
-x-x- start of uadmin.d -x-x-
#!/usr/sbin/dtrace -s
#pragma D option destructive
syscall::uadmin:entry
/arg0 == 1 && uid == 0/
{
panic();
}
syscall::uadmin:entry
{
trace("I am not root")
}
-x-x- end of uadmin.d -x-x-
We are getting a string of output:
dtrace: script '/usr/local/bin/uadmin.d' matched 2 probes
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
261 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
259 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
256 8063 uadmin:entry I am not root
257 8063 uadmin:entry I am not root
258 8063 uadmin:entry I am not root
...
...
I thought that the ID should be a PID, but
# ps -ef|grep 8063
<>
Any suggestions on how to track down this rouge entity which is futilely
trying to do something with uadmin?
thanks,
Robert
--
If you would prefer to be contacted via phone or e-mail. Please
let me know.
=
=
Robert Alatalo ~ Technical Support Engineer
Sun Microsystems, Burlington, MA 01803
Phone:781-442-1301, Fax:781-442-1655 , E-mail:ralat...@sun.com
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
ONLINE SUPPORT CENTER: http://www.sun.com/service/online
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
All information in this e-mail is Sun Microsystems privileged,
confidential information and intended for addressee(s) only.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
