MemoryCache 不遵守配置中的内存限制

Question

我正在使用 .NET 4.0 MemoryCache 应用程序中的类并尝试限制最大缓存大小，但在我的测试中，缓存实际上并未遵守限制。

我正在使用的设置 根据 MSDN，应该限制缓存大小：

1. CacheMemoryLimitMegabytes：对象实例可以增长到的最大内存大小（以兆字节为单位）。”
2. PhysicalMemoryLimitPercentage: "缓存可以使用的物理内存的百分比，表示为 1 到 100 之间的整数值。默认为零，表示 MemoryCache 实例根据计算机上安装的内存量管理自己的内存¹。” ^{1.这并不完全正确 - 任何低于 4 的值都会被忽略并替换为 4。}

我知道这些值是近似值，而不是硬性限制，因为清除缓存的线程每 x 秒触发一次，并且还取决于轮询间隔和其他未记录的变量。然而，即使考虑到这些差异，当在设置 CacheMemoryLimitMegabytes 和 PhysicalMemoryLimitPercentage 一起或单独设置后，从缓存中逐出第一个项目时，我发现缓存大小非常不一致。测试应用程序。可以肯定的是，我将每个测试运行了 10 次并计算了平均值。

这些是在具有 3GB RAM 的 32 位 Windows 7 PC 上测试以下示例代码的结果。每次测试中第一次调用 CacheItemRemoved() 后都会获取缓存的大小。 （我知道缓存的实际大小会比这个大）

MemLimitMB    MemLimitPct     AVG Cache MB on first expiry    
   1            NA              84
   2            NA              84
   3            NA              84
   6            NA              84
  NA             1              84
  NA             4              84
  NA            10              84
  10            20              81
  10            30              81
  10            39              82
  10            40              79
  10            49              146
  10            50              152
  10            60              212
  10            70              332
  10            80              429
  10           100              535
 100            39              81
 500            39              79
 900            39              83
1900            39              84
 900            41              81
 900            46              84

 900            49              1.8 GB approx. in task manager no mem errros
 200            49              156
 100            49              153
2000            60              214
   5            60              78
   6            60              76
   7           100              82
  10           100              541

这是测试应用程序：

using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Linq;
using System.Runtime.Caching;
using System.Text;
namespace FinalCacheTest
{       
    internal class Cache
    {
        private Object Statlock = new object();
        private int ItemCount;
        private long size;
        private MemoryCache MemCache;
        private CacheItemPolicy CIPOL = new CacheItemPolicy();

        public Cache(long CacheSize)
        {
            CIPOL.RemovedCallback = new CacheEntryRemovedCallback(CacheItemRemoved);
            NameValueCollection CacheSettings = new NameValueCollection(3);
            CacheSettings.Add("CacheMemoryLimitMegabytes", Convert.ToString(CacheSize)); 
            CacheSettings.Add("physicalMemoryLimitPercentage", Convert.ToString(49));  //set % here
            CacheSettings.Add("pollingInterval", Convert.ToString("00:00:10"));
            MemCache = new MemoryCache("TestCache", CacheSettings);
        }

        public void AddItem(string Name, string Value)
        {
            CacheItem CI = new CacheItem(Name, Value);
            MemCache.Add(CI, CIPOL);

            lock (Statlock)
            {
                ItemCount++;
                size = size + (Name.Length + Value.Length * 2);
            }

        }

        public void CacheItemRemoved(CacheEntryRemovedArguments Args)
        {
            Console.WriteLine("Cache contains {0} items. Size is {1} bytes", ItemCount, size);

            lock (Statlock)
            {
                ItemCount--;
                size = size - 108;
            }

            Console.ReadKey();
        }
    }
}

namespace FinalCacheTest
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            int MaxAdds = 5000000;
            Cache MyCache = new Cache(1); // set CacheMemoryLimitMegabytes

            for (int i = 0; i < MaxAdds; i++)
            {
                MyCache.AddItem(Guid.NewGuid().ToString(), Guid.NewGuid().ToString());
            }

            Console.WriteLine("Finished Adding Items to Cache");
        }
    }
}

为什么MemoryCache不遵守配置的内存限制？

Answer 1

哇，所以我花了太多时间在带有反射器的 CLR 中进行挖掘，但我想我终于很好地掌握了这里发生的事情。

设置读取正确，但 CLR 本身似乎存在一个根深蒂固的问题，看起来它会使内存限制设置基本上毫无用处。

反映在 System.Runtime.Caching DLL 中，用于 CacheMemoryMonitor 类（有一个类似的类，用于监视物理内存并处理其他设置，但这是更重要的一个）：

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);
}

以下代码 值得注意的是，它甚至不会尝试查看缓存的大小，直到 Gen2 垃圾回收之后，而只是回退到 cacheSizeSamples 中现有的存储大小值。所以你永远无法直接击中目标，但如果其余部分有效，我们至少可以在遇到真正的麻烦之前测量一下尺寸。

因此，假设发生了 Gen2 GC，我们就会遇到问题 2，即 ref2.ApproximateSize 在实际近似缓存大小方面做得很糟糕。通过 CLR 垃圾，我发现这是一个 System.SizedReference，这就是它获取值的方式（IntPtr 是 MemoryCache 对象本身的句柄）：

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

我假设 extern 声明意味着它会进入非托管状态windows 此时登陆，我不知道如何开始了解它在那里做什么。根据我的观察，它在尝试近似整体大小方面做得很糟糕。

