我们目前在版本3.0.10上运行ArangoDB集群，用于存储在磁盘上的大约81 GB的POC，以及分布在5个主数据库服务器上的大约98 GB的主内存消耗。大约有2亿个顶点和3.5亿个边缘。有3个Edge集合和3个文档集合，由于存在边缘，大部分内存（80％）被消耗
我正在探索减少主内存消耗的方法。我想知道是否有任何方法来压缩/序列化数据，以便使用较少的主内存。
内存减少的原因是降低基础设施成本，我愿意为我的用例权衡速度。
如果有任何方法可以减少ArangoDB的主内存消耗，请告诉我
我们花了一段时间才发现我们将vm.overcommit_memory设置为2的原始建议在所有情况下并不好。
似乎ArangoDB中的捆绑式jemalloc内存分配器存在一些问题。
使用vm.overcommit_memory内核设置值为2时，分配器存在拆分现有内存映射的问题，这使得arangod进程的内存映射数量随着时间的推移而增长。这可能导致内核拒绝向arangod进程分发更多内存，即使物理内存仍然可用。内核只会向每个进程授予vm.max_map_count内存映射，在许多Linux环境中默认为65530。
运行jemalloc并将vm.overcommit_memory设置为2时的另一个问题是，对于某些工作负载，Linux内核跟踪为“已提交的内存”的内存量也会随着时间的推移而增长并且不会减少。因此，最终ArangoDB守护进程（arangod）可能无法获得更多内存，因为它达到了配置的过度使用限制（物理RAM * overcommit_ratio +交换空间）。
所以这里的解决方案是将vm.overcommit_memory的值从2修改为1或0。这将解决这两个问题。当使用jemalloc和任何overcommit设置时，我们仍然观察到不断增加的虚拟内存消耗，但实际上这不应该导致问题。因此，当将vm.overcommit_memory的值从2调整为0或1（0是Linux内核默认btw。）时，这应该会改善这种情况。
解决这个问题的另一种方法，就是需要从源代码编译ArangoDB，就是编译一个没有jemalloc的构建（-DUSE_JEMALLOC=Off，当cmaking时）。我只是将此列为完整性的替代方案。使用系统的libc分配器，您应该看到非常稳定的内存使用情况。我们还尝试了另一个分配器，恰好是来自libmusl的分配器，并且随着时间的推移，这也显示出非常稳定的内存使用。这里使分配器交换成一个重要问题的主要问题是jemalloc具有非常好的性能特征。
（Qazxswpoi）