問題タブ [lru]

アプリケーションにキャッシュを実装しようとしていますが、C# で既定のメモリ キャッシュを使用したいと考えています (これが機能しない場合は、この要件を変更できます)。私の問題は、マシンにある物理メモリの最大量を超えたくないということですが、私が理解しているように、デフォルトのメモリキャッシュにそのような制約を追加することはできません。

一般に、ポリシーは次のとおりです。

1. オブジェクトがリクエストなしで 10 分間キャッシュ内にある場合、オブジェクトは削除されます
2. 新しいオブジェクトがキャッシュに追加され、使用可能な物理メモリの最大量が使用済みに近づくと、LRU に基づいて要素が削除されます

私のキャッシュにはさまざまなオブジェクトが含まれている可能性があり、それらは 10 MB から 2 ～ 3 GB の範囲にあるため、trim機能を実際に動作させることはできません。

RAM の使用状況を監視する LRU キャッシュを実装する方法について何か提案はありますか? うまくいけば、.net のキャッシュを使用して実行できますか?

編集

MemoryCache が 100Mb と物理メモリの 20% に制限されている簡単な例を追加しましたが、何も変わりません。私のメモリは、キャッシュエントリの削除なしでいっぱいです。ポーリング間隔が 5 秒ごとに変更されていることに注意してください。

アプリケーションの非常に単純な lru ページの置換に次のコードを使用したいと考えていました。buf_recの 2 番目と 3 番目の要素のカウンターは常に同じ値であり、その理由がわかりませんでした。

これが私がそれを使用する方法です

cache.cファイルでLRUコードを探していますが、これが私が見つけることができる唯一のコードです。

私にはLRUコードが欠落しているように見えますが、コロンの直後にLRUアルゴリズムを配置する必要があると思いました。それで、私が何かを逃した場合、あなたは私を正しい方向に向けるか、私にいくつかのヒントを与えることができますか？

どうもありがとうございます。

Adaptive Cache Replacement アルゴリズムの Java 実装を手伝ってくれる人はいますか? それは私の学士号の一部であり、それを理解するのに本当に問題があります。EJB 2.0 でキャッシュ実装を使用します。

memcache で使用可能なメモリがいっぱいになると、memcache は LRU (最後に最近使用された) アルゴリズムを使用してメモリを解放します。私の質問は、LRU アルゴリズムは、期限切れのアイテムではなく、一定期間使用されていない (最後に最近使用された) エントリを削除するのでしょうか? 期限切れのエントリは、その時点では削除されませんが、次に誰かがアクセスしようとしたとき (AFAIR) に削除されます。では、LRU アルゴリズムは (また) キーの有効期限を考慮しますか?

私は次のプログラムに取り組んでいますが、情報が不足しているように感じます.a)とb)はちょっとしたトリックです:

ループは、4KB ページを使用する仮想メモリ システム上のプログラムの一部として実行されます。必要に応じてメモリ内で置換するページを選択するために LRU 置換アルゴリズムが使用されると仮定します。「Start」というラベルの付いた命令はページ境界で始まり、ループの本体には 4601 組のシフト命令 (sll と srl) が含まれています。

a) メモリに 8 つの 4KB フレームが含まれている場合、ループの実行中にページ フォールトはいくつ発生しますか?

b) メモリに 9 つの 4KB フレームが含まれている場合、ループの実行中にページ フォールトはいくつ発生しますか?

a) と b) はどちらも 5 ページ フォールトではないでしょうか? ループするたびに 4602 の命令があり、MIPS 命令は 4B、ページ サイズは 4KB です。4KB/4B = 1 ページあたり 1024 命令なので、最初のループは次のようになります。

命令 0 - 1023 フレーム 0 ページフォルト あり

指示 1024 - 2047 フレーム 1 ページ フォルトあり

指示 2048 - 3071 フレーム 2 ページ フォルトあり

指示 3072 - 4096 フレーム 3 ページ フォルトあり

指示 4096 - 4602 フレーム 4 ページ フォルトあり

そのため、2 回目の反復でループに戻ったとき、ページはまだ LRU ポリシーによって置き換えられていないため、それらを再度参照できます。32 回のループ反復で 8 フレームか 9 フレームかによって、なぜこれが変わるのでしょうか?

ネットでこの情報を探してみましたが、それについての良い情報を見つけることができませんでした. それがどのように機能するかを説明することを知っていますか？1. ある種の LRU アルゴリズムですか? 2. すべてのブラウザが同じ「クリーニング アルゴリズム」を共有していますか?

ありがとう！シェイ

このコードは、ブースト多重指数「mru」の例から採用されています。

http://www.boost.org/doc/libs/1_46_1/libs/multi_index/example/serialization.cpp

boost :: unordered_mapと同様のことをしているコードがありますが、この例からmru機能を追加したいと思います。

このコードをできるだけboost::unordered_mapに近づけて機能させたいと思います。私にとって重要な機能は、unordered_mapの[]演算子です。

main（）の最後の行は壊れており、コメントとして各行の上にあるのが私の質問です。

すべての回答コメントに事前に感謝します。

