MemoryCache ne respecte pas les limites de la mémoire de configuration

Wow, je viens de passer beaucoup trop de temps à creuser autour de la CLR avec réflecteur, mais je pense que j'ai enfin une bonne poignée sur ce qui se passe ici.

Les paramètres sont lus correctement, mais il semble y avoir un profond problème dans le CLR lui-même qui ressemble, il sera rendu à la mémoire de réglage de limite essentiellement inutiles.

Le code suivant est reflétée par le Système.Moment de l'exécution.La mise en cache DLL, pour le CacheMemoryMonitor classe (il y a une catégorie similaire qui surveille la mémoire physique et les offres spéciales avec les autres, mais c'est le plus important):

protected override int GetCurrentPressure()
{
int num = GC.CollectionCount(2);
SRef ref2 = this._sizedRef;
if ((num != this._gen2Count) && (ref2 != null))
{
this._gen2Count = num;
this._idx ^= 1;
this._cacheSizeSampleTimes[this._idx] = DateTime.UtcNow;
this._cacheSizeSamples[this._idx] = ref2.ApproximateSize;
IMemoryCacheManager manager = s_memoryCacheManager;
if (manager != null)
{
manager.UpdateCacheSize(this._cacheSizeSamples[this._idx], this._memoryCache);
}
}
if (this._memoryLimit <= 0L)
{
return 0;
}
long num2 = this._cacheSizeSamples[this._idx];
if (num2 > this._memoryLimit)
{
num2 = this._memoryLimit;
}
return (int) ((num2 * 100L) / this._memoryLimit);
}

La première chose que vous remarquerez, c'est qu'il n'a même pas essayer de regarder la taille du cache jusqu'à ce qu'après un Gen2 la collecte des ordures, au lieu juste de tomber sur la stockées existantes valeur de taille dans cacheSizeSamples. De sorte que vous ne jamais être en mesure de frapper la cible est bien, mais si le reste travaillé nous aurait au moins d'obtenir une mesure de la taille avant que nous arrivions en réelle difficulté.

Donc en supposant une Gen2 GC a eu lieu, nous courons dans le problème 2, qui est que ref2.ApproximateSize fait un horrible travail de rapprochement de la taille de la mémoire cache. Obstinés par la CLR indésirable, je trouve que c'est un Système.SizedReference, et c'est ce qu'il fait pour obtenir la valeur (IntPtr est un handle vers le MemoryCache objet lui-même):

