1

我在服务器中使用 MIC 作为我的 LRU 缓存，它已经替换了列表/映射 LRU，因为我怀疑这是导致一些无法解释的内存占用的原因。内存泄漏是不可能的，至少没有工具发现任何泄漏以及代码检查。自从我开始使用 MIC 后，图片有所改善（这是内存碎片的唯一证据），但还不够。我们谈论的是几 Gb 的缓存，每天有数百万条记录从其中弹出。两到三周后，问题变得清晰起来——如果我清空缓存，该进程仍会保留无法解释的 2-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;

它使用eraseandpush_front插入新条目（或覆盖旧条目），然后在需要时从尾部弹出元素。问题是是否值得尝试使用replaceandrelocate而不是push_front？

UPDATE001：好的，新版本已经启动并运行，我看到重新分配显着改善了这种情况，3 周后的内存占用比没有更改的机器上的占用少约 1/1.5 Gb。现在它部署在全球所有机器上。作为第二阶段，缓存失效机制有很多变化。更少的弹出和重新插入也应该改善这种情况（如果它真的是内存碎片）

4

1 回答 1

0

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

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

在一分钟的分辨率下，可以看到，在加载缓存之前，内存消耗从 0 到 4.7GB 是线性的，之后它会以对数速度不断增加。如图所示。（使缓存满需要 14 分钟）。 在此处输入图像描述

更有趣的事情是 pmap -x 报告了很多 65536k 块正在加载的虚拟内存（因此对于这种过多的内存使用可能存在理论上的最大值），但如果我从一个线程执行相同的操作，测试程序分配了一个 4.7GB 块，缓存满后，内存使用量保持不变。

于 2016-12-19T07:59:37.823 回答