9.4. DTrace lockstat Provider The lockstat provider probes help you discern lock contention statistics or understand virtually any aspect of locking behavior. The lockstat(1M) command is actually a DTrace consumer that uses the lockstat provider to gather its raw data. The lockstat provider makes available two kinds of probes: content-event probes and hold-event probes. Contention-event probes correspond to contention on a synchronization primitive; they fire when a thread is forced to wait for a resource to become available. Solaris is generally optimized for the noncontention case, so prolonged contention is not expected. Use these probes to aid your understanding of those cases in which contention does arise. Because contention is relatively rare, enabling contention-event probes generally doesn't substantially affect performance. Hold-event probes correspond to acquiring, releasing, or otherwise manipulating a synchronization primitive. These probes can answer arbitrary questions about the way synchronization primitives are manipulated. Because Solaris acquires and releases synchronization primitives very often (on the order of millions of times per second per CPU on a busy system), enabling hold-event probes has a much higher probe effect than does enabling contention-event probes. While the probe effect induced by enabling the probes can be substantial, it is not pathological, so you can enable them with confidence on production systems.
The lockstat provider makes available probes that correspond to the different synchronization primitives in Solaris; these primitives and the probes that correspond to them are discussed in Section 10.6.4. The provider probes are as follows: Adaptive lock probes. The four lockstat probes are adaptive-acquire, adaptive-block, adaptive-spin, and adaptive-release. They are shown for reference in Table 10.7. For each probe, arg0 contains a pointer to the kmutex_t structure that represents the adaptive lock. Adaptive locks are much more common than spin locks. The following script displays totals for both lock types to provide data to support this observation. lockstat:::adaptive-acquire /execname == "date"/ { @locks["adaptive"] = count(); } lockstat:::spin-acquire /execname == "date"/ { @locks["spin"] = count(); } If we run this script in one window and run a date(1) command in another, then when we terminate the DTrace script, we see the following output. # dtrace -s ./whatlock.d dtrace: script './whatlock.d' matched 5 probes ^C spin 26 adaptive 2981 As this output indicates, over 99% of the locks acquired from running the date command are adaptive locks. It may be surprising that so many locks are acquired in doing something as simple as retrieving a date. The large number of locks is a natural artifact of the fine-grained locking required of an extremely scalable system like the Solaris kernel. Spin lock probes. The three probes pertaining to spin locks are spin-acquire, spin-spin, and spin-release. They are shown in Table 10.8. Thread locks. Thread lock hold events are available as spin lock hold-event probes (that is, spin-acquire and spin-release), but contention events have their own probe (thread-spin) specific to thread locks. The thread lock hold-event probe is described in Table 10.9. Readers/writer lock probes. The probes pertaining to readers/writer locks are rw-acquire, rw-block, rw-upgrade, rw-downgrade, rw-release. They are shown in Table 10.10. For each probe, arg0 contains a pointer to the krwlock_t structure that represents the adaptive lock.
|
