You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
As you might expect, mutexes are expected to perform the pinning operation much more quickly than latches can do pinning. A quick test showed mutex pinning is significantly faster than latch pinning. For this test, a simple Oracle Database 10g Release 2 one-table SQL statement cursor was repeatedly opened and closed 500,000 times in a very tight PL/SQL loop by a single session. The database server contained a single four-core CPU. This test was repeated 30 times and the wall clock time recorded. The hidden instance parameter _kks_use_mutex_pin (a setting of true enables mutexes when supported) determined if mutexes were used instead of library cache latches.
With mutexes disabled, both the library cache and the library cache pin latches were very active. However, with mutexes enabled, neither latch had any activity (that is, latch gets were zero)! With mutexes disabled and the library cache latches enabled, the average test took 20.00 s +/- 1.07 s, 95% of the time. With mutexes enabled and the library cache latches disabled, the average test took 19.90 s +/- 0.98 s, 95% of the time. While the difference may seem irrelevant, statistically, they are indeed very different. Even at a 95% confidence level, this test indicates mutexes did indeed improve performance. Also keep in mind that this is a simple, single-session cursor open and close test. We would expect mutex performance to be even more pronounced in a high-concurrency test.
So, I created a high-concurrency mutex experiment. The situation was similar to the single-process test, except now five sessions were involved, the cursor was opened and closed 200,000 instead of 500,000 times, and 6 samples were taken instead of 30 samples. The clock started when the first process began and stopped when all five processes completed their 200,000 cursor open and close loops. With mutexes disabled and the library cache latches enabled, the average test took 468.0 s +/- 14.7 s, 95% of the time. With mutexes enabled and the library cache latches disabled, the average test took 418.1 s +/- 7.4 s, 95% of the time. Mutexes reduced the test time by an incredible 11%. Statistically speaking, the performance difference is significant indeed! Also the mutex test times were less variable then standard latching, which means mutex usage will result in more consistent performance. As we hoped and expected, mutexes significantly improved cursor pinning performance.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|