Is there any way to check what process is running on CPU''s? I have new T2000 server which is multi core and multi thread and I would like to know what is running at given time on any of my threads/cores in terms of PID and maybe process names or something... I did look at many examples and did try to come up with something thats meaningfull but I am not able to do that... Maybe I am to novice for DTrace yet. Anyway thanks for any help... Chris
On Thu, 16 Feb 2006, Krzys wrote:> Is there any way to check what process is running on CPU''s? I have new T2000 > server which is multi core and multi thread and I would like to know what is > running at given time on any of my threads/cores in terms of PID and maybe > process names or something...Hi Chris, You have a couple of options. The first option is prstat, which allows you to view each thread along with the CPU the thread is running on. The second option would be DTrace''sched provider. This nifty little provider contains the enqueue, dequeue, on-cpu and off-cpu probes, and is described in gory detail on docs.sun.com: http://docs.sun.com/app/docs/doc/817-6223/6mlkidll6?a=view Hope this helps, - Ryan -- UNIX Administrator http://daemons.net/~matty
Great, thank you, I just wanted to do it in dtrace rather than other tools since I wanted to learn it and see maybe it can expand to do something more than I wanted to start with... I''ve downloaded the whole DTrace user guide and am going rough it along with few other examples... It will probably take me a while to get comfortable with DTRace but I love it and all the tools that people wrote... Anyway thanks for helpful link. Chris On Thu, 16 Feb 2006, Matty wrote:> > On Thu, 16 Feb 2006, Krzys wrote: > >> Is there any way to check what process is running on CPU''s? I have new >> T2000 server which is multi core and multi thread and I would like to know >> what is running at given time on any of my threads/cores in terms of PID >> and maybe process names or something... > > Hi Chris, > > You have a couple of options. The first option is prstat, which allows you to > view each thread along with the CPU the thread is running on. The second > option would be DTrace''sched provider. This nifty little provider > contains the enqueue, dequeue, on-cpu and off-cpu probes, and is described in > gory detail on docs.sun.com: > > http://docs.sun.com/app/docs/doc/817-6223/6mlkidll6?a=view > > Hope this helps, > - Ryan > > -- > UNIX Administrator > http://daemons.net/~matty > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org > > > !DSPAM:122,43f4d62426854137527416! >
Hi,
here is a simple dtrace script I wrote, to see when a thread of a proccess
switches the cpu, or the CPU board (on a E2900). Maybe you can derive a version
that works for you.
Is seems to work fine, but I don''t get why output line are sometimes
repeated. E.g:
TID CPU ID Boardnr
1 529 2
2 2 0
2 3 0
1 16 2
1 16 2
1 16 2
1 16 2
1 17 2
===========================#pragma D option quiet
dtrace:::BEGIN
{
printf("TID CPU ID Boardnr\n");
}
sched:::on-cpu
/self->lastcpu != cpu && pid == $target/
{
self->lastcpu = cpu;
oncpu[tid] ++;
printf ("%d %d %d\n",tid,cpu, (cpu&24)/8);
}
dtrace:::END
{
}
===================================
Regards
Samuel
This message posted from opensolaris.org
On Tue, Feb 28, 2006 at 01:47:08AM -0800, Samuel Sarholz wrote:> Hi, > > here is a simple dtrace script I wrote, to see when a thread of a proccess switches the cpu, or the CPU board (on a E2900). Maybe you can derive a version that works for you. > Is seems to work fine, but I don''t get why output line are sometimes repeated. E.g: > > TID CPU ID Boardnr > 1 529 2 > 2 2 0 > 2 3 0 > 1 16 2 > 1 16 2 > 1 16 2 > 1 16 2 > 1 17 2 > > ===========================> #pragma D option quiet > dtrace:::BEGIN > { > printf("TID CPU ID Boardnr\n"); > } > sched:::on-cpu > /self->lastcpu != cpu && pid == $target/ > { > self->lastcpu = cpu; > oncpu[tid] ++; > printf ("%d %d %d\n",tid,cpu, (cpu&24)/8); > } > dtrace:::END > { > } > ===================================I''m not sure why there would be repeats, either; here''s a version of your script which might help suss it out: --- cut here --- #!/usr/sbin/dtrace -s #pragma D option quiet self int lastcpu; /* == last cpu seen on + 1, or 0 if unseen */ dtrace:::BEGIN { printf("%-6s %6s %4s %4s %s\n", "PID", "TID", "PREV", "CPU", "Board#"); } sched:::on-cpu /pid == $target && self->lastcpu != (cpu + 1)/ { printf("%6d %6d %4d %4d %d\n", pid, tid, self->lastcpu - 1, cpu, (cpu & 24)/8); self->lastcpu = cpu + 1; } --- cut here --- Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
On Tue, Feb 28, 2006 at 11:06:16AM -0800, Jonathan Adams wrote:> On Tue, Feb 28, 2006 at 01:47:08AM -0800, Samuel Sarholz wrote: > > Hi, > > > > here is a simple dtrace script I wrote, to see when a thread of a proccess switches the cpu, or the CPU board (on a E2900). Maybe you can derive a version that works for you. > > Is seems to work fine, but I don''t get why output line are sometimes repeated. E.g: > > > > TID CPU ID Boardnr > > 1 529 2 > > 2 2 0 > > 2 3 0 > > 1 16 2 > > 1 16 2 > > 1 16 2 > > 1 16 2 > > 1 17 2 > > > > ===========================> > #pragma D option quiet > > dtrace:::BEGIN > > { > > printf("TID CPU ID Boardnr\n"); > > } > > sched:::on-cpu > > /self->lastcpu != cpu && pid == $target/ > > { > > self->lastcpu = cpu; > > oncpu[tid] ++; > > printf ("%d %d %d\n",tid,cpu, (cpu&24)/8); > > } > > dtrace:::END > > { > > } > > ===================================> > I''m not sure why there would be repeats, either; here''s a version of your > script which might help suss it out:Actually, there''s a simple explanation; in dtrace, each CPU has its own buffer, which are downloaded and processed in order. So if a thread migrates as follows: ... -> 16 -> 17 -> 16 -> ... The buffers will fill up: CPU 16 CPU 17 ------ ------ 1/16/2 1/17/2 1/16/2 and will get printed out as: 1 16 2 1 16 2 1 17 2 even though the actual timestamp order is: 1 16 2 1 17 2 1 16 2 Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
So - Is there an equally simply / funky way to get the output in order? :) Nathan. On Wed, 2006-03-01 at 06:30, Jonathan Adams wrote:> On Tue, Feb 28, 2006 at 11:06:16AM -0800, Jonathan Adams wrote: > > On Tue, Feb 28, 2006 at 01:47:08AM -0800, Samuel Sarholz wrote: > > > Hi, > > > > > > here is a simple dtrace script I wrote, to see when a thread of a proccess switches the cpu, or the CPU board (on a E2900). Maybe you can derive a version that works for you. > > > Is seems to work fine, but I don''t get why output line are sometimes repeated. E.g: > > > > > > TID CPU ID Boardnr > > > 1 529 2 > > > 2 2 0 > > > 2 3 0 > > > 1 16 2 > > > 1 16 2 > > > 1 16 2 > > > 1 16 2 > > > 1 17 2 > > > > > > ===========================> > > #pragma D option quiet > > > dtrace:::BEGIN > > > { > > > printf("TID CPU ID Boardnr\n"); > > > } > > > sched:::on-cpu > > > /self->lastcpu != cpu && pid == $target/ > > > { > > > self->lastcpu = cpu; > > > oncpu[tid] ++; > > > printf ("%d %d %d\n",tid,cpu, (cpu&24)/8); > > > } > > > dtrace:::END > > > { > > > } > > > ===================================> > > > I''m not sure why there would be repeats, either; here''s a version of your > > script which might help suss it out: > > Actually, there''s a simple explanation; in dtrace, each CPU has its own > buffer, which are downloaded and processed in order. So if a thread > migrates as follows: > > ... -> 16 -> 17 -> 16 -> ... > > The buffers will fill up: > > CPU 16 CPU 17 > ------ ------ > 1/16/2 1/17/2 > 1/16/2 > > and will get printed out as: > > 1 16 2 > 1 16 2 > 1 17 2 > > even though the actual timestamp order is: > > 1 16 2 > 1 17 2 > 1 16 2 > > Cheers, > - jonathan > > -- > Jonathan Adams, Solaris Kernel Development > _______________________________________________ > dtrace-discuss mailing listdtrace-discuss at opensolaris.org -- ////////////////////////////////////////////////////////////////// // Nathan Kroenert nathan.kroenert at sun.com // // PTS Engineer Phone: +61 2 9844-5235 // // Sun Services Direct Ext: x57235 // // Level 2, 828 Pacific Hwy Fax: +61 2 9844-5311 // // Gordon 2072 New South Wales Australia // //////////////////////////////////////////////////////////////////
On Wed, Mar 01, 2006 at 10:59:34AM +1100, Nathan Kroenert wrote:> So - Is there an equally simply / funky way to get the output in order?Well, you can, but it gets tricky. The simplest way is to use (abuse) an aggregation: --- cut here --- #!/usr/sbin/dtrace -s #pragma D option quiet dtrace:::BEGIN { printf("%-16s %6s %4s %s\n", "TIMESTAMP", "TID", "CPU", "BOARD"); } sched:::on-cpu /self->lastcpu != cpu + 1 && pid == $target/ { @a[timestamp, tid, cpu, (cpu & 24)/8] = count(); self->lastcpu = cpu + 1; } dtrace:::END, profile:::tick-1s { printa("%16x %6d %4d %4d\n", @a); trunc(@a); } --- cut here --- Here, the timestamp is the sorting key used in printing, so the output is always in timestamp order. (note that I add 1 to the cpuid before storing it in lastcpu; that keeps the default "0" value from matching CPU 0) Cheers, - jonathan> :) > > Nathan. > > On Wed, 2006-03-01 at 06:30, Jonathan Adams wrote: > > On Tue, Feb 28, 2006 at 11:06:16AM -0800, Jonathan Adams wrote: > > > On Tue, Feb 28, 2006 at 01:47:08AM -0800, Samuel Sarholz wrote: > > > > Hi, > > > > > > > > here is a simple dtrace script I wrote, to see when a thread of a proccess switches the cpu, or the CPU board (on a E2900). Maybe you can derive a version that works for you. > > > > Is seems to work fine, but I don''t get why output line are sometimes repeated. E.g: > > > > > > > > TID CPU ID Boardnr > > > > 1 529 2 > > > > 2 2 0 > > > > 2 3 0 > > > > 1 16 2 > > > > 1 16 2 > > > > 1 16 2 > > > > 1 16 2 > > > > 1 17 2 > > > > > > > > ===========================> > > > #pragma D option quiet > > > > dtrace:::BEGIN > > > > { > > > > printf("TID CPU ID Boardnr\n"); > > > > } > > > > sched:::on-cpu > > > > /self->lastcpu != cpu && pid == $target/ > > > > { > > > > self->lastcpu = cpu; > > > > oncpu[tid] ++; > > > > printf ("%d %d %d\n",tid,cpu, (cpu&24)/8); > > > > } > > > > dtrace:::END > > > > { > > > > } > > > > ===================================> > > > > > I''m not sure why there would be repeats, either; here''s a version of your > > > script which might help suss it out: > > > > Actually, there''s a simple explanation; in dtrace, each CPU has its own > > buffer, which are downloaded and processed in order. So if a thread > > migrates as follows: > > > > ... -> 16 -> 17 -> 16 -> ... > > > > The buffers will fill up: > > > > CPU 16 CPU 17 > > ------ ------ > > 1/16/2 1/17/2 > > 1/16/2 > > > > and will get printed out as: > > > > 1 16 2 > > 1 16 2 > > 1 17 2 > > > > even though the actual timestamp order is: > > > > 1 16 2 > > 1 17 2 > > 1 16 2 > > > > Cheers, > > - jonathan > > > > -- > > Jonathan Adams, Solaris Kernel Development > > _______________________________________________ > > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org > -- > ////////////////////////////////////////////////////////////////// > // Nathan Kroenert nathan.kroenert at sun.com // > // PTS Engineer Phone: +61 2 9844-5235 // > // Sun Services Direct Ext: x57235 // > // Level 2, 828 Pacific Hwy Fax: +61 2 9844-5311 // > // Gordon 2072 New South Wales Australia // > //////////////////////////////////////////////////////////////////-- Jonathan Adams, Solaris Kernel Development