QDS_ASYNC_QUEUE is recorded when a thread waits for access to the queue of Query Store information that is being asynchronously persisted to disk. Query Store collects runtime stats in memory and stages them through this queue for background writing; the wait is the coordination around that staging.
Third member of the Query Store background trio, alongside QDS_PERSIST_TASK_MAIN_LOOP_SLEEP and QDS_SHUTDOWN_QUEUE.
Is It a Problem?
No; it has not been a contention point and is filtered as benign. Like its siblings, it accumulates wherever Query Store is enabled, which on modern versions and Azure SQL Database means practically everywhere, and its totals say nothing about Query Store overhead or health.
Query Store trouble has better witnesses: sys.database_query_store_options for state and size, and forced-plan or capture-mode issues visible in the Query Store views themselves.
Common Causes
- Query Store enabled, with runtime stats flowing through the async persistence queue.
- Many QS-enabled databases multiplying the background machinery.
What To Do
- Filter it out with the other
QDS_*background waits; ourGet-WaitStatisticsscript does. - Check per-database Query Store health via the options DMV when that is the actual question.
- Leave capture and flush settings alone on account of this wait; it does not measure their cost.
How To See It
Rank waits with Get-WaitStatistics, where it is filtered as Query Store background noise.
Part of the SQL Server Wait Types Library.
Related deep dive: IO_COMPLETION Wait Type.
Leave a Reply