The following is a demonstration of the cpuwalk.d script,
cpuwalk.d is not that useful on a single CPU server,
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.