-none- 2004-04-28 - By -not available-
-CPU time almost unchanged=20
-a huge change in the Total Wait Time (cs) for the following events (the
number of waits were all within an order of 2 of each other except for la=
tch
free which jumped from 200 to 150,000).
NAME TIME-initial (cs) TIME-fi=
nal
(cs)=20
latch free 200
2,800,000=20
enqueue 900
280,000=20
global cache lock busy 8,200 30,000=20
library cache pin 500 18,00=
0=20
row cache lock 600 15,000=
=20
library cache lock 600 8,000=
=20
DFS lock handle 30 5,000=20
PX Deq: Execution Msg -- 5,000=20
-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 increas=
ed
by ~x10.
For the 10046 traces (taken a few weeks ago) I had a chance to look throu=
gh
a few of the multitude before they were deleted.=20
-Lots of latch free:library cache, shared pool, and row cache object wait=
s.
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 instan=
ce
lock enqueue.
My working model is that the latch free (library cache) waits are a sympt=
om.
Something is holding a library cache pin/lock and another process wants i=
t.
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.=20
|
|
