Are You Sure You Want to Use MMAP in Your Database Management System?

Memory-mapped (MMAP) file I/O is an OS-provided feature that maps the contents of a file on secondary storage into a program’s address space. The program then accesses pages via pointers as if the file resided entirely in memory. The OS transparently loads pages only when the program references them and automatically evicts pages if memory fills up.

MMAP‘s perceived ease of use has seduced database management system (DBMS) developers for decades as a viable alternative to implementing a buffer pool. There are, however, severe correctness and performance issues with MMAP that are not immediately apparent. Such problems make it difficult, if not impossible, to use MMAP correctly and efficiently in a modern DBMS. In fact, several popular DBMSs initially used MMAP to support larger-than-memory databases but soon encountered these hidden perils, forcing them to switch to managing file I/O themselves after significant engineering costs.

In this way, MMAP and DBMSs are like coffee and spicy food: an unfortunate combination that becomes obvious after the fact.

Since developers keep trying to use MMAP in new DBMSs, we wrote this paper to provide a warning to others that MMAP is not a suitable replacement for a traditional buffer pool. We discuss the main shortcomings of MMAP in detail, and our experimental analysis demonstrates clear performance limitations. Based on these findings, we conclude with a prescription for when DBMS developers might consider using MMAP for file I/O.

Recommended Music for this Paper:
Dr. Dre – High Powered (featuring RBX)