109 lines
4.1 KiB
Plaintext
109 lines
4.1 KiB
Plaintext
The following is a demonstration of the threaded.d script,
|
|
|
|
|
|
Here we run a test program called "cputhread" that creates 4 busy threads
|
|
that run at the same time. Here we run it on a server with only 1 CPU,
|
|
|
|
# threaded.d
|
|
|
|
2005 Jul 26 02:56:37,
|
|
|
|
PID: 8516 CMD: cputhread
|
|
|
|
value ------------- Distribution ------------- count
|
|
1 | 0
|
|
2 |@@@@@@@ 17
|
|
3 |@@@@@@@@@@@ 28
|
|
4 |@@@@@@@@@@@ 27
|
|
5 |@@@@@@@@@@@ 28
|
|
6 | 0
|
|
[...]
|
|
|
|
In the above output, we can see that cputhread has four busy threads with
|
|
thread IDs 2, 3, 4 and 5. We are sampling at 100 Hertz, and have caught
|
|
each of these threads on the CPU between 17 and 28 times.
|
|
|
|
Since the above counts add to 100, this is either a sign of a single CPU
|
|
server (which it is), or a sign that a multithreaded application may be
|
|
running "serialised" - only 1 thread at a time. Compare the above output
|
|
to a multi CPU server,
|
|
|
|
|
|
|
|
Here we run the same test program on a server with 4 CPUs,
|
|
|
|
# threaded.d
|
|
|
|
2005 Jul 26 02:48:44,
|
|
|
|
PID: 5218 CMD: cputhread
|
|
|
|
value ------------- Distribution ------------- count
|
|
1 | 0
|
|
2 |@@@@@@@@@@@ 80
|
|
3 |@@@@@@@@@@ 72
|
|
4 |@@@@@@@@@ 64
|
|
5 |@@@@@@@@@@@ 78
|
|
6 | 0
|
|
[...]
|
|
|
|
This time the counts add to equal 294, so this program is definitely
|
|
running on multiple CPUs at the same time, otherwise this total would
|
|
not be beyond our sample rate of 100. The distribution of threads on CPU
|
|
is fairly even, and the above serves as an example of a multithreaded
|
|
application performing well.
|
|
|
|
|
|
|
|
Now we run a test program called "cpuserial", which also create 4 busy
|
|
threads, however due to a coding problem (poor use of mutex locks) they
|
|
only run one at a time,
|
|
|
|
# threaded.d
|
|
|
|
2005 Jul 26 03:07:21,
|
|
|
|
PID: 5238 CMD: cpuserial
|
|
|
|
value ------------- Distribution ------------- count
|
|
2 | 0
|
|
3 |@@@@@@@@@@@@ 30
|
|
4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 70
|
|
5 | 0
|
|
[...]
|
|
|
|
The above looks like we are back on a single CPU server with 100 samples
|
|
in total, however we are still on our 4 CPU server. Only two threads have
|
|
run, and the above distribution is a good indication that they have
|
|
run serialised.
|
|
|
|
|
|
|
|
Now more of a fringe case. This version of cpuserial again creates 4 threads
|
|
that are all busy and hungry for the CPU, and again we run it on a 4 CPU
|
|
server,
|
|
|
|
# threaded.d
|
|
|
|
2005 Jul 26 03:25:45,
|
|
|
|
PID: 5280 CMD: cpuserial
|
|
|
|
value ------------- Distribution ------------- count
|
|
1 | 0
|
|
2 |@@@@@@@@@@@@@@@ 42
|
|
3 |@@@@@@@@@@@@@@@@@@ 50
|
|
4 |@@@@@@ 15
|
|
5 |@ 2
|
|
6 | 0
|
|
[...]
|
|
|
|
So all threads are running, good. And with a total of 109, at some point
|
|
more than one thread was running at the same time (otherwise this would
|
|
not have exceeded 100, bearing in mind a sample rate of 100 Hertz). However,
|
|
what is not so good is that with 4 CPUs we have only scored 109 samples -
|
|
since all threads are CPU hungry we'd hope that more often they could
|
|
run across the CPUs simultaneously; however this wasn't the case. Again,
|
|
this fault was created by poor use of mutex locks.
|
|
|