Enabling efficient OS paging for main-memory OLTP databases

Abstract

Even though main memory is becoming large enough to fit most OLTP databases, it may not always be the best option. OLTP workloads typically exhibit skewed access patterns where some records are hot (frequently accessed) but many records are cold (infrequently or never accessed). Therefore, it is more economical to store the coldest records on a fast secondary storage device such as a solid-state disk. However, main-memory DBMS have no knowledge of secondary storage, while traditional disk-based databases, designed for workloads where data resides on HDD, introduce too much overhead for the common case where the working set is memory resident.In this paper, we propose a simple and low-overhead technique that enables main-memory databases to e ciently migrate cold data to secondary storage by relying on the OS's virtual memory paging mechanism. We propose to log accesses at the tuple level, process the access traces o✏ine to identify relevant access patterns, and then transparently re-organize the in-memory data structures to reduce paging I/O and improve hit rates. The hot/cold data separation is performed on demand and incrementally through careful memory management, without any change to the underlying data structures. We validate experimentally the data re-organization proposal and show that OS paging can be efficient: a TPC-C database can grow two orders of magnitude larger than the available memory size without a noticeable impact on performance.

In-Memory Big Data Management and Processing: A Survey

“…Data overflow. In general, approaches to the data overflow problem can be classified into three categories: user-space (e.g., H-Store Anti-caching [133], Hekaton Siberia [134]), kernel-space (e.g., OS Swap, MongoDB memory mapped files [65]) and the hybrid (e.g., Efficient OS Paging [136] and UVMM [138]). The semantics-aware user-space approaches can make more effective decision on the paging strategies, while the hardware-conscious and well-developed kernel-space approaches are able to utilize the I/O efficiency brought by the OS during swapping.…”

“…The semantics-aware user-space approaches can make more effective decision on the paging strategies, while the hardware-conscious and well-developed kernel-space approaches are able to utilize the I/O efficiency brought by the OS during swapping. Potentially, both the semantics-aware paging strategy and hardware-conscious I/O management can be exploited to boost the performance [136], [138]. In addition to the above, hardware solutions are being increasingly exploited for performance gain.…”

“…Alternatively, as in the traditional database systems, effective eviction mechanisms could be adopted to replace the in-memory data when the main memory is not sufficient. The authors of [133], [134], [157] propose to move cold data to disks, and [136] re-organizes the data in memory and relies on OS to do the paging, while [137] introduces pointer swizzling in database buffer pool management to alleviate the overhead caused by traditional databases in order to compete with the completely re-designed in-memory databases. UVMM [138] taps onto a hybrid of hardwareassisted and semantics-aware access tracking, and non-blocking kernel I/O scheduler, to facilitate efficient memory management.…”

In-memory performance for big data

“…Stoica and Ailamaki profiled the performance of the stateof-the-art in-memory VoltDB database, and found that performance dropped precipitously when the working data set exceeded available memory [37]. Their work demonstrated that by intelligently controlling which tuples are swapped out by the operating system and which are kept in memory, it is possible to make much more effective use of available memory.…”

“…Unfortunately, there are no mechanisms for asynchronous read-ahead and for writing multiple pages concurrently, i.e., multiple msync calls execute serially. As observed by [37], without extensive explicit control, the virtual memory manager may swap out hot data along with the cold. Our experiments in Section 5 demonstrate this performance penalty.…”