服务器模式GC似乎永远收集0代堆 [英] Server mode GC seems to never collect Gen 0 Heap

问题描述

澄清的问题（TL; DR）

阅读和分析所有下面介绍的结果后，这个问题似乎归结为在GC不收集第0级堆为我们的应用程序服务器模式下，只要其变更为工作站模式问题消失。

After reading and profiling with all the results covered below, the problem seems to boil down to the GC not collecting Gen 0 Heap for our applications when in Server mode, as soon as its changed to Workstation mode the problem goes away.

原来的问题和细节

我的问题有所涉及：的这个问题和这个问题

My question is somewhat related to:This question and this question.

我们最近遇到了什么似乎是在我们在我们的测试环境.NET应用程序的内存泄漏，工作进程将上升要么迅速绕到450MB的使用无负载下下负荷或时，逐步时。

We recently ran into what seemed to be a memory leak in our .NET applications on our test environments, the worker processes would climb to around 450MB usage either quickly when under load or gradually when under no load.

问题不能在我们的开发环境复制的，主要差别在于dev的环境是物理服务器，而测试环境是虚拟化和由木偶（从控制开我没有环境本身）的许多知识。

The problem could not be replicated on our development environments, the primary difference being that the dev environments are physical servers whereas the test environments are virtualized and controlled by Puppet (apart from that I do not have much knowledge of the environments themselves).

在为了希望看到哪些对象负责占用了所有的内存，我跑蚂蚁内存分析器上测试服务器，我发现所有的记忆被其余为未使用，并从来没有被释放。

In order to hopefully see what objects were responsible for taking up all that memory I ran Ants Memory Profiler on the test server, I found that all of that memory was remaining as unused and was never being released.

虽然研究这是什么原因，我碰到的这个论坛帖子这反过来又使我的这篇文章。

While researching what could cause this I came across this forum post which in turn lead me to this article.

最后我想它建议使用的配置，把GC进入工作站模式：

I ended up trying the configuration it recommends, to put the GC into workstation mode:

<configuration>
  <runtime>
    <gcServer enabled="false"/>
    <gcConcurrent enabled="false"/>
  </runtime>
</configuration>

运行IISRESET并重新运行我的记忆分析问题完全消失，这是伟大的，但仍然没有按后'吨真的解释是摆在首位发生。

After running iisreset and re running my memory profiling the issue was completely gone, which is great but still doesn't really explain what was happening in the first place.

我做一些更多的阅读和发现的这太问题，这使我相信，此配置更改可能最终会有损于我们的吞吐量的应用。

I did do some more reading and found this SO question, which leads me to believe that this configuration change may end up being detrimental to the throughput of our applications.

所以我的问题是：什么会导致IIS工作进程积累，永远不会被垃圾收集了大量未使用的内存

So my question is: What would cause an IIS worker process to accumulate a large amount of unused memory that never gets garbage collected?

编辑：
要澄清我的问题有点多，我认为我们已经证明，该代码是不负责，因为完全相同的代码不会遇到这种问题的开发环境。

To clarify my question a bit more, I believe we have proven that the code is not responsible for this, as the exact same code does not experience this issue on the dev environment.

下面是我把我的内存分析的前后配置更改后的截图，没有大量的信息在这里，但图确实显示了存储趋势很好。

Here are the screenshots I took of my memory profiling before and after the configuration change, there isn't a lot of information here but the graph does show the memory trend nicely.

修改2：
下面是从我可以收集服务器的规格，我都不可能得到更多的只是需要时间

Edit 2: Here are the server specs from what I could gather, I can possibly get more will just take time.

开发环境：
物理机
CPU：单芯
。内存：6GB

Dev Environment: Physical Machine CPU: Single core Memory: 6GB

测试环境：
虚拟机
CPU：4逻辑线程（我不能CPU计数评论）
。内存：8GB

Test Environment: Virtual Machine CPU: 4 Logical threads (I cannot comment on CPU count) Memory: 8GB

在Machine.config文件的唯一区别是，开发环境是增加
Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior这两个端点和服务的行为。

The only difference in the Machine.Config files is that the dev environment is adding "Microsoft.VisualStudio.Diagnostics.ServiceModelSink.Behavior" to both endpoint and service behaviours.

和目前的测试环境具有前面提到的GC设置。在aspnet.config文件

And the test environment currently has the GC settings previously mentioned in the aspnet.config file.

修改3：
做了一些更多的分析，发现一对夫妇更计数器，我可以添加蚂蚁之内，尤其是我加0代堆大小，它看起来像这是问题的根源。随着服务器模式的GC，当我触发我使用剖析该行立即跳起来测试到300MB〜然后回来到230MB〜但从未追溯到一路走低（下图）。

Edit 3: Did some more profiling and noticed a couple more counters that I could add within Ants, notably I added "Gen 0 heap size" and it looks like this is the source of the issues. With the GC in server mode when I trigger the test I'm using for profiling this line immediately jumps up to ~300MB then comes back down to ~230MB but never goes all the way back down (graph below).

运行在工作站模式下的GC同样分析认为刘根0堆的大小有一个更小的初始峰值，当请求完成回返回到基本为零（下图）。

Running the same profiling with the GC in workstation mode sees the Gen 0 heap size have a much smaller initial spike and return back to essentially zero when the requests have finished (graph below).

做一些更多的搜索这一带我到另一个多更多相关SO的问题，但是他的发现是，该内存使用量是一个非的问题，而在我的情况下，服务实际需要手动重新启动，每天至少一次。

Doing some more searching on this lead me to another much more related SO question, however his findings were that this memory usage was a non issue, whereas in my case the service actually needs to be manually restarted at least once a day.

我还发现的rel=\"nofollow\">有以下就这个问题说了（这似乎说明发生了什么几乎完美：

I also found this article that had the following to say on the issue (which seems to describe what is happening almost perfectly:

0代很可能有一个较大的数字对象的64位系统上，特别是当你使用服务器的垃圾收集，而不是工作站垃圾回收。这是因为阈值，以触发0代垃圾收集是在这些环境中更高，和第0代集合可以得到更大。当应用程序分配更多的内存垃圾收集被触发之前的性能得到改进。

Generation 0 is likely to have a larger number of objects on a 64-bit system, especially when you use server garbage collection instead of workstation garbage collection. This is because the threshold to trigger a generation 0 garbage collection is higher in these environments, and generation 0 collections can get much bigger. Performance is improved when an application allocates more memory before a garbage collection is triggered.

虽然问题仍然存在，在服务器模式下代而不是只是不经常0堆看似永远不会收集。

Though the problem still remains that in Server mode the Generation 0 heap is seemingly never collected as opposed to just not as often.

推荐答案

经过反复研究，阅读和分析我一直能够证明我们的IIS的内存使用情况实际上是在标准范围内;这是使用Sysinternals的测试极限实用程序服务器的物理内存使用率推至最高接近完成，一旦这样做是所有的应用程序发布了自己的记忆。

After much research, reading, and profiling I have been able to prove that our IIS memory usage is actually within the standard; this was done using the SysInternals Test Limit utility to push the server's physical memory usage to near max, once this was done all of our applications released their memory.

我们做的还有某种记忆问题在我们的测试环境，我需要调查，但在这一点上我想我可以自信地说，这是完全无关的。

We do still have some kind of memory issue in our test environment that I need to investigate but at this point I think I can confidently say that this is entirely unrelated.

这个故事告诉我们是不是认为这个问题报告的原因是正确的。

Moral of the story is to not assume that the cause reported with the issue is correct.

这篇关于服务器模式GC似乎永远收集0代堆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！