1 The following is a demonstration of the threaded.d script,
4 Here we run a test program called "cputhread" that creates 4 busy threads
5 that run at the same time. Here we run it on a server with only 1 CPU,
11 PID: 8516 CMD: cputhread
13 value ------------- Distribution ------------- count
22 In the above output, we can see that cputhread has four busy threads with
23 thread IDs 2, 3, 4 and 5. We are sampling at 100 Hertz, and have caught
24 each of these threads on the CPU between 17 and 28 times.
26 Since the above counts add to 100, this is either a sign of a single CPU
27 server (which it is), or a sign that a multithreaded application may be
28 running "serialised" - only 1 thread at a time. Compare the above output
29 to a multi CPU server,
33 Here we run the same test program on a server with 4 CPUs,
39 PID: 5218 CMD: cputhread
41 value ------------- Distribution ------------- count
50 This time the counts add to equal 294, so this program is definitely
51 running on multiple CPUs at the same time, otherwise this total would
52 not be beyond our sample rate of 100. The distribution of threads on CPU
53 is fairly even, and the above serves as an example of a multithreaded
54 application performing well.
58 Now we run a test program called "cpuserial", which also create 4 busy
59 threads, however due to a coding problem (poor use of mutex locks) they
60 only run one at a time,
66 PID: 5238 CMD: cpuserial
68 value ------------- Distribution ------------- count
71 4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 70
75 The above looks like we are back on a single CPU server with 100 samples
76 in total, however we are still on our 4 CPU server. Only two threads have
77 run, and the above distribution is a good indication that they have
82 Now more of a fringe case. This version of cpuserial again creates 4 threads
83 that are all busy and hungry for the CPU, and again we run it on a 4 CPU
90 PID: 5280 CMD: cpuserial
92 value ------------- Distribution ------------- count
95 3 |@@@@@@@@@@@@@@@@@@ 50
101 So all threads are running, good. And with a total of 109, at some point
102 more than one thread was running at the same time (otherwise this would
103 not have exceeded 100, bearing in mind a sample rate of 100 Hertz). However,
104 what is not so good is that with 4 CPUs we have only scored 109 samples -
105 since all threads are CPU hungry we'd hope that more often they could
106 run across the CPUs simultaneously; however this wasn't the case. Again,
107 this fault was created by poor use of mutex locks.