🎊HotStorage’24 Can Modern LLMs Tune and Configure LSM-based Key-Value Stores?
论文分享|2024-7-17|最后更新: 2024-12-10
LSM
AI
Tune
type
Post
status
Published
date
Jul 17, 2024
slug
llm-tune-lsm
summary
HotStorage’24 Best Paper 介绍了一种利用 LLM 调优 LSM 的思路
tags
LSM
AI
Tune
category
论文分享
icon
password
Property
Dec 10, 2024 09:42 AM
ELMo-Tune
SZ-NPE • Updated Jul 16, 2024

Abstract

  • 基于日志结构合并树的键值存储 (lsmkvs) 是现代IT基础设施中重要的数据存储构件。但是，调优它们的性能需要配置 100 多个参数，这通常是手动完成的任务，或者在自动调优机制中使用有限的参数。本文探讨并回答了以下问题:我们能否利用 LLM 对系统和 LSM-KVS 组件的理解来对 LSM-KVS 进行无限制的参数池调优
  • LLMs 接受的训练是基于现成的 LSM-KVS 源代码、研究论文和开放材料，这些材料使机器具有类似人类的理解能力。我们研究了将大语言模型(llm)集成到 LSM-KVS 的自动调优框架中，以增强调优能力和交互性。我们的框架利用 llm 根据硬件、系统和工作负载信息，通过校准提示来推荐量身定制的配置。初步结果表明，与 lsm-kv 的开箱即用配置相比，在各种硬件和工作负载上的吞吐量提高了 3 倍，p99 延迟降低了 9 倍。

Introduction

  • LSM 由多个组件组成，每个组价对于性能、存储效率、查询速度都很关键。
  • LSM 因为应用场景的多样，已经适应了各种 setup：DM，Remote Storage 等等。像 RocksDB 和 Hbase 可能提供了超过 100 个的参数配置来管理组件。公司经常聘请领域专家，他们了解并与设置高性能 LSM-KVS 的工作负载和系统配置进行交互，以管理特定工作负载、存储设备、内存设备和部署的权衡。然而，随着参数数量的增加，即使是代码开发人员也很难充分理解每个选项的效果。
  • LSM-KVS 部署的日益复杂刺激了提高性能的自动化方法的发展。这些方法主要分为两大类:
    • Tuning (调优) —— 对公开的配置参数进行调优以提高性能(例如 RTune[26]、Endure[25]、Dremel [48]);
    • Optimization (优化) —— 对底层代码库和配置参数都进行修改（ADOC [46], AC-Key）
  • 本文聚焦在调优。下面这些方法只聚焦在一些子集的配置上，比如 bf, cache 大小等，缺乏对于系统资源、负载的知识。
    • RTune，K2VTune，Endure 利用 ML 预测不同工作负载的最佳配置；
    • Dremel, Sami and Eiko 分别提出了在线配置选择和贝叶斯优化技术。
  • 使用 LLM 来调优 LSM 面临一些挑战：
    • 构建提示和促进代码和自然语言之间转换的框架，反之亦然
    • 构造解析器来处理来自 LLM 响应的输出，这些响应可以是文本、单个代码块以及两者的交错组合
    • 对意外情况的防范措施 (如不允许记录日志或日志)，以及对意外反应的检测 (如缺少选项，幻觉反应)
  • 本文提出了弹性的基于大模型的调优，ELMo-Tune 采用了一个反馈回路，包括专门用于快速构建、系统资源监控、故障安全管理和 LLM 输出解释的模块，用于 lsm-kv 调优。用户只负责以预期的系统工作负载 (例如，读密集型，写密集型，以及相同的比率) 启动它。
  • 我们使用RocksDB [9] 和 GPT-4 API[4] 实现了 ELMo-Tune 的原型，该框架在 Github 上开源，用于进一步的调查和研究。与默认配置相比，我们的原型可以在 7 次调优迭代内将吞吐量提高 3 倍，将 p99 延迟提高 9 倍。我们在评估部分中讨论的各种配置上运行 ELMo-Tune。

Background

  • LSM-tree 可能涉及的 Options
notion image
  • 自动调优：人工调优的缺点是众所周知的，虽然没有任何方法可以取代人工调优，但最近机器学习和优化算法的进步已经为 LSM-KVS 引入了各种自动调优技术。但也存在局限性，即只能对小部分的 options 调优，BF, buffers 以及 merge 策略等等，缺少对于系统资源和负载的感知。
    • RTune 集成深度学习和遗传算法，通过分析工作负载模式来预测最佳配置
    • Endure 侧重于鲁棒调优，以最大限度地提高不同场景下的吞吐量。
    • Dremel 采用了一个Multi-Armed Bandit 来进行在线配置的选择。
    • Sami and Eiko 将多任务建模纳入贝叶斯优化框架

