垃圾收集每100秒

是否有人遇到过高内存分配负载的应用程序每100秒执行第二代收集的情况？

我们使用64位服务器和8-16 GB的物理内存.

应用程序有几GB的数据存储在缓存中,无法从中清除,因为它实际上是由应用程序使用的.另外它收到很多在处理过程中分配GEN 0对象的请求.

对我来说奇怪的是,GEN 2系列的表现就像时钟一样100秒.我认为它不太可预测

1> Marc Gravell..：

---

如果你的内存负载很高,并且使用了很多对象,那么是的:GC会忙碌...如果它正在击中gen-2,那么听起来你有很多中/长寿命的对象闲逛......

我假设内存使用率相当稳定？以上可能表明某种伪泄漏(可能通过静态事件等持有太多对象),或者只是意味着你的内存使用率很高!

你用了多少内存？你能考虑x64和大量的内存吗？或者,3gb交换机(x86)会为你多买几个字节吗？

---

最终我解决了它,显然我们在切换到服务器GC之后不再使用服务器GC,不再需要调用GC2.显然并发GC的假设是查找每秒分配的内存量,如果它高于它每100秒称为gen 2 GC的某个值

---

服务器GC模式没有任何基于时间的启发式方法,它会动态调整以反映您的分配率和生存对象.

2> leppie..：

---

如果您运行的是双核CPU,请尝试在app/web.config中设置GCServer ="true".

就我而言,它占原始GC的10%左右,应用程序感觉更加快捷.

3> user109878..：

---

发生像钟表甲第二代集合会建议无论是GC.Collect的方法被称为像钟表,或分配是像钟表.

除非分配或GC.Collect调用是真正随机的,否则您希望在垃圾收集中看到的随机性不太可能发生.

鉴于您的服务器应用程序处于如此高的负载,并且您在处理过程中创建了新对象,我会认真考虑重构代码,以查看在处理期间是否可以通过使用对象池来重新创建更少的对象.

对象池与大多数垃圾收集器的不同之处在于,池中的对象一旦被放回池中就可以重用,并且垃圾收集器需要在之前可以再次使用包含对象的前一块内存之前执行收集作为一个不同的对象.