Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
sp_Blitz and sp_BlitzFirst: add warning about high USERSTORE_TOKENPERM cache size #2134
Back when I wrote this check in, I apparently tacked it onto the warning about the plan cache being erased recently. I feel like that could easily get missed since the message for it is already pretty long.
If you look here, the code is already written to get the size.
The question is: is this important enough to be its own check?
If so, is 2 GB the right size to warn at?
"... is 2 GB the right size to warn at?"
Tough one. If it's 2 GB of 4 GB in total, then I'm interested for sure. If it's 2 GB of 256 GB, then probably not so much.
Is it worth pulling in from SQL OS how much memory is available for all memory caches to fight over to see if USERSTORE_TOKENPERM is using a lot more than its fair share of the available space?
Looking at this post from Bulent Ozkir), and this thread on SQL Server Central gives me a few ideas of variations on this theme to point out different reasons why USERSTORE_TOKENPERM has blown out of proportion. Perhaps there's a new group of checks here?
Yeah, I'll tackle it. I've got a client fighting this issue, and I'm pretty sure there's a bug in SQL Server around it. They have a Microsoft support call open, and we're still trying to track it down.
I just ran a quick analysis on the SQL ConstantCare data. There's a good chunk of the population where the USERSTORE_TOKENPERM cache size is >20% of the buffer pool. Unfortunately, sys.dm_os_memory_clerks is one of the larger tables we have in SQL ConstantCare (because I didn't do the right filtering in early exe versions), so the queries take a heck of a long time. (Like, an hour or more.) We just rolled out a newer version of the exe that won't gather as much data, so I should be able to start analyzing this faster. I wanna try to figure out if it correlates with a particular build or version - I'm seeing it on 2016 and 2017 for sure.
For now, I'm guessing we'll flag it at 10% or more of the buffer pool (to help catch the worst offenders) and get the dialog going. I'll code that for the March release - if anybody has input, holler.