1The 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 12The above output shows that threads belonging to sched, the kernel, spent 13a total of 220 microseconds waiting for an adaptive mutex lock. 14 15 16 17 18This 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 33Here we can see threads belonging to fsflush have spent a total of 19.7 ms 34waiting for an adaptive mutex. Note: it's not easy to say that it means a 3519.7 ms delay in the completion of the fsflush program, as this value is 36the sum of the block times across all the threads. So it is possible that 37many threads were blocked at the same time, eg, it could have been 19 threads 38blocked during the same 1 ms. 39 40 41 42 43