Tuesday November 21, 2006 It was quite some time ago since I provided an update on CPU caps. A lot have happened since then. I was working on finishing the implementation and now the development phase is complete. So, I went back to the documentation and updated both the design document and the implementation description.
The major change is the addition of the observability hooks to the project. I used the nice kstat(1M) facility to provide some visibility into CPU caps inner workings.
First of all I created a project for myself by adding a line in /etc/project:
user.akolb:1234:Projects for akolb:*:*:project.cpu-cap=(privileged,50,none)
I could then join the project:
$ newtask -p akolb -c $$
$ ps -o user,project,comm -p $$
USER PROJECT COMMAND
akolb akolb bash
Now I started a process that does nothing but consumes CPU cycles:
$ while [ 1 ]; do true; done
Running prstat -J 1 showed that my project uses 25% of the system
(50% of a CPU on a 2-CPU system gives 25% total). Now I use kstats to verify how
am I doing with caps:
$ kstat caps
module: caps instance: 0
name: cpucaps_project_1234 class: project_caps
above_sec 278
below_sec 97
flags 10
nwait 1
usage 49
value 50
I can see that the cap value is set to 50%, the actual usage at the moment is
49%, there is one thread on the wait queue and the cap was below the cap for 97
seconds (~26%) and above the cap for 278 seconds which is pretty close to
expectations. This output immediately shows me how much my applications are
affected by CPU caps. Low above_sec/below_sec values mean that the impact is
minimum, while high values indicate that my application is seriously
constrained.
The design document provides additional information on observing CPU caps with DTrace and provides a couple of interesting examples. It allows us to pinpoint CPU caps effect for specific process.
[ Technorati: Scheduler, Solaris ]
( Nov 21 2006, 06:25:03 PM PST ) Permalink