-none- 2004-04-27 - By -not available-
NAME TIME-initial (cs) TIME-final (cs)
latch free 200 2,800,000
enqueue 900 280,000
global cache lock busy 8,200 30,000
library cache pin 500 18,000
row cache lock 600 15,000
library cache lock 600 8,000
DFS lock handle 30 5,000
PX Deq: Execution Msg -- 5,000
-latch sleeps skyrocketed for library cache, shared pool, and row cache objects with many having at least 4 sleeps. The 'dlm resource hash list ' latch had about the same number of sleeps, but the number of gets increased by ~x10.
For the 10046 traces (taken a few weeks ago) I had a chance to look through a few of the multitude before they were deleted.
-Lots of latch free:library cache, shared pool, and row cache object waits. The library cache wait always pointed to the same address (the same 1 of 5 children).
-Increase in library cache lock and library cache pin. These are pointing to the same handle address. Also an increase in the library cache pin instance lock enqueue.
My working model is that the latch free (library cache) waits are a symptom. Something is holding a library cache pin/lock and another process wants it. Get a latch. Someone else wants it. Latch contention. Latch contention builds. Spin, sleep, another process, more latch contention, ... Take a systemstate dump to see what is happening.
|
|
