marcingminski
commented
1 year ago Thanks, this doesn’t sound like an issue as such, just a matter of adding the wait exclusion, which is configurable. For others to benefit from your findings, are you able to submit this as a PR?
Thanks
hvoges
Did you check DOCS to make sure there is no workaround? https://sqlwatch.io/docs/
Describe the bug SQLWatch shows incredible High Waits (>20000)
To Reproduce Steps to reproduce the behavior: This behaviour shows on an always on Instance with quite a few replicas. The Server has no performance issues. As far as I could reproduce the results, it seems the wait-query does not exclude the Default HADR-Wait-Types, especially HADR_WorkQueue and HADR_NOTIFICATION_DEQUEUE. According to sys_dm_os_wait_stats, these are expected waits: HADR_Work_Queue: This is an expected wait when there are ready workers waiting for new work, which is the normal state HADR_NOTIFICATION_DEQUE: A background task that processes Windows Server Failover Clustering notifications is waiting for the next notification. Internal use only. When I exclude these two, the result of the query in usp_sqlwatch_logger_requests_and_sessions.sql drops from >20000 to ~500, but there may be more exptected Waiting-tasks that can be excluded.
Expected behavior These Events should be included in dbo.sqlwatch_config_exclude_wait_stats.
Screenshots If applicable, add screenshots to help explain your problem.
Windows Server (please complete the following information):
SQL Server (please complete the following information):
SQL Server Management Studio (SSMS -> about -> copy info):
SQLWATCH version (from DACPAC or from sysinstances)
Additional context Add any other context about the problem here.