提升multi_index_container和内存碎片

Question

我在服务器中使用MIC作为我的LRU缓存，它已经取代了列表/映射LRU，因为我怀疑这是导致一些无法解释的内存占用的原因。内存泄漏是不可能的，至少没有工具发现任何泄漏以及代码检查。自从我开始使用MIC以来，图片有所改善(这是内存碎片的唯一证据)，但还不够。我们谈论的是几Gb的缓存，每天都有数百万条记录从缓存中被弹出。两到三周后，问题变得很明显--如果我清空缓存，进程仍然会有2-3 3Gb的内存。

我的容器非常简单：

typedef std::pair<Key, T> Element;
    typedef mic::multi_index_container<
        Element,
        mic::indexed_by<mic::sequenced<mic::tag<struct Seq>>,
                        mic::hashed_unique<mic::tag<struct Hash>, mic::member<Element, const Key, &Element::first>>>>
        item_list;

它使用erase和push_front插入新条目(或覆盖旧条目)，然后根据需要从尾部弹出元素。问题是是否值得尝试使用replace和relocate而不是push_front

UPDATE001:好了，新版本已经启动并运行了，我看到realocate显著改善了这种情况，3周后的内存占用比没有更改的机器上的占用少了大约1/1.5 Gb。现在它部署在世界各地的所有机器上。作为第二阶段，缓存无效化机制有许多变化。更少的弹出和重新插入应该也会改善这种情况(如果这真的是内存碎片)

Answer 1

我们也经历过同样的事情。我写了一个小测试程序，它使用300个线程的缓存。它使inserting和eraseing保持在大约200k (insert+erase)/sec，我在周末运行了它。我通过pmap -x total RSS检查了内存使用情况。

pmap -x [pid] | tail -n1 | awk '{print $4}'

在一分钟的分辨率中，人们可以看到，在缓存加载之前，内存消耗是线性的，从0到4.7‘s，然后以对数速度不断增加。如图所示。(缓存填满需要14分钟)。

​

更有趣的是，pmap -x报告加载了大量65536k的虚拟内存块(因此，这种过多的内存使用可能存在理论上的最大值)，但如果我从一个线程执行相同的操作，测试程序会分配一个4.7 got的块，并且在缓存变满后，内存使用量是恒定的。