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