Black or White? How to Develop an AutoTuner for Memory-based Analytics [Extended Version]
Not on the map. Why?
Abstract (arXiv)
There is a lot of interest today in building autonomous (or, self-driving) data processing systems. An emerging school of thought is to leverage AI-driven "black box" algorithms for this purpose. In this paper, we present a contrarian view. We study the problem of autotuning the memory allocation for applications running on modern distributed data processing systems. For this problem, we show that an empirically-driven "white-box" algorithm, called RelM, that we have developed provides a close-to-optimal tuning at a fraction of the overheads compared to state-of-the-art AI-driven "black box" algorithms, namely, Bayesian Optimization (BO) and Deep Distributed Policy Gradient (DDPG). The main reason for RelM's superior performance is that the memory management in modern memory-based data analytics systems is an interplay of algorithms at multiple levels: (i) at the resource-management level across various containers allocated by resource managers like Kubernetes and YARN, (ii) at the container level among the OS, pods, and processes such as the Java Virtual Machine (JVM), (iii) at the application level for caching, aggregation, data shuffles, and application data structures, and (iv) at the JVM level across various pools such as the Young and Old Generation. RelM understands these interactions and uses them in building an analytical solution to autotune the memory management knobs. In another contribution, called GBO, we use the RelM's analytical models to speed up Bayesian Optimization. Through an evaluation based on Apache Spark, we showcase that RelM's recommendations are significantly better than what commonly-used Spark deployments provide, and are close to the ones obtained by brute-force exploration; while GBO provides optimality guarantees for a higher, but still significantly lower compared to the state-of-the-art AI-driven policies, cost overhead.
Key facts. Cited by 9 papers in the map (data through 7 Oct 2026). First posted on arXiv 26 Feb 2020.
Builds on
No reference list yet.
Built on by
Citing papers per year: 2021: 1; 2022: 1; 2023: 3; 2024: 1; 2025: 1; 2026: 2.
9 papers.
- 2021A Survey on Deep Reinforcement Learning for Data Processing and Analyticscited by 10
- 2024E2ETune: End-to-End Knob Tuning via Fine-tuned Generative Language Modelcited by 9
- 2023A Unified and Efficient Coordinating Framework for Autonomous DBMS Tuningcited by 4
- 2023Rover: An online Spark SQL tuning service via generalized transfer learningcited by 3
- 2023Towards General and Efficient Online Tuning for Sparkcited by 1
- 2022Learning-Based Data Storage [Vision] (Technical Report)cited by 0
- 2025Centrum: Model-based Database Auto-tuning with Minimal Distributional Assumptionscited by 0
- 2026A Case for Agentic Tuning: From Documentation to Action in PostgreSQLcited by 0
- 2026Data Agents: Agentic Data Systemscited by 0
- 2026Data Agents: Agentic Data Systems21 Sep 2026
- 2026A Case for Agentic Tuning: From Documentation to Action in PostgreSQL19 May 2026
- 2025Centrum: Model-based Database Auto-tuning with Minimal Distributional Assumptions26 Oct 2025
- 2024E2ETune: End-to-End Knob Tuning via Fine-tuned Generative Language Model17 Apr 2024
- 2023Towards General and Efficient Online Tuning for Spark5 Sep 2023
- 2023A Unified and Efficient Coordinating Framework for Autonomous DBMS Tuning10 Mar 2023
- 2023Rover: An online Spark SQL tuning service via generalized transfer learning8 Feb 2023
- 2022Learning-Based Data Storage [Vision] (Technical Report)12 Jun 2022
- 2021A Survey on Deep Reinforcement Learning for Data Processing and Analytics10 Aug 2021