Disclaimer: This is work in progress intended to consolidate information from various sources (some unfortunately not available anymore).
Buffer Pool [aka BP, BPool]
- main memory component in SQL Server [2]
- ⇐ preferred memory allocator for the whole server [1]
- ⇐ the biggest consumer of SQL Server
- area of memory that SQL Server used to store
- cached data (aka data pages)
- cached execution plans
- algebrizer trees for views, constraints and defaults
- lock memory
- ⇐ anything with a non-zero value in sys.dm_os_memory_clerks.single_pages_kb
- ⇐ caching data in the buffer pool reduces the load on the I/O subsystem and improves performance [6]
- ⇐ all pages must be copied into the buffer pool before they can be used in a query
- ⇒ it is needed to scan the buffer pool for a number of operations [3]
- single-page allocator
- it commits and decommits memory blocks of 8KB granularity only
- manages disk I/O functions for bringing data and index pages into the data cache so data can be shared among users [2]
- all memory not used by another memory component remains in the buffer pool to be used as a data cache for pages read in from the database files on disk [2]
- when other components require memory, they can request a buffer from the buffer pool [2]
- most of the buffers taken from the buffer pool for other memory components go to other kinds of memory caches [2]
- ⇐ they can only get blocks of 8KB in size [1]
- these blocks are not continues in memory[1]
- allocation for large buffers will be satisfied by memory node's multi-page allocator or by virtual allocator [1]
- ⇒ memory will be allocated outside of Buffer Pool [1]
- BP can be used as underneath memory manager for SQL Server components as long as they allocate buffers of 8KB [1]
- pages allocated from BP are referred as stolen[1]
- first decides how much of VAS it needs to reserve for its usage (aka target memory)
- decision based on internal memory requirements and external memory state
- it calculates its target amount of memory it thinks it should commit before it can get into memory pressure [1]
- ⇐ to keep the system out of paging the target memory is constantly recalculated [1]
- {restriction} the target memory can't exceed max memory that represents max server memory settings [1]
- even if the min server memory equals the max server memory BP commits its memory on demand [1]
- ⇐ monitor the corresponding profiler event to observe this behavior [1]
- reserves all of it right a way
- ⇐ check monitor SQL Server's virtual bytes from perfmon or use vasummary view to observe this behavior
- ⇐ normally can't get all the needed memory in one region
- ⇒ several large regions reserved ← by design behavior
- commits pages on demand
- during startup the memory manager configures BP to be SQLOS's single page allocator
- from that point on all dynamic single page allocations are provided by BP[1]
- has its own memory clerk
- is leveraged to respond to external and VAS memory pressure only [47]
- leverages only Virtual and AWE SQLOS's interfaces
- never uses any type of page allocator from SQLOS [1]
- {operation} dropping buffers
- likely results in some degree of performance degradation
- ⇐ any subsequent query executions will have to reread the data from the database files increasing I/O
- via: DBCC DROPCLEANBUFFERS
- {concept} page
- the fundamental unit of data storage in SQL Server
- {concept} buffer
- page in memory that's the same size as a data or index page [2]
- ⇐ page frame that can hold one page from a database [2]
- {concept} buffer pool scan
- common internal operation that iterates through the entire buffer descriptor array to find any buffers that belong to a specific database [3]
- [<SQL Server 2022] serial operation
- on large memory machines operations that require scanning the buffer pool can be slow [3]
- ⇐ the larger the machine, the greater the impact
- ⇐ it doesn’t necessarily matter about the size of the operation [3]
- [SQL Server 2022] {feature}Buffer Pool Parallel Scan
- parallelized by utilizing multiple cores
- adds processing power to scan the buffer pool more efficiently [3]
- ⇐ benefits both small and large database operations on larger memory machines
- 10-30x improvement in executions
- customers running mission-critical OLTP, hosted service providers, and data warehouse environments will witness the most improvements in overall processing speed [3]
- uses one task per 8 million buffers (64 GB)
- ⇐ a serial scan will still be used if there are less than 8 million buffers [3]
- uses buffer pool scan diagnostics to improve supportability and insights with new buffer pool scan events [3]
- can significantly improve the performance of database workloads
- operations benefiting from it
- database startup/shutdown
- creating a new database
- file drop operations
- backup/restore operations
- Always On failover events
- DBCC CHECKDB and DBCC Check Table
- log restore operations
- other internal operations (e.g., checkpoint)
[1] Slava Oaks (2005) SQLOS's memory manager and SQL Server's Buffer Pool (link) [something similar seems to be available here]
[2] Kalen Delaney (2006) Inside Microsoft® SQL Server™ 2005: The Storage Engine
[3] Microsoft SQL Server Blog (2022) Improve scalability with Buffer Pool Parallel Scan in SQL Server 2022, by David Pless (link)
[4] Microsoft learn (2022) Operations that trigger a buffer pool scan may run slowly on large-memory computers (link)