Expand wait_time_percent_of_uptime to accomodate >1,000% waits#585
Merged
erikdarlingdata merged 1 commit intoerikdarlingdata:devfrom Apr 24, 2025
Merged
Expand wait_time_percent_of_uptime to accomodate >1,000% waits#585erikdarlingdata merged 1 commit intoerikdarlingdata:devfrom
erikdarlingdata merged 1 commit intoerikdarlingdata:devfrom
Conversation
erikdarlingdata
added
bug
Owner
|
@ChrisMayIVCE You can totally have wait stats that are higher than uptime. It happens a lot particularly on servers where there's a lot of parallelism. Multiple cores emitting waits simultaneously can really add up. This is a pretty minimal change so I'm happy to push it on through. Thanks for the assist here! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi Erik, love the new proc but I am getting some arithmetic errors in the block starting on line 1928 (the update on #wait_stats). This is ultimately due to having >1000% wait times as a percentage of server uptime:
I am not sure if this is a bug in the DMVs or accurate reporting, but this is from an Azure SQL Managed Instance being utilised as a data warehouse and this fix resolved the issue and now they appear as priority 20 results.
Can adjust how this is done if you would prefer, please let me know your thoughts