RocksDB 内存超限问题剖析

原创

于 2024-12-12 10:24:39 发布 · 1.1k 阅读

16 ·

CC 4.0 BY-SA版权

文章标签：

#RocksDB #内存分配管理 #glibc ptmalloc #jemalloc

作者：来自 vivo 互联网服务器团队- Zeng Luobin

在使用 RocksDB 存储引擎的过程中，有部分开发者遇到了内存使用超出预期的情况。本文针对这一问题展开了深入分析，从内存使用原理、RocksDB 内存管理机制、常见内存使用问题等方面进行了详细探讨，并提出了相应的解决方案和优化建议，希望能够帮助开发者更好地理解和优化 RocksDB 的内存使用情况，提升系统性能和稳定性。

一、背景

1.1 前言

在现代数据库系统中，RocksDB 作为一种高性能的键值存储引擎，广泛应用于需要高吞吐量和低延迟的场景。然而，在使用过程中观察到 RocksDB 的内存使用常常超出预设的阈值，这一现象对系统的稳定性和可用性构成了严重威胁。

RocksDB 提供了通过 block-cache-size 参数来控制缓存使用的机制。开发者可以通过以下代码片段设置缓存大小：

std::shared_ptr<rocksdb::Cache> cache = rocksdb::NewLRUCache(cache_size, -1, true);

然而，实际应用中发现，RocksDB 的内存占用往往超出了设定的 cache_size 值。这种内存使用的不可预测性导致了内存分配的失控，甚至触发了程序的 OOM（Out of Memory）错误，严重影响了服务的连续性和可靠性。

有部分开发者报告了相似的内存超额使用问题，该问题在 GitHub 社区也引起了广泛关注。

1.2 内存分析流程

在分析内存的过程中，可以搭配许多 Linux 的命令工具来进行。以下是一套内存分析的基本思路：

图片来源：https://learn.lianglianglee.com/

1、可以先用 free 和 top，查看系统整体的内存使用情况。

2、再用 vmstat 和 pidstat，查看一段时间的趋势，从而判断出内存问题的类型。

3、最后进行详细分析，比如内存分配分析、缓存/缓冲区分析、具体进程的内存使用分析等。

其中，第一步和第二步可以观察到内存问题的现象，而最难的往往是第三步，对内存的使用情况进行分析。第三步中需要结合业务代码，对问题的根因提出假设，然后配合一些工具来验证假设。分析的过程更像在做实验：提出假设，收集数据，验证假设，得出结论。下文中，也会搭配内存工具进行分析，供读者参考。

二、问题描述

在前文所述的 RocksDB 内存使用问题背景下，我们业务生产环境遭遇了相似的挑战。应用程序采用 glibc 的 ptmalloc 作为内存分配器。在程序中，存在两个 RocksDB 实例，分别用于存储不同类型的数据。根据配置，两个实例的 block-cache-size 分别被设定为4GB和8GB。然而，实际的内存消耗量远远超出了这一预设值，导致整体内存使用量显著高于预期。

通过执行 free -g 命令，监测到程序的内存使用量达到了59GB，这一数值已经接近了物理服务器的内存容量阈值。此外，通过定期执行 vmstat 3 命令，观察到自服务启动以来，内存使用量持续上升，直至接近100%的使用率。这一现象表明，系统内存已极度紧张，存在触发 OOM（Out of Memory）错误的风险。

鉴于当前内存使用情况，确认了内存管理问题的存在，并认识到需要进一步结合源代码进行深入分析，以识别内存使用异常的根本原因，并探索相应的优化措施。