pstime - a mash-up of ps(1) and ptime(1)

I have done some testing in the past where I needed to know the amount of CPU consumed by a process more accurately than I can get from the standard set of operating system utilities.

Recently I hit the same issue - I wanted to collect CPU consumption of mysqld.

To capture process CPU utilization over an interval on Solaris, about the best I can get is the output from a plain "prstat" command, which might look like:

mashie ) prstat -c -p `pgrep mysqld` 5 2
Please wait...
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
  7141 mysql     278M  208M cpu0    39    0   0:38:13  40% mysqld/45
Total: 1 processes, 45 lwps, load averages: 0.63, 0.33, 0.18
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP       
  7141 mysql     278M  208M cpu1    32    0   0:38:18  41% mysqld/45
Total: 1 processes, 45 lwps, load averages: 0.68, 0.34, 0.18

I am after data from the second sample only (still not sure exactly how prstat gets data for the fist sample, which comes out almost instantaneously), so you can guess I will need some sed/perl that is a litte more complicated than I would prefer.

pstime reads PROCFS (i.e.. the virtualized file-system mounted on /proc) and captures CPU utilization figures for processes. It will report the %USR and %SYS either for a specific list of processes, or every process running on the system (i.e., running at both sample points). The start sample time is recorded in high resolution at the time a process' data is captured, and then again after N seconds, where N is the first parameter supplied to pstime.

The default output of pstime is expressed as either a percentage of whole system CPU, or CPU seconds, with four significant digits. Solaris itself records the original figures in nanosecond resolution, although we do not expect today's hardware to be that accurate.

Here is an example:

mashie ) pstime 10 `pgrep sysbench\\|mysqld`
  UID    PID  %USR  %SYS COMMAND
mysql   7141 44.17 3.391 /u/dist/mysql60-debug/bin/mysqld --defaults-file=/et
mysql  19870 2.517 2.490 sysbench --test=oltp --oltp-read-only=on --max-time=
mysql  19869 0.000 0.000 /bin/sh -p ./run-sysbench

Downloads

Comments:

BTW, have you seen the recent behavior of ptime:

# ptime -mp `pgrep syslogd`

real 188:03:13.534915573
user 0.265454413
sys 0.446344125
trap 0.000923692
tflt 0.000000000
dflt 0.000000000
kflt 0.000000000
lock 2068:34:43.661316464
slp 752:13:09.781305826
lat 5.526255235
stop 0.005778086
#

It only occurred to me after this was putback (actually, after I started putting it to real use) that I should have added a sampling period option (e.g., -s 10) and a percentage option.

Note that the version of ptime that does this can be copied onto a Solaris 10 box and still work.

Posted by Chad Mynhier on April 27, 2009 at 07:40 AM PDT #

Chad,

Yes! I had seen your excellent addition to ptime; and have pointed it out to others. I didn't know it could go back that far. I'm still not sure where the best place for the functionality of pstime would be, if it were to become a new feature. I have thought about adding a microstate data dump feature to pstime, though.

Regards,
Tim

Posted by Tim Cook on April 27, 2009 at 09:19 AM PDT #

prstat -mc -n10,1 1
Should be helpful for you.

Chad - yes, ptime -i N -p PID would be useful but on the other hand you get almost the same information by 'prstat -m -p PID -c 1'

Posted by Robert Milkowski on April 28, 2009 at 08:48 PM PDT #

Post a Comment:
Comments are closed for this entry.
About

Tim Cook's Weblog The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today