Second-level buffer cache management

TLDR: This work investigates multiple approaches to effectively manage second-level buffer caches and reports a new local algorithm called multi-queue (MQ) that performs better than nine tested alternative algorithms for second-levels buffer caches, and a set of global algorithms that manage a multilevel buffer cache hierarchy globally and significantly improve second- level buffer cache hit ratios over corresponding local algorithms.

Abstract: Buffer caches are commonly used in servers to reduce the number of slow disk accesses or network messages. These buffer caches form a multilevel buffer cache hierarchy. In such a hierarchy, second-level buffer caches have different access patterns from first-level buffer caches because accesses to a second-level are actually misses from a first-level. Therefore, commonly used cache management algorithms such as the least recently used (LRU) replacement algorithm that work well for single-level buffer caches may not work well for second-level. We investigate multiple approaches to effectively manage second-level buffer caches. In particular, we report our research results in 1) second-level buffer cache access pattern characterization, 2) a new local algorithm called multi-queue (MQ) that performs better than nine tested alternative algorithms for second-level buffer caches, 3) a set of global algorithms that manage a multilevel buffer cache hierarchy globally and significantly improve second-level buffer cache hit ratios over corresponding local algorithms, and 4) implementation and evaluation of these algorithms in a real storage system connected with commercial database servers (Microsoft SQL server and Oracle) running industrial-strength online transaction processing benchmarks.

Figures

Fig. 6. Global LRU algorithm.

Fig. 6. Global LRU algorithm.

Fig. 10. Cache hit ratios for (a) MS-SQL-Small and (b) Auspex.

Fig. 1. An example of a multilevel buffer cache hierarchy.

Fig. 7. Client Content Tracking (CCT) table (notation: (disk1, bno1) uniquely identifies a recently evicted block).

Fig. 8. Comparison with the ARC and LIRS algorithms. (a) HP Disk Trace and (b) Auspex Server Trace.

Frequently asked questions

Q1. What are the contributions mentioned in the paper "Second-level buffer cache management" ?

This paper investigates multiple approaches to effectively manage second-level buffer caches. 

Q2. What is the impact of reducing cache hit ratios?

Storage buffer cache hit ratios (%).reload threshold value increases, the number of reloads issignificantly reduced, leading to less contention on disks. 

Q3. How long is the access latency for random read/writes?

The bandwidth of data transfers between disk and host memory is about 15 Mbytes/sec and the access latency for random read/writes is about 9 milliseconds. 

Q4. How many kbytes are used for the access pattern analysis?

In their study, the authors use 8 Kbytes as the cache block size for their access pattern analysis and their experimental evaluation of various algorithms. 

Q5. What is the first method to demote a block?

Since an L1 buffer cache evicts a clean block to make space for a new block, the first method needs to demote (send) the evicted block to an L2 buffer cache before replacing it. 

Q6. What is the advantage of using a data structure called client content tracking (CCT) table?

An L2 buffer cache can use a data structure called client content tracking (CCT) table to record current disk blocks (diskID; blockNo) that reside in different memory location of an L1 buffer cache. 

Q7. How many blocks are in the history buffer?

Each entry of the history buffer occupies fewer than 32 bytes so that the memory requirement for the history buffer is quite small, less than 0.5 percent of the L2 buffer cache size. 

Q8. How does MQ remember access frequencies of recently evicted blocks?

MQ also uses a history buffer Qout, similarly to the 2Q algorithm [20], to remember access frequencies of recently evictedblocks for someperiodof time. 

Q9. What is the way to divide an L2 buffer cache into multiple partitions?

If different L1s access different data (which is typically the case in parallel databases such as Microsoft SQL Server), one method is to divide an L2 buffer cache into multiple partitions, one for each L1. 

Q10. How many MBytes of Oracle buffer is used to collect the trace?

The first trace is collected by setting the Oracle buffer cache to be 128 MBytes, whereas the latter is collected with 16 MBytes of Oracle buffer cache. 

Q11. What is the difference between the access percentage curves for all four traces?

For all four traces, the access percentage curves decrease more slowly than the block percentage curves, indicating that a large percentage of accesses are to a small percentage of blocks. 

Q12. Why did Willick et al. not study disk cache access patterns?

Another study conducted by Willick et al. demonstrated that the Frequency-Based Replacement (FBR) algorithm performs better for a back-end disk caches than locality-based replacement algorithms such as LRU [47], but this study did not study disk cache access patterns to understand their results. 

Q13. What are the common types of cache replacement policies?

Cache replacement policies have been intensively studied in various contexts in the past, including processor caches [40], paged virtual memory systems [42], [6], and disk caches [41]. 

Q14. How does the performance of a local replacement algorithm at L2 buffer caches differ from other?

The performance of a local replacement algorithm at L2 buffer caches primarily depends on how well they can satisfy the life time property.