The LOGPOOL_* waits all belong to one structure, so this page covers the family: LOGPOOL_CACHESIZE, LOGPOOL_CONSUMER, LOGPOOL_CONSUMERSET, LOGPOOL_FREEPOOLS, and LOGPOOL_REPLACEMENTSET.
The log pool is an in-memory cache of recently flushed log blocks. Its purpose: log readers, the components that consume the transaction log after it is written, can read recent log from memory instead of issuing physical reads against the log file. Availability Group capture threads sending log to asynchronous replicas are the headline customer; CDC and replication log readers benefit from the same idea. The individual wait names cover threads synchronising on the pool’s different internal pieces (its sizing, consumer lists, free pools, and replacement machinery).
Are They a Problem?
No; none of the family has been a noticeable contention point. Their presence mostly documents that log readers are active on the instance, AGs, CDC, replication, and the amounts stay small relative to the real log waits.
If log readers are actually struggling, it shows up in their own metrics: AG send queues growing, CDC latency climbing, replication log reader agent lag. The pool waits stay incidental even then; a reader falling behind the pool’s retention simply drops to physical log reads (which is a performance cost, but one visible as I/O, not as LOGPOOL_* waits).
What To Do
- Filter the family out of wait analysis.
- Judge log readers by their own health:
log_send_queue_sizefor AGs,sys.dm_cdc_log_scan_sessionsfor CDC, agent latency for replication. - Nothing in the log pool itself is user-tunable in a supported way.
How To See It
Rank waits with Get-WaitStatistics; any LOGPOOL_* entries are background traces from log-reading features doing their jobs.
Part of the SQL Server Wait Types Library.
Related deep dive: WRITELOG Wait Type.
Leave a Reply