> I would take a look at monCachedProcedures and see how many plans per proc
> are there and how much proc cache they consume/how long in cache
Is this the correct way of looking at it ?
select ObjectName, count(*), sum(MemUsageKB), min(CompileDate)
from monCachedProcedures
group by ObjectName
order by 3
We have some procs will 300 entries. Some procs which are rather too long (and are being re-written) take up a lot of space
eg
StatCompPeer 277 308578 Dec 7 2015 11:15PM
We have 30,037 entries in monCachedProcedures (but this looks to be ever increasing)
11,321 are stored proc entries (total space = 4,494 Mb)
18,718 are *ss* statement entries (total space = 837Mb)
We currently bounce the server weekly so nothing is more than 7 days old in the cache.
What causes entries to get thrown out the procedure cache ? I've got procedure cache entries showing from 5th Dec after the server reboot.
> You can also check the proc logic.....if creating an index on a #temp table
> (which would cause sort buffer usage), make sure the index is truly needed
When I find these I'm removing them - especially as we were getting hit with contention on the procedure cache due to unnecessary recompiles.
BTW, Each row has a unique PlanID
select ObjectName, PlanID, count(*)
from monCachedProcedures
group by ObjectName, PlanID
having count(*) > 1
order by 3
shows no rows - Is this correct ?
And many entries have zero ExecutionCount - is this normal ?