1

サーバーの LRU キャッシュに MIC を使用しています。これが原因で説明できないメモリ フットプリントが発生したのではないかと疑っていたため、リスト/マップ LRU を MIC に置き換えました。メモリ リークは把握できていません。少なくとも、コード インスペクションだけでなく、リークを検出したツールはありません。MIC を使い始めてから画像は改善されましたが (メモリの断片化の唯一の証拠です)、十分ではありませんでした。私たちは、数 Gb のキャッシュについて話しており、毎日何百万ものレコードがそこから排出されています。2 ~ 3 週間後、問題が明らかになりました。キャッシュを空にすると、プロセスはまだ原因不明の 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;

eraseandを使用しpush_frontて新しいエントリを挿入 (または古いエントリを上書き) し、必要に応じて末尾から要素を取り出します。replace問題は、 andrelocateの代わりにpush_front?を使用する価値があるかどうかです。

UPDATE001: OK、新しいバージョンが稼働中です。再割り当てによって状況が大幅に改善されたことがわかりました。3 週間後のメモリ フットプリントは、変更を加えていないマシンのフットプリントよりも 1/1.5 Gb 小さくなりました。現在、世界中のすべてのマシンに展開されています。第 2 段階として、キャッシュ無効化機構に多数の変更があります。排出と再挿入を減らすと、状況も改善されるはずです (実際にメモリの断片化が発生している場合)。

4

1 に答える 1

0

私たちは同じことを経験しました。300 スレッドのキャッシュを使用する小さなテスト プログラムを作成しました。insert約 200k (挿入 + 消去)/秒でing とing を維持eraseし、週末にかけて実行しました。pmap -x total RSS でメモリ使用量を調べてみました

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

1 分間の解像度では、キャッシュがロードされるまで、メモリ消費量は 0 から 4.7GB までほぼ線形であり、その後は対数速度で増加していることがわかります。図が示すように。(キャッシュがいっぱいになるまでに 14 分かかりました)。 ここに画像の説明を入力

もう 1 つの興味深い点は、pmap -x がロードされている仮想メモリの 65536k チャンクを大量に報告したことです (したがって、この過剰なメモリ使用量には理論上の最大値がある可能性があります)。単一の 4.7GB チャンクを割り当て、キャッシュがいっぱいになった後、メモリ使用量は一定でした。

于 2016-12-19T07:59:37.823 に答える