1 **************************************************************************
2 * The following are additional notes on the cputimes command.
4 * $Id: cputimes_notes.txt 44 2007-09-17 07:47:20Z brendan $
6 * COPYRIGHT: Copyright (c) 2007 Brendan Gregg.
7 **************************************************************************
12 cputimes measures time consumed by the kernel, idle therads and processes,
13 by tracking the activity of the schedular. In particular we track on-cpu
14 and off-cpu events for kernel therads, measuring the timestamps at each event.
19 If you are interested in how much time processes are consuming, the data
20 given by "prstat" or "prstat -m" is fine. However there is no easy way to
21 see kernel consumed time, which is the idea behind cputimes.
26 The output shows categories of threads by the sum of time, in nanoseconds.
28 A nanosecond is 10^-9, or 0.000000001 of a second. This program uses
29 nanoseconds as units, but does not have nanosecond accuracy. It would be
30 reasonable to assume that this has microsecond accuracy (10^-6), so in
31 practise ignore the last three digits of the times.
33 The sections reported are,
35 PROCESSES - the sum of all the process time on the CPU.
36 KERNEL - the sum of the time spent in the kernel.
37 IDLE - the time the kernel spent in the idle thread, waiting for some work.
39 If your system isn't doing much, then the idle time will be quite large. If
40 your system is running many applications, then there may be no idle time
41 at all - instead most of the time appearing under processes.
44 * When is there a problem?
46 Expect to see most of the time in processes or idle, depending on how busy
47 your server is. Seeing a considerable amout of time in kernel would
48 definately be interesting.
50 The kernel generally doesn't use much CPU time, usually less than 5%.
51 If it were using more, that may indicate heavy activity from an interrupt
52 thread, or activity caused by DTrace.
63 In this sample the kernel is using a massive amount of the CPUs, around 47%.
64 This sample was taken during heavy network utilisation, the time consumed
65 by the TCP/IP and network driver threads (and DTrace). The "intrstat" command
66 could be used for further analysis of the interrupt threads responsible
67 for servicing the network interface.
70 * Problems with cputimes
72 The way cputimes measures schedular activity turns out to be a lot of work.
73 There are many scheduling events per second where one thread steps onto a
74 CPU and another leaves. It turns out that cputimes itself causes some degree
77 Here we run 1 cputimes,
90 Now a second cputimes is run at the same time,
106 2005 May 15 12:03:09,
110 2005 May 15 12:03:10,
116 Each extra cputimes is consuming an extra 4 to 5 ms of the CPU as kernel time.
117 Around 0.5%. This can be used as an estimate of the kernel load caused by
118 running cputimes, and a similar strategy could be used to measure the kernel
119 load of other DTrace scripts.
121 However the following CPU characteristics must be taken into consideration,
124 Status of virtual processor 0 as of: 05/15/2005 12:06:05
125 on-line since 04/30/2005 13:32:32.
126 The i386 processor operates at 867 MHz,
127 and has an i387 compatible floating point processor.
129 as well as the type of activity that was also running on the system, which
130 cputimes was monitoring (frequency of scheduling events).
132 A system with a slower CPU will use a larger proportion of kernel time to
133 perform the same tasks. Also, a system that is context switching more
134 (switching between different processes) is likely to consume more kernel time