在ArangoDB中减少内存消耗的方法

Question

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

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

减少内存的原因是为了减少基础设施成本，我愿意为我的用例在速度上进行权衡。

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

Answer 1

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

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

在vm.overcommit_memory内核设置值为2的情况下，分配器在拆分现有内存映射时会遇到问题，这会使arangod进程的内存映射数量随着时间的推移而增长。即使物理内存仍然可用，这也可能会导致内核拒绝将更多内存分配给arangod进程。内核只会向每个进程授予最多vm.max_map_count内存映射，在许多Linux环境中，该值默认为65530。

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

因此，这里的解决方案是将vm.overcommit_memory的值从2修改为1或0。这将解决这两个问题。我们仍然观察到当使用jemalloc和任何过量提交设置时，虚拟内存消耗在不断增加，但在实践中这应该不会造成问题。因此，在将vm.overcommit_memory的值从2调整为0或1时(0是Linux内核的默认btw。)这应该会改善这种情况。

解决这个问题的另一种方法是编译一个没有ArangoDB的构建(cmaking时使用-DUSE_JEMALLOC=Off)。为了完整起见，我只是在这里列出了一个备选方案。使用系统的libc分配器，您应该可以看到非常稳定的内存使用情况。我们还尝试了另一个分配器，确切地说是来自libmusl的分配器，它也显示了随着时间的推移内存使用情况相当稳定。这里的主要问题是，jemalloc在其他方面具有非常好的性能特征，这使得交换分配器成为一个不小的问题。

()

同时，对rocksdb存储引擎进行了几个新的添加。We demonstrate how memory management works in rocksdb。

许多Options of the rocksdb storage engine are exposed to the outside via options。

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

• --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