WAITFOR_PER_QUEUE is recorded when a Service Broker worker thread waits for a message on a specific queue as part of an activation procedure’s WAITFOR (RECEIVE ...). Each wait runs up to the statement’s timeout, or 60 seconds when none is specified, then the loop typically re-issues the receive.
It is the queue-scoped cousin of BROKER_RECEIVE_WAITFOR, and normal furniture in any environment using Broker activation.
Is It a Problem?
No; blocked receives on empty queues are exactly how activation readers are meant to idle, and the wait accumulates in timeout-sized increments while queues are quiet. Filter it.
Activation health has its own checkpoints when questions arise: whether activated procedures are erroring (error log), whether messages arrive but sit unprocessed (queue depth via sys.transmission_queue and the queues themselves), and whether MAX_QUEUE_READERS matches the arrival rate.
Common Causes
- Activation procedures blocked on
WAITFOR (RECEIVE)against quiet queues. - Timeout-and-retry loops accumulating waits in 60-second default increments.
What To Do
- Filter it out of wait analysis.
- Verify activation configuration when Broker processing lags: readers, errors, and queue depths tell the real story.
How To See It
Rank waits with Get-WaitStatistics; expect it wherever Broker activation runs, meaning only that readers are standing by.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply