Recently we got an email asking for help from a DBA who was concerned about a high percentage of the PREEMPTIVE_DEBUG wait on a SQL Server. They were investigating poor performance and had searched the internet high and low and not found information on what this wait means. They were stumped.
What to Do When You Find an Unusual Wait
We have a lot of tools to explore and learn things ourselves in SQL Server. Even when you find results explaining something on the internet (like this one!) it’s always good to use those tools to explore yourself and learn.
But first, don’t panic! Just because a wait is a high percentage doesn’t necessarily mean it’s a problem. For any wait…
- Narrow in and find out when the wait occurs, and how much of it there is. Just because it’s a top wait by percentage doesn’t mean it’s always a problem. The server could be bored.
- If it actually is a problem, identify what’s running when the wait occurs.
- Blog about it! Help others.
But what is the PREEMPTIVE_DEBUG wait, anyway?
I had a guess as to what this wait type meant, so I did a quick test to verify. In one SQL Server Session, I ran our sp_BlitzFirst procedure to take a 10 second sample of waits:
|
1 2 |
exec sp_BlitzFirst @ExpertMode=1, @Seconds=10; GO |
In another session, I ran the built in procedure sp_spaceused, but ran it with the “Debug” button at the top of SSMS and started stepping into the code. (I just picked that procedure randomly.)
Here’s a screenshot of what I saw when sp_BlitzFirst® completed:
Success! The PREEMPTIVE_DEBUG wait is related to using debugging tools to step through code. When you’re stepping through something the SQL Server has to wait for you to say “go on”.
My guess is that this probably isn’t specific to only the debugging tool built into SQL Server Management Studio itself. Developers can use other debugging tools when working with Visual Studio or Windbg, and I bet they all produce this wait.
What to Do if You See PREEMPTIVE_DEBUG
The list I have above still applies– do a quick assessment of how much of the wait there is. But I’d also start asking some friendly questions of folks about whether they use debugging tools against production often– and if you can maybe give them a fresh database backup in a development environment where they can debug safely, away from your customers!
2 Comments. Leave new
Interesting, I’ve not run into this one. Would you generally consider PREEMPTIVE_DEBUG to be a “problem” wait? In the same sense that a WAITFOR wait is not really a problem, it’s just a description of why something is waiting. I guess if that person debugging is holding locks and causing blocking type waits, but then it would be the LCK_ waits that would actually indicate a problem, right?
Although if it’s production and devs are debugging on it, it’s probably time to unsheath the scimitars…errr, I mean…redirect them to an appropriate environment to do that sort of development work.
I haven’t run into it in large amounts either.
Some debugging activities will freeze up the entire process. But I didn’t test what waits show up with a kernel debugger in this post and if it’s the same wait. If any readers happen to know offhand, I’m kind of curious– but not actually curious enough to break out a debugger right now since I’m in the midst of some things 🙂