[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern long GetApproximateSizeOfSizedRef(IntPtr h);

Je suis en supposant que la déclaration extern signifie qu'il va plonger dans non géré windows la terre à ce point, et je n'ai aucune idée de comment commencer à trouver ce qu'elle fait là. De ce que j'ai observé cependant, il fait une horrible tâche d'essayer de rapprocher la taille de l'ensemble de la chose.

La troisième perceptible chose il y a l'appel à manager.UpdateCacheSize qui sonne comme il devrait faire quelque chose. Malheureusement, dans le fonctionnement normal de l'échantillon de la façon dont cela devrait fonctionner s_memoryCacheManager sera toujours null. Le champ est défini par le public membre statique ObjectCache.De l'hôte. Ce n'est exposée à l'utilisateur de jouer avec s'il le veut, et j'ai été réellement en mesure de faire cette chose type de travail, comme il est censé le faire en s'inclinant ma propre IMemoryCacheManager mise en œuvre, la valeur ObjectCache.D'accueil, puis l'exécution de l'échantillon. À ce point, cependant, il semble que vous pourriez tout aussi bien faire votre propre cache de la mise en œuvre et même pas la peine avec tous ces trucs, surtout depuis que je n'ai aucune idée de si le réglage de votre propre classe pour ObjectCache.Hôte (statique, de sorte qu'il concerne chacun de ces qui pourraient être là-bas dans les processus) pour mesurer le cache pourrait gâcher d'autres choses.

Je crois qu'au moins une partie de celle-ci (si ce n'est un couple de pièces) est juste un droit en haut de bug. Ce serait bien de l'entendre de quelqu'un à MS ce qui se passait avec cette chose.

TLDR version de ce géant de réponse: Supposons que CacheMemoryLimitMegabytes est complètement arrêté à ce point dans le temps. Vous pouvez le mettre à 10 MO, et ensuite de remplir le cache à ~2 GO et souffler un souvenir d'exception avec pas de déclenchement de l'élément de retrait.

J'ai rencontré ce problème ainsi. Je suis la mise en cache des objets qui sont en cours de licenciement dans mon processus des dizaines de fois par seconde.

J'ai trouvé la configuration et l'utilisation de la libère les éléments, toutes les 5 secondes la plupart du temps.

App.config:

Prendre note de cacheMemoryLimitMegabytes. Lorsque cela a été fixée à zéro, la purge de routine ne serait pas le feu dans un délai raisonnable.

   <system.runtime.caching>
<memoryCache>
<namedCaches>
<add name="Default" cacheMemoryLimitMegabytes="20" physicalMemoryLimitPercentage="0" pollingInterval="00:00:05" />
</namedCaches>
</memoryCache>
</system.runtime.caching>  

L'ajout de cache:

MemoryCache.Default.Add(someKeyValue, objectToCache, new CacheItemPolicy { AbsoluteExpiration = DateTime.Now.AddSeconds(5), RemovedCallback = cacheItemRemoved });

Confirmant la suppression de cache est de travail:

void cacheItemRemoved(CacheEntryRemovedArguments arguments)
{
System.Diagnostics.Debug.WriteLine("Item removed from cache: {0} at {1}", arguments.CacheItem.Key, DateTime.Now.ToString());
}

J'ai fait quelques tests avec l'exemple de @Canacourse et la modification de @woany et je pense qu'il y a quelques critique des appels qui bloquent le nettoyage de la mémoire cache.

public void CacheItemRemoved(CacheEntryRemovedArguments Args)
{
//this WriteLine() will block the thread of
//the MemoryCache long enough to slow it down,
//and it will never catch up the amount of memory
//beyond the limit
Console.WriteLine("...");
//...
//this ReadKey() will block the thread of 
//the MemoryCache completely, till you press any key
Console.ReadKey();
}

Mais pourquoi la modification de @woany semble garder la mémoire au même niveau? Tout d'abord, la RemovedCallback n'est pas réglé et il n'y a pas de sortie de la console ou de l'attente pour une entrée qui pourrait bloquer le fil de la mémoire cache.

Deuxièmement...

public void AddItem(string Name, string Value)
{
//...
//this WriteLine will block the main thread long enough,
//so that the thread of the MemoryCache can do its work more frequently
Console.WriteLine("...");
}

Un Thread.Sleep(1) toutes les ~1000e AddItem() aurait le même effet.

Bien, elle n'est pas très profonde investigation du problème, mais il semble comme si le fil de la MemoryCache ne pas obtenir suffisamment de temps PROCESSEUR pour le nettoyage, tandis que de nombreux nouveaux éléments sont ajoutés.

Si vous utilisez la suite modifiés de classe et de surveiller la mémoire via le Gestionnaire des Tâches n'est en fait obtenir garnis:

internal class Cache
{
private Object Statlock = new object();
private int ItemCount;
private long size;
private MemoryCache MemCache;
private CacheItemPolicy CIPOL = new CacheItemPolicy();
public Cache(double CacheSize)
{
NameValueCollection CacheSettings = new NameValueCollection(3);
CacheSettings.Add("cacheMemoryLimitMegabytes", Convert.ToString(CacheSize));
CacheSettings.Add("pollingInterval", Convert.ToString("00:00:01"));
MemCache = new MemoryCache("TestCache", CacheSettings);
}
public void AddItem(string Name, string Value)
{
CacheItem CI = new CacheItem(Name, Value);
MemCache.Add(CI, CIPOL);
Console.WriteLine(MemCache.GetCount());
}
}