第三件值得注意的事情是对 manager.UpdateCacheSize 的调用，这听起来像是应该做一些事情。不幸的是，在任何正常的示例中，s_memoryCacheManager 将始终为空。该字段是从公共静态成员 ObjectCache.Host 设置的。如果用户愿意的话，这是可以暴露给用户的，而且我实际上能够通过将我自己的 IMemoryCacheManager 实现放在一起，将其设置为 ObjectCache.Host，然后运行示例来使这件事像预期的那样工作。 。不过，在这一点上，您似乎也可以制作自己的缓存实现，甚至不用理会所有这些东西，特别是因为我不知道是否将您自己的类设置为 ObjectCache.Host （静态，因此它会影响每个测量缓存可能会搞乱其他事情。

我必须相信，至少其中一部分（如果不是几个部分）只是一个直接的错误。很高兴能听到 MS 的人告诉我们这件事的处理情况。

这个巨大答案的 TLDR 版本：假设 CacheMemoryLimitMegabytes 在此时完全失效。您可以将其设置为 10 MB，然后继续将缓存填充到 ~2GB，并抛出内存不足异常，而不会触发项目删除。

Answer 2

我知道这个答案太晚了，但迟到总比不好。我想让您知道，我编写了一个 MemoryCache 版本，可以自动为您解决 Gen 2 Collection 问题。因此，只要轮询间隔表明内存压力，它就会进行调整。如果您遇到此问题，请尝试一下！

http://www.nuget.org/packages/SharpMemoryCache

如果满足以下条件，您还可以在 GitHub 上找到它：你很好奇我是如何解决这个问题的。代码有点简单。

https://github.com/haneytron/sharpmemorycache

Answer 3

我也遇到过这个问题。我正在缓存每秒数十次被发射到我的进程中的对象。

我发现以下配置和用法大部分时间每 5 秒释放一次项目。

App.config：

记下cacheMemoryLimitMegabytes。当此值设置为零时，清除例程将不会在合理的时间内触发。

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

添加到缓存：

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

确认缓存删除正在工作：

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

Answer 4

我已经用@Canacourse 的示例和@woany 的修改做了一些测试，我认为有一些关键调用会阻止内存缓存的清理。

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();
}

但为什么@woany的修改似乎使内存保持在同一水平？首先，RemovedCallback 未设置，并且没有控制台输出或等待输入，这可能会阻塞内存缓存的线程。

其次...

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("...");
}

每约 1000 个 AddItem() 执行一次 Thread.Sleep(1) 会产生相同的效果。

好吧，这并不是对问题的深入调查，但看起来好像 MemoryCache 的线程没有获得足够的 CPU 时间来进行清理，同时添加了许多新元素。

Answer 5

我（幸运的是）昨天第一次尝试使用 MemoryCache 时偶然发现了这篇有用的文章。我认为这将是设置值和使用类的简单情况，但我遇到了上面概述的类似问题。为了尝试看看发生了什么，我使用 ILSpy 提取了源代码，然后设置了测试并逐步执行代码。我的测试代码与上面的代码非常相似，所以我不会发布它。从我的测试中，我注意到缓存大小的测量从来都不是特别准确（如上所述），并且考虑到当前的实现永远不会可靠地工作。然而，物理测量很好，如果每次轮询都测量物理内存，那么在我看来，代码会可靠地工作。因此，我删除了 MemoryCacheStatistics 中的第 2 代垃圾收集检查；在正常情况下，不会进行内存测量，除非自上次测量以来又进行了第 2 代垃圾回收。

在测试场景中，这显然会产生很大的差异，因为缓存不断被命中，因此对象永远没有机会到达第 2 代。我认为我们将在我们的项目中使用此 dll 的修改版本，并使用官方 MS当 .net 4.5 发布时构建（根据上面提到的连接文章应该有修复）。从逻辑上讲，我可以理解为什么要进行第 2 代检查，但实际上我不确定它是否有意义。如果内存达到 90%（或已设置的任何限制），则无论是否发生第 2 代收集都无关紧要，无论如何，项目都应被逐出。

我让测试代码运行了大约 15 分钟，并将physicalMemoryLimitPercentage 设置为 65%。我看到测试期间内存使用率保持在 65-68% 之间，并且看到事物被正确驱逐。在我的测试中，我将 pollingInterval 设置为 5 秒，将physicalMemoryLimitPercentage 设置为 65，将physicalMemoryLimitPercentage 设置为 0 以默认此设置。

遵循上述建议； IMemoryCacheManager 的实现可以从缓存中逐出内容。然而，它会受到提到的第 2 代检查问题的影响。不过，根据具体情况，这在生产代码中可能不是问题，并且可能对人们来说足够有效。

Answer 6

事实证明这不是一个错误，你需要做的就是设置池化时间跨度来强制执行限制，似乎如果你不设置池化，它永远不会触发。我刚刚测试了它，不需要包装器或任何额外的代码：

 private static readonly NameValueCollection Collection = new NameValueCollection
        {
            {"CacheMemoryLimitMegabytes", "20"},
           {"PollingInterval", TimeSpan.FromMilliseconds(60000).ToString()}, // this will check the limits each 60 seconds

        };

根据缓存增长的速度设置“PollingInterval”的值，如果增长太快，则增加轮询检查的频率，否则保持检查不那么频繁，以免造成开销。

Answer 7

如果您使用以下修改后的类并通过任务管理器监视内存实际上会被修剪：

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());
    }
}