I’ve been trying to find out if the same CPU limitations database mirroring has apply to Availability Groups. My guess is that the same limitations exists, given that Availability Groups was built on the same technology as Mirroring, so the following would still apply.

  • Principal server: 1 global thread and 2 threads per each of the mirrored databases.
  • Mirror server: – 64 bit architectures: 1 global thread, 2 threads per mirrored databases and one additional thread for each mirrored database for every 4 processor cores.

Is this correct? Thank you!

1 Answer 1


This is documented here on BOL: Thread Usage By Availability Groups. For redundancy purposes, here is the breakdown:

  • 3 to 10 shared threads (but can increase depending on primary replica workload)
  • (primary replica) 1 log capture thread per primary database
  • (primary replica) 1 log send thread per secondary database
  • (secondary replica) 1 redo thread for each secondary database
  • (secondary replica) during a backup, holds a thread on the primary replica for the duration of the backup

Other points to consider:

  • There is a shared pool of threads for hadr, and this is the max number of threads except 40 (so hadr worker thread pool could take a significant amount of threads)
  • Idle threads (about 15 seconds of idle-ness) can be released back to the pool

Other references:

AlwaysON - HADRON Learning Series: Worker Pool Usage for HADRON Enabled Databases

Monitoring SQL Server 2012 AlwaysOn Availability Groups Worker Thread Consumption

  • Thank you Thomas! This is exactly what I was looking for...feeling embarrassed now for not seeing it on BOL :| Commented Apr 7, 2015 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.