RESYSTANCE: Unleashing Hidden Performance of Compaction in LSM-trees via eBPF

TL;DR

RESYSTANCE is proposed, which leverages eBPF and io_uring to free compaction from system calls and unlock hidden performance potential and significantly reduces software stack overhead by handling compaction directly inside the kernel through eBPF.

Abstract

The development of high-speed storage devices such as NVMe SSDs has shifted the primary I/O bottleneck from hardware to software. Modern database systems also rely on kernel-based I/O paths, where frequent system call invocations and kernel-user space transitions lead to relatively large overheads and performance degradation. This issue is particularly pronounced in Log-Structured Merge-tree (LSM-tree)-based NoSQL databases. We identified that, in particular, the background compaction process generates a large number of read system calls, causing significant overhead. To address this problem, we propose RESYSTANCE, which leverages eBPF and io_uring to free compaction from system calls and unlock hidden performance potential. RESYSTANCE improves disk I/O efficiency during read operations via io uring and significantly reduces software stack overhead by handling compaction directly inside the kernel through eBPF. Moreover, RESYSTANCE minimizes user-kernel transitions by offloading key I/O routines into the kernel without modifying the LSM-tree structure or compaction algorithm. RESYSTANCE was extensively evaluated using db_bench, YCSB, and OLTP workloads. Compared to baseline RocksDB, it reduced the average number of system call invocations during compaction by 99% and shortened compaction time by 50%. Consequently, in write-intensive workloads, RESYSTANCE improved throughput by up to 75% and reduced the p99 latency by 40%.

Figures (12)

• Figure 1: An Architecture of LSM-tree.
• Figure 2: Operation of block-based compaction in LSM-trees.
• Figure 3: Overview of the Resystance architecture.
• Figure 4: Detailed operation of the Resystance controller.
• Figure 5: Performance comparison under the FillRandom workload with varying numbers of compaction threads: overall IOPS, compaction throughput, and latency.