まだC++/ boostを掘り下げているので、コメント/フィードバックは大歓迎です。

私はboost::unordered_mapsで遊んでいて、図形を使用して多形の例を作成しました。頭を包み込んだ頃（ほとんど）、boostmulti_indexのmruの例に出くわしました。 http://www.boost.org/doc/libs/1_46_1/libs/multi_index/example/serialization.cpp

その時点で私は思った。うーん、LRUに基づいて値を破棄する固定サイズのマルチインデックスポリモーフィックコンテナで、実装しないのはおかしなことに聞こえます。

たくさんのことをやり遂げた後、私はまだ次の質問を残されています。

1. insert（）で、シーケンスイテレータからhashed_uniqueイテレータを取得して、eraseを直接呼び出す方法はありますか？

2. findを実装するより良い方法はありますか？ルックアップのためだけにダミーの形状を作成する代わりに、キーだけを使用してboost::unordered_mapのような検索を実行できれば便利です。

3. get <>の正しいパスは何ですか（コードのXXXコメントを参照）私は正しいことをすべて試した後、ランダムながらくたを試し始めましたが、何もパンアウトされませんでした。

4. 本当に[]演算子が欲しいのですが、それは道のりだと思います... shape [cptr1-> pos] = cptr1;

5. 私のhash_index::iteratorからアイテムを取得する（または一般的にこれを理解する）にはどうすればよいですか、それを印刷することは確かに役に立ちませんでした...

p itr $ 1 = {、std :: allocator >>>、boost :: multi_index :: detail ::bucket_array >>>、boost :: shared_ptr、long、boost :: shared_ptr const *、boost :: shared_ptr const＆>> = {、std :: allocator >>>、boost :: multi_index :: detail ::bucket_array >>>、boost :: shared_ptr const *、boost :: iterator、long、boost :: shared_ptr const *、boost :: shared_ptr const＆ > >> = {、std :: allocator >>>、boost :: multi_index :: detail ::bucket_array >>>、boost :: shared_ptr const *、boost :: iterator、long、boost :: shared_ptr const *、boost :: shared_ptr const＆> >> = {、std :: allocator >>>、boost :: multi_index :: detail ::bucket_array >> >>、boost :: incrementable、std :: allocator >>>、boost :: multi_index： ：detail ::bucket_array >>>、boost :: dereferenceable、std :: allocator>>>、boost :: multi_index :: detail ::bucket_array >>>、boost :: shared_ptr const *、boost :: iterator、long、boost :: shared_ptr const *、boost :: shared_ptr const＆>> >>> = { 、std :: allocator >>>、boost :: multi_index :: detail ::bucket_array >>>、boost :: dereferenceable、std :: allocator >> >>、boost :: multi_index :: detail ::bucket_array >>>、 boost :: shared_ptr const *、boost :: iterator、long、boost :: shared_ptr const *、boost :: shared_ptr const＆>> >> = {、std :: allocator >> >>、boost :: multi_index :: detail :: bucket_array >>>、boost :: shared_ptr const *、boost :: iterator、long、boost :: shared_ptr const *、boost :: shared_ptr const＆> >> = {、long、boost :: shared_ptr const *、boost :: shared_ptr const＆>> = {、long、boost :: shared_ptr const *、boost ::shared_ptr const＆>> = {、long、boost :: shared_ptr const *、boost :: shared_ptr const＆>> = {}、}、}、}、}、}、}、}、}、node = 0x60a010、buckets = 0x7fffffffdd88 }

質問1

サーバーの RAM メモリ キャッシュ レイヤーを構築/検索しています。これは、同時要求 (Get と Sets の両方) を処理する必要がある単純な LRU キャッシュです。

https://github.com/pmylund/go-cacheがスレッドセーフであると主張していることがわかりました。

これは、保存されたインターフェイスを取得する限り当てはまります。しかし、複数のゴルーチンが同じデータを要求する場合、それらはすべて、同じメモリ ブロックへのポインター (インターフェースに格納されている) を取得しています。ゴルーチンがデータを変更する場合、これはもはや安全ではありません。

この問題に取り組むキャッシュパッケージはありますか?

質問 1.1

質問 1に対する答えが「いいえ」の場合、推奨される解決策は何ですか?
2 つのオプションが表示されます。

代替案 1の
解決策:sync.Mutex各ゴルーチンがデータの読み取り/書き込みの前にデータをロックする必要があるように、値を a を使用してラッピング構造体に格納します。
type cacheElement struct { value interface{}, lock sync.Mutex }
欠点:キャッシュは、データに加えられた変更を認識しなくなったり、キャッシュから削除されたりすることさえあります。1 つのゴルーチンが他のゴルーチンをロックすることもあります。

代替案 2の
解決策:データのコピーを作成します (データ自体にポインターが含まれていないと仮定します)
。 欠点:キャッシュ Get が実行されるたびにメモリが割り当てられ、ガベージ コレクションが増えます。

マルチパートの質問で申し訳ありません。しかし、すべてに答える必要はありません。質問 1 に適切な答えがあれば、それで十分です。