21

OK、ASP.NET エキスパートの皆さん: リフレクターを使用して ASP.NET キャッシュの実装 (上にHttpRuntime.Cacheあり、HttpContext.Current.Cache) をHashtable内部で使用してキャッシュを保持しています。

ただし、データはアンマネージ メモリに格納されます。アンマネージ メモリにデータが格納されているのを確認できなかったので、これは非常に奇妙です。ただし、バイト配列のチャンクをキャッシュに挿入する非常に単純な Web アプリケーションを作成すると、次のようになります。

ここに画像の説明を入力

  • プライベート バイト: 460MB
  • 全ヒープのバイト数: 150MB

=>

管理メモリ: 150 MB

アンマネージド メモリ: 310 MB

したがって、基本的に私はアプリケーションを何度も呼び出しています (それぞれの増加は 1000x リクエストで、それぞれ 64KB の空のバッファbyte[]をキャッシュに入れます)。そのため、最も大きくなったのは、すべてのヒープ(マネージ メモリ)内のバイトではなく、プライベート バイト(合計メモリ) です。ただし、Hashtable を使用してマネージ ヒープにオブジェクトを追加しているため、マネージメモリは総メモリ量に合わせて増加すると予想しています。

この振る舞いを説明していただけますか？

アップデート

サイモンが言ったように、すべてのヒープ値のバイトはガベージ コレクションの後にのみ変更されます。コードを変更してガベージ コレクションを誘導し、カウンターを更新しました。Gen 2 ヒープ メモリの増加は、追加されたメモリの量とまったく同じです。ただし、アンマネージ メモリは依然としてはるかに高くなっています。この例では、合計メモリが 231 MB であるのに対し、ヒープ 2 はわずか 96 MB でした。

ここに画像の説明を入力

4

1 に答える 1

6

は# Bytes in all Heapsガベージ コレクションの実行時にのみ更新されPrivate Bytesますが、 はより高速な更新レートで使用できます。(その数値がどこから、内部的に、どのくらいの頻度で更新されているのかはわかりません。)

Private Bytes17:42:45 直後にの量が増加します。この量は# Bytes in all Heaps、約 17:43:10 の値のジャンプと一致しているようです。ガベージ コレクションが実行されて# Bytes in all Heapsカウンターが更新されるまでに 20 ～ 25 秒かかったようです。

スクリーンショットに示されている数分間のパフォーマンス カウンターから、メモリ割り当てがどのように機能するかを理解するのは困難です。;) テストを実行し続けて、長期にわたって予想がどのように機能するかを確認してください。

TL;DR: マネージド バイトの量はプライベート バイトと相関する必要がありますが、マネージド カウンターはガベージ コレクション中にのみ更新されます。

OP からの小さなメモ: この応答が示すように、メモリの遅れは GC の遅れによって完全に説明できます。アンマネージ メモリも上昇するという事実は、私の質問ではありませんでした。@サイモンに感謝します。

于 2013-10-17T17:15:37.633 に答える