ELMo-Tune

  • 框架负责编排所有模块，并确保它们协同工作。用户负责以预期的系统工作负载(例如，读密集型，写密集型)启动系统。然后，ELMo 接管，在基准测试系统和 LLM 之间实现持续的反馈循环。当满足预定义的停止标准时(例如，基于最小的性能改进或最大的迭代次数)，ELMOTune 输出最终优化的配置文件
  • 四个主要模块：
    • Pompt Generator: 利用多个信息来创造 prompt，包括通过 psutil 和 fio 测试得到的系统信息，负载统计、当前配置信息。收集到的信息交织在一起形成提示
    • Option Evaluator：根据所选择的模型和输入信息，LLM 响应可能采用各种格式。框架需要在解析这些响应和提取建议的配置更改方面具有鲁棒性。
    • Active Flagger：ELMO-Tune处理基准测试结果(例如，从报告中提取吞吐量、延迟和尾延迟数据)，将其与前一次迭代的性能值进行比较，并确定更改是否增强了性能。如果有改进，则保留新的配置。否则，ELMO-Tune 将恢复到以前的选项文件，并使用有关性能恶化的信息生成一个中间提示，然后使用新的输出重新运行基准测试。这确保只记录有益的更改，逐步细化 LSM-KVS 配置以改进。
    • Safeguard Enforcer：LLM 容易产生不准确或不相关的输出，即所谓的幻觉[32]。ELMo 实现了两个简单而有效的解决方案，以避免 LLM 可能出现的错误/错误配置，一个可配置的黑名单，确保不修改必要的选项，以及一个格式检查器，确保只接受特定格式的 LLM 输出。
        • notion image

Evaluation

  • Docker 容器中测试：首先随机写 FR 50M 条键值对，其次随机读取 10M 条，数据预先加载了 25M 条；2 个线程执行随机读和随机写 (readrandom writerandom (RR-WR)作为混合工作负载)，共 25M ops， Mixgraph 中的 25M ops，一个配置为 50% 写和 50% 读的生产工作负载
  • 吞吐、延迟、不同配置下的对比：
notion image
notion image
  • 多轮迭代
notion image
  • 上图的 FR 中有多个参数被修改
notion image

Conclusion and Discussion

  • 我们目前的方法为迭代增强建立了一个反馈循环，并提供了显著的性能提升。此外，该方法可以修改和调优大量选项，而不局限于较小的子集
  • 我们观察到
    • 1) 在一次迭代中调整超过10个选项导致边际改进，
    • 2) 执行迭代允许 LLM 进行实验并从过去的结果中学习，
    • 3) 这样的方法允许灵活的调优方法，可以与各种系统配置、工作负载和存储设备一起工作，
    • 4) 模型以类似于在线博客的模式响应，更倾向于相同的配置选项。
  • 这些观察结果显示了这种方法的潜力。然而，值得注意的局限性仍然存在——特别是实现微调的能力有限。LLM 模型特别擅长提供快速启动配置。利用此属性并结合微调机制的解决方案将实现更快、更好的调优。此外，LLM 在识别新选项和废弃选项方面存在局限性，这需要特别注意，因为更有用的现代选项(例如 Rocksdb 中的动态级别大小)通常会被忽略，而旧选项(例如 Flush Job Count) 可能会被不必要地关注
  • 像 ELMo 这样的方法承诺了配置灵活性和无限调优能力，尽管存在限制，但我们相信它们可以被克服，并且该方法显示出进一步研究的希望

代码分析

  • 核心就是运行 main.py，该脚本会使用初始的 option file 运行 dbbench，然后通过 GPT API 生成新的 option file，并使用新的配置文件来运行 dbbench，同时也会存储输出到文件，输出包含对应的测试结果，以及当前测试的 option 配置文件，以及 GPT API 提供的选项文件背后的原因。 每轮迭代都是单独的文件。
  • 支持的一些参数：
  • 执行流程：
    • get_fio_result 获取 FIO 的测试结果，传入参数为包含 fio 测试结果的文件，如果不存在则执行 fio_run，分别运行 ["randwrite", "randread", "read", "write"]
      • —bs=4k，--ioengine=posixaio，--numjobs=1，--runtime=60，--size=10G
      • 正则表达式分别解析出对应的读写带宽
    • 获取初始的 option 配置文件
    • rocksdb subproces 执行测试， spm.benchmark
      • def benchmark(db_path, options, output_file_dir, reasoning, iteration_count, previous_results, options_files):
      • 如果是首次运行，直接执行 dbbench，iteration_count 为第几次迭代，指定负载 TEST_NAME 和使用的 options_files
        • 存储当前 option 到文件中；
        • 执行 pre_task 清理环境，主要是删 DB 和清缓存
        • 首次执行，创建 CGroupMonitor，监控执行 dbbench 过程中的 cpu 和 mem 消耗 avg_cpu_used, avg_mem_used
        • 如果不是首次执行，且 SIDE_CHECKER 为 true：
          • 创建 CGroupMonitor 监控 CPU 和内存消耗；
          • 间隔 30s 获取 ops/second，正则匹配得到吞吐
            • 如果小于之前吞吐的 0.9x，吞吐下降，则杀死进程（允许迭代次数为 3 次），重新 fio 测试，获取系统资源信息
            • 根据当前的情况生成新的配置文件：midway_options_file_generation
            • 然后使用新的配置文件运行 dbbench，对应的迭代次数 bm_iter+1
      • 不是首次执行，传入的参数中包含之前的测试结果再次运行 dbbench
    • 解析 dbbbench 的输出，错误处理、画图
    • 外层 main 控制迭代次数，以及设置一些 GPT 的参数：temperature = 0.4，retry_counter = 5
      • 每轮迭代也会生成新的 options 文件 generate_option_file_with_gpt 并且运行 benchmark
  • 在中途检测到性能下降时，生成配置文件的 GPT prompt
    • 每轮迭代运行的 gpt：支持三种 case，默认 case1
      • Generating options file with long option changes
      • Generating options file with short option changes
      • Generating options file with differences
    ICDE’23/VLDBJ’24 Optimizing LSM-based indexes for disaggregated memoryCV
    Loading...