几乎每天都在同一时间段，我注意到内存被释放，由于我的DevOp技能非常有限，我无法弄清楚是什么原因造成的。
下面的图表显示了这种模式：
我的问题是：会导致什么？我很容易怀疑应该归咎于内存泄漏，但是...可用内存永远不会降到70％以下，而只会在流量最大的两个VM中发生！
我应该担心什么？看到这样的东西吗？
PS：我一直在为我们运行的每个Windows服务以及w3wp进程收集“私有e虚拟字节”的度量标准...尽管我已经读到，这些度量标准是确定内存是否泄漏不是很可靠，但是至少我会尝试获取某种趋势，并查看它是否与上面显示的模式相关。
#1 楼
我已经在其他系统中看到了相同的“锯齿”模式，尤其是基于Java的数据工具。根据您的描述，我认为您正在研究.NET垃圾收集（假设这是一个.NET应用程序。）Java和.NET都是内存管理语言和使用垃圾收集的框架。通常会在缺乏内存管理的框架中或在内存管理的框架中的程序中使内存垃圾收集器混乱或混乱，从而导致内存泄漏。
这些是您流量最高的事实服务器很有意义。您会看到.NET框架根据需要分配内存，然后垃圾回收器按常规周期启动，并使用垃圾回收算法回收未使用的内存。除非您要跟踪特定的性能问题，否则我认为这种内存使用模式不会有问题。
评论
这确实是一个.NET应用程序，根据我过去几天的研究，您和@Tensibai编写的内容非常有意义。
–AntónioSérgioSimões
17年5月10日在11:06
#2 楼
我想已经找到了为什么这张图看起来像这样。我也在收集ASP.NET应用程序/错误总性能计数器的指标，并且我注意到，与此同时，内存发生可用浪涌时，“总错误”度量标准重置为0。
根据msdn，每次应用程序重新启动/关闭时，此计数器重置为0。
这使我相信造成此“内存可用”锯齿模式的原因是由于应用程序重新启动。
我的图表如下：
UPDATE
发生这种情况是因为W3WP进程的“专用字节”达到了回收的限制（我们在应用程序池中配置了“专用字节”限制）。仔细查看Private Bytes图表，我们可以看到发生了一些异常，因为内存使用量从650MB跃升至3.2GB，几个小时后从3.6GB跃升至16.6GB！这是回收的时候。
评论
这是更合理的解释。突然的内存释放几乎只在进程重新启动时发生。释放正在运行的进程的内存的机制从来没有这么尖锐，很少真正释放内存，而不是释放预分配堆上的一些空间。
–吉里·克鲁达（Jiri Klouda）
17年5月15日在12:54
评论
您会看到通常的垃圾收集器或缓存清理恕我直言。您的网站用母语完成了吗？ （这可能是您的应用，您的网络服务器，甚至是进行一些清理的系统）我也对此感到怀疑...它是在ASP.NET MVC 4中完成的，因此垃圾收集理论是有道理的。另外，顺便提一下，我在w3wp进程和Windows服务上收集的指标看起来绝对正常。
我对ASP几乎一无所知，但是我认为有一种方法可以像Java中那样绘制内存消耗和垃圾回收图，这应该有助于确保这是根本原因。