面临的问题

日志结构合并树（LSM-tree）凭借其将随机写转化为顺序写的独特设计，已广泛用于现代键值存储系统（如 RocksDB、OceanBase）。

然而，LSM-tree 内部操作会与前台用户请求争抢 CPU、I/O 带宽和内存资源，导致系统吞吐量急剧下降、延迟飙升至正常值的数十倍甚至数百倍。这种性能尖峰（Performance Spikes）问题长期困扰着学术界和工业界。

近年来，大量工作尝试通过静态参数配置、启发式规则或 LLM 辅助参数调优等方式来缓解这一问题。静态配置无法适应动态变化的工作负载；基于 LLM 的方法（如 ELMo-Tune）虽然智能，但单次迭代耗时约 100 秒，且调优效果不稳定；部分参数调整方法（如 ADOC、SILK）则因触发滞后、参数覆盖面有限而无法性能尖峰。

论文 Tetris 正是针对这一核心缺陷提出了解决方案。

作者指出，LSM-tree 系统拥有超过 100 个参数，但现有方法要么对所有参数一视同仁，要么仅调整少数几个参数，没有根据实时工作负载特征进行针对性的参数选择。Tetris 通过实时监控性能波动和负载模式，在性能尖峰发生前提前介入，动态选择最合适的参数进行调整。

核心理念：让系统从“被动响应性能恶化”转向“主动预防性能尖峰”

传统的 LSM-KVS 参数调优方法仍存在严重的性能波动问题，未能很好地适应动态变化的工作负载。静态配置和部分参数调整虽然简单，但缺乏灵活性与针对性；LLM 方法虽然能调整多个参数变量，但代价高昂且行为不可预测。

Tetris 的核心理念在于，将参数调优视为一个可检测、可分类、可动态调整的过程。

它不再把调优等同于简单的参数修改，而是将调优拆解为三个紧密协同的部分：何时触发调优、调整哪些参数、如何高效调整。通过建模性能尖峰的严重程度和当前工作负载的特征，Tetris 为轻量级实时调优场景提供了一种解决方案。

图1. Tetris 架构图

Tetris 设计：何时调、调什么、怎么调

在决定何时启动参数调优时，一个关键挑战在于如何区分正常的性能波动与真正需要干预的性能尖峰。

Tetris 采用基于滑动窗口的统计模型：维护一个历史性能指标窗口，实时计算均值（μ）和标准差（σ），设定自适应阈值 μ + k·σ。

• 轻微尖峰：当延迟超过 μ+2σ 时，视为预警信号。论文通过实验发现，在 OceanBase 上，一系列轻微尖峰往往预示着即将到来的剧烈尖峰。此时触发慢调优器，以线性方式温和调整参数。
• 重大尖峰：当延迟超过 μ+4σ 时，触发快调优器，以指数方式激进调整，迅速缓解性能恶化。

滑动窗口大小和 k 值共同控制灵敏度，在实时响应与误报风险之间取得平衡。

图2.性能驱动的调优触发器示例图

RocksDB 暴露了超过 100 个可调参数，全量调优既不现实也无必要。以往方法通常只调整少数几个参数（如线程数、批次大小），而没有根据工作负载特征进行选择参数。

通过实时监控读写比、顺序性/随机性、访问倾斜度等特征，将工作负载分类（读密集、写密集、均衡等），并映射到性能关键参数（如 MemTable 大小、compaction 线程数等）。

这种负载驱动的参数选择大幅压缩了调优空间，使实时调优变得可行。

表1. 负载模式建模

参数调整本身虽然会消耗系统资源，Tetris 通过资源感知、参数调优和参数回滚确保调优过程轻量高效。

具体而言，它实时监测 CPU 线程、内存使用及 LSM-tree 层级状态（如文件数和待合并字节数），确保参数调优不超出当前资源余量；在应对负载尖峰时，根据严重程度采用线性步长逐步逼近最优配置或指数步长快速缓解延迟尖峰；待系统性能恢复稳定后，再逐步回滚参数至默认值，避免因过度调优引发性能下降。

图3. Tetris执行流程

实验效果

团队在 RocksDB 上使用 db_bench 和 YCSB 真实负载进行评测，主要结果如下：

相比 ADOC，Tetris 使平均延迟降低 18%（最高62%），吞吐量提升 38%（最高1.64倍）。在不同读写比（0:100、20:80、50:50、80:20、100:0）的连续负载下，Tetris 产生的延迟尖峰数量最少、峰值最低。

图4. 吞吐量对比

图5.平均延迟对比

图6. 尾延迟

图7. 实时延迟对比

Tetris 通过将“何时调、调什么、怎么调”三个设计结合，有效弥补了现有方法过度依赖静态配置或高成本 LLM 调优的不足。

此外，Tetris 在多种工作负载与模型设置下均展现出稳定的性能提升，并改善了系统的可预测性与资源利用效率。

转自：Oceanbase

版权申明：内容来源网络，版权归原创者所有，如有侵权请联系删除

想了解更多行业资讯

扫码关注👇

了解更多考试相关

扫码添加上智启元官方客服微信👇