performance - 减少 ArangoDB 内存消耗的方法

Question

我们目前有一个 ArangoDB 集群在 3.0.10 版本上运行，用于 POC，磁盘上存储了大约 81 GB，主内存消耗大约 98 GB，分布在 5 个主数据库服务器上。大约有 2 亿个顶点和 3.5 亿条边。有3个边集合和3个文档集合，大部分内存(80%)由于边的存在而被消耗

我正在探索减少主内存消耗的方法。我想知道是否有任何方法可以压缩/序列化数据，以便使用更少的主内存。

减少内存的原因是为了降低基础设施成本，我愿意为我的用例牺牲速度。

如果有任何方法可以减少 ArangoDB 的主内存消耗，请告诉我

Answer 1

我们花了一段时间才发现我们最初的建议是将 vm.overcommit_memory 设置为 2 这在所有情况下都不好。

在某些环境下，ArangoDB 中捆绑的 jemalloc 内存分配器似乎存在问题。

vm.overcommit_memory 内核设置值为 2 时，分配器会出现拆分现有内存映射的问题，这使得 number arangod 进程的内存映射随时间增长。这可能导致内核拒绝向 arangod 进程分配更多内存，即使物理内存仍然可用。内核只会向每个进程授予最多 vm.max_map_count 个内存映射，在许多 Linux 环境中默认为 65530。

在 vm.overcommit_memory 设置为 2 的情况下运行 jemalloc 时的另一个问题是，对于某些工作负载，Linux 内核跟踪的内存量 “提交的内存" 也会随着时间的推移而增长，不会减少。因此，最终 ArangoDB 守护进程 (arangod) 可能无法获得更多内存，因为它达到了配置的过度使用限制(物理 RAM * overcommit_ratio + 交换空间)。

所以这里的解决方案是将vm.overcommit_memory的值从2修改为1或者0。这将解决这两个问题。我们仍然观察到在将 jemalloc 与任何过度使用设置一起使用时，虚拟 内存消耗不断增加，但实际上这不会导致问题。因此，当将 vm.overcommit_memory 的值从 2 调整为 0 或 1 (0 是 Linux 内核默认的 btw。)这应该可以改善这种情况。

解决该问题的另一种方法是在没有 jemalloc 的情况下编译构建(-DUSE_JEMALLOC=Off 时需要从源代码编译 ArangoDB)。为了完整起见，我只是将其列为替代方案。使用系统的 libc 分配器，您应该会看到相当稳定的内存使用情况。我们还尝试了另一个分配器，正是来自 libmusl 的分配器，这也显示了随着时间的推移相当稳定的内存使用情况。这里使交换分配器成为一个重要问题的主要问题是 jemalloc 在其他方面具有非常好的性能特征。

( quoting Jan Steemann as can be found on github )

同时对 rocksdb 存储引擎进行了一些新添加。 We demonstrate how memory management works in rocksdb .

很多Options of the rocksdb storage engine are exposed to the outside via options .

Discussions and a research of a user led to two more options to be exposed for configuration使用 ArangoDB 3.7:

• --rocksdb.cache-index-and-filter-blocks-with-high-priority
• --rocksdb.pin-l0-filter-and-index-blocks-in-cache
• --rocksdb.pin-top-level-index-and-filter