G''Day,
On Tue, 11 Apr 2006, leslie wrote:
> prustat can be used to see the status of each process.
Yes, prustat is my dream tool - CPU/Mem/Disk/Net by process. Eg,
# prustat -t5 5
PID %CPU %Mem %Disk %Net COMM
440 14.77 45.39 0.00 0.00 Xsun
2618 0.58 14.34 0.00 0.00 mozilla-bin
582 2.76 2.16 0.00 0.00 gnome-terminal
22301 0.01 3.16 0.00 0.00 setiathome
574 1.71 1.31 0.00 0.00 metacity
...
> I mostly use it to see the cpu and memory usage for each process.
Firstly, while prustat looks like an incredible tool, it is worth
explaining why it is not in the DTraceToolkit. That is due to the
following,
$ more prustat
#!/usr/bin/perl
#
# prustat - Process utilisation stats: %CPU, %Mem, %Disk, %Net. Solaris 10.
# Needs to run as root. This is a demonstration release - check for
# newer optimised versions. Uses Kstat, DTrace and procfs.
#
# 12-Mar-2005, ver 0.50 (demonstration release, http://www.brendangregg.com)
...
It is described twice in the first 7 lines as a demonstration release.
This means it hasn''t been properly tested and verified to be accurate.
For
this reason it has been rejected, until a newer version is released.
This is an example of me rejecting my own tools! Fantastic as prustat is,
it is going to take a lot of testing to make me happy (especially since it
is the sort of tool that customers will depend upon, possibly too much!).
I am aware that I need to update how it calculateds %Net - as it could be
more accurate than it currently is. (oh, and I should do a TIOCGWINSZ and
scale appropriatly also)...
> But I have a
> question. The percentage of cpu usage is based on the all cpu. Are
> there any methodes to see how much percent of cpu do each processes use?
> I want to statistic usage for each cpu. I see prustat mainly use
> /proc/pid/psinfo to get pctcpu and pctmem. It looks like no cpu id
> options in it. Is it mean prustat can not do what I want? If yes, where
> can I find such a script to do it.
Uhh, perhaps you shouldn''t use prustat so much until it is more than
just
a demonstration release. :) ... actually, a reason why prustat has stayed a
demonstration release for so long, is that few people have emailed me to
say they liked it - so your posting will encourage me to go and fix it
up.
Ok, a script that may answer your question is cpuwalk.d from the
DTraceTolokit. See Docs/Examples/cpuwalk_example.txt. Eg,
# cpuwalk.d 5
Sampling...
PID: 12194 CMD: cpuserial
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@ 470
1 |@@@@@@ 920
2 |@@@@@@@@@@@@@@@@@@@@@@@@@ 3840
3 |@@@@@@ 850
4 | 0
This shows that the multi-threaded process (PID 12194, "cpuserial") is
running on CPUs 0, 1, 2 and 3, in an unbalanced manner. By defalt this
samples at 1000 Hz, and prints a report when either Ctrl-C is hit or a
provided interval is reached (see Bryan - I am using "defaultargs" :).
The count is the number of samples for that CPU; so in the above example,
the process spent most of its time on CPU 2.
I''ve sourced the entire example file at the bottom of this email, as I
think it''s a kick-arse demo of DTrace... :-)
...
cheers,
Brendan
[Sydney, Australia]
...
DTraceToolkit-0.92/Docs/Examples/cpuwalk_example.txt
-----
The following is a demonstration of the cpuwalk.d script,
cpuwalk.d is not that useful on a single CPU server,
# cpuwalk.d
Sampling... Hit Ctrl-C to end.
^C
PID: 18843 CMD: bash
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 30
1 | 0
PID: 8079 CMD: mozilla-bin
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 10
1 | 0
The output above shows that PID 18843, "bash", was sampled on CPU 0 a
total
of 30 times (we sample at 1000 hz).
The following is a demonstration of running cpuwalk.d with a 5 second
duration. This is on a 4 CPU server running a multithreaded CPU bound
application called "cputhread",
# cpuwalk.d 5
Sampling...
PID: 3 CMD: fsflush
value ------------- Distribution ------------- count
1 | 0
2 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 30
3 | 0
PID: 12186 CMD: cputhread
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@@@@@@@@ 4900
1 |@@@@@@@@@@ 4900
2 |@@@@@@@@@@ 4860
3 |@@@@@@@@@@ 4890
4 | 0
As we are sampling at 1000 hz, the application cputhread is indeed running
concurrently across all available CPUs. We measured the applicaiton on
CPU 0 a total of 4900 times, on CPU 1 a total of 4900 times, etc. As there
are around 5000 samples per CPU available in this 5 second 1000 hz sample,
the application is using almost all the CPU capacity in this server well.
The following is a similar demonstration, this time running a multithreaded
CPU bound application called "cpuserial" that has a poor use of
locking
such that the threads "serialise",
# cpuwalk.d 5
Sampling...
PID: 12194 CMD: cpuserial
value ------------- Distribution ------------- count
< 0 | 0
0 |@@@ 470
1 |@@@@@@ 920
2 |@@@@@@@@@@@@@@@@@@@@@@@@@ 3840
3 |@@@@@@ 850
4 | 0
In the above, we can see that this CPU bound application is not making
efficient use of the CPU resources available, only reaching 3840 samples
on CPU 2 out of a potential 5000. This problem was caused by a poor use
of locks.
-----