Optimizing Buffer Pool Memory Management in TDSQL-C Serverless

Buffer Pool Memory Management

TDSQL-C Serverless separates compute and storage, offering PB‑scale storage on demand, while its Serverless compute layer automatically starts, stops, and scales based on actual database load, charging only for usage. The compute resources (CCU) consist of CPU and memory, where memory is primarily used by the Buffer Pool to cache user data.

Buffer Pool Organization

InnoDB splits the Buffer Pool into multiple Buffer Pool Instances to reduce lock contention. Each instance contains several equal‑sized chunks, the smallest allocation unit. Pages (16 KB) are stored in frames within blocks, which are managed by free and LRU lists.

Buffer Pool Resize

MySQL supports dynamic Buffer Pool resize via the innodb_buffer_pool_size system variable. The resize runs in the background; subsequent changes are ignored until completion. Progress can be monitored via error logs or the Innodb_buffer_pool_resize_status variable.

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

During expansion, new chunks are allocated, blocks and frames are initialized, and blocks are added to the free list. During contraction, blocks must be reclaimed from both free and LRU lists, moved to a withdraw list, and finally released.

/* cap scan_depth with current LRU size. */
scan_depth = ut_min(ut_max(buf_pool->withdraw_target -
                       UT_LIST_GET_LEN(buf_pool->withdraw),
                       static_cast
(srv_LRU_scan_depth)),
                       lru_len);
mutex_exit(&buf_pool->free_list_mutex);
buf_flush_do_batch(buf_pool, BUF_FLUSH_LRU, scan_depth, 0, &n_flushed);
buf_flush_wait_batch_end(buf_pool, BUF_FLUSH_LRU);

Bottleneck Analysis and Solutions

IO Bottleneck

In MySQL 8.0, contraction is limited by flushing the LRU list, which requires dirty page writes and frequent LRU mutex acquisition, causing latency spikes. TDSQL-C avoids this by generating pages asynchronously from redo logs, eliminating the need for dirty page flushes.

Free/LRU List Mutex Bottleneck

Traversing the free and LRU lists holds their mutexes, blocking user threads. The O(N) traversal (N = number of blocks) can cause noticeable stalls.

Global Lock Bottleneck

Resize operations also need a global Buffer Pool lock, during which the pool is unavailable. The most time‑consuming steps are chunk memory reclamation, chunk allocation, and hash table resizing, especially when the pool size changes dramatically.

Optimization Strategies

Reducing Lock Scope

Instead of scanning entire lists, iterate only over blocks within the chunks being reclaimed, acquiring mutexes per‑block rather than per‑list.

Pre‑allocation of Chunks

Allocate and initialize chunks and their blocks before acquiring the global lock, store them in a temporary free list, then merge the list into the Buffer Pool in O(1) time.

Delayed Release of Chunks

Move chunks to a temporary container while holding the lock, release the lock, and free the chunks afterward, reducing lock hold time.

Resize Hash Optimization

Resize hash tables only when necessary, using configurable thresholds to avoid frequent rehashing; more advanced solutions could involve lock‑free or consistent hashing.

Optimization Effects

Benchmarks with sysbench oltp_read_only (long_query_time=0.1) show that after applying the optimizations, slow‑query spikes disappear during expansion and contraction, indicating a more stable serverless scaling behavior.