cddl/contrib/dtracetoolkit/Examples/lockbyproc_example.txt

   1 The following is a demonstration of the lockbyproc.d script,
   2
   3    # lockbyproc.d
   4    dtrace: description 'lockstat:::adaptive-block ' matched 1 probe
   5    ^C
   6
   7      pageout                                                       49438
   8      mysql-test-run                                                96414
   9      oracle                                                       149086
  10      sched                                                        220601
  11
  12 The above output shows that threads belonging to sched, the kernel, spent
  13 a total of 220 microseconds waiting for an adaptive mutex lock.
  14
  15
  16
  17
  18 This example sampled for a longer interval,
  19
  20    # lockbyproc.d
  21    dtrace: description 'lockstat:::adaptive-block ' matched 1 probe
  22    ^C
  23
  24      init                                                         136228
  25      java                                                         371896
  26      oracle                                                       783402
  27      sched                                                       2315779
  28      mysqltest                                                   9428277
  29      mysql-test-run                                             10093658
  30      mysqld                                                     17412999
  31      fsflush                                                    19676738
  32
  33 Here we can see threads belonging to fsflush have spent a total of 19.7 ms
  34 waiting for an adaptive mutex. Note: it's not easy to say that it means a
  35 19.7 ms delay in the completion of the fsflush program, as this value is
  36 the sum of the block times across all the threads. So it is possible that
  37 many threads were blocked at the same time, eg, it could have been 19 threads
  38 blocked during the same 1 ms.
  39
  40
  41
  42