Economy Of Waits
There’s a joke about two economists walking down the street.
One of them asks the other how they’re doing.
The punchline is that their response is “compared to what?”
It’s not the best joke, and it’s something to keep in mind when you’re measuring anything, but SQL Server specifically.
This isn’t a post about collecting baselines, though it’s a relevant concept.
One of the best ways to find bottlenecks in SQL Server is to look at wait stats.
Lots of scripts and monitoring tools will show you top waits, percentages, signal waits, and even percentages of signal waits.
Oh baby, those datapoints.
But there’s frequently a missing axis: compared to what?
Let’s say you’ve got 604,800 seconds of CX packet waits.
Let’s also say they’re 95% of your total server wait stats.
How does your opinion of that number change if your server has been up for:
- One Day (86,400 seconds)
- One Week (604,800 seconds)
- One Month (2,592,000 seconds)
- One Year (31,536,000 seconds)
Obviously, if your server has been up for a day, you might wanna pay more attention to that metric.
If your server has been up for two weeks, it becomes less of an issue.
Seven Year Abs
I’ll give you another example: OH MY GOD YOU ATE 20,000 CALORIES.
- In a day, that might be cause for concern
- In a week, you’re about average
- In a month, you might need medical attention
- In a year, well, you’re probably more calorically important to worms
Compared to what is a pretty important measure.
I get it. Someone can clear out wait stats, and judging uptime can be unreliable, and more difficult up in the cloud.
Looking at wait stats without knowing the period of time they were collected over isn’t terribly helpful.
I’d opened an issue to at least separate wait stats by database, though Microsoft doesn’t seem to be too into my idea.
Thanks for reading!