CaliEventHandlerDelegateProxy泄漏

Question

我们在我们的网站上有一个问题，似乎是随机的(每天左右，最多每7-10天一次)网站将变得没有反应。

我们在Azure上有两个web服务器，我们使用Redis。

我成功地运行了DotNetMemory，并在它崩溃时捕捉到了它，我观察到的是，在Event handlers leak下，在网站停止工作之前，有两个项目的数量似乎增加到数千个。这两个项目是CaliEventHandlerDelegateProxy和ArglessEventHandlerProxy。一旦站点崩溃，我们就会得到很多Redis异常，它们无法连接到Redis服务器。根据Azure Portal的说法，我们的Redis服务器负载在高峰时刻从未超过10%，我们正在遵循所有的最佳实践。

我花了很长时间浏览我们的网站，确保没有明显的内存泄漏，并修补了一些未被关注的案例。有趣的是，这些似乎改善了网站的稳定性。我们查过的东西：

所有的properly)

• Event对象现在都被封装在使用块中(我们以前严格地这样做过，但是我们确实发现了一些未处理的处理程序是未订阅的--在我们的代码库
• 中很少使用WebUserControls，我们使用的WebUserControls相当多)。每个母版页都将当前母版页作为参数传入。我们已经删除了对此的依赖，因为我们认为它可能导致GC不收集页面，也许是

我们最近的问题是，当web服务器正常运行时，我们运行DotNetMemory并将其附加到w3wp.exe进程中，这会导致CaliEventHandlerDelegateProxy和ArglessEventHandlerProxy事件泄漏迅速增加，直到站点崩溃！因此，只要运行DotNetMemory，就可以复制崩溃。下面是我们看到的截图：

​

​

我现在不知所措，我相信我已经用尽了代码库中内存泄漏的所有可能性，我们的“解决方案”是让应用程序池每隔几个小时循环一次，以保持安全。

我们甚至尝试过将Redis升级到高级层，甚至将We服务器上的所有驱动器升级到SSD，看看它是否有帮助，而它似乎没有帮助。

有人能说明是什么导致了这些问题吗？

Answer 1

所有的iDisposable对象现在都被包装在使用块中(我们以前严格地这样做过，但是我们确实发现有一些没有正确地处理)

在没有任何信息的情况下，我们不能说很多关于坠机的事情，但我有一些猜测。我看到一万(!)未释放由终结队列处理的对象。让我们从它们开始，找到它们，并在您的应用程序中添加Dispose调用。此外，我建议检查您的应用程序使用了多少系统句柄。对句柄的数量有操作系统限制，如果超出它们，就可以创建文件句柄、网络套接字等。我推荐它，特别是考虑到未释放对象的数量。

另外，如果您有访问Redis的超时时间，请获取性能分析器，并查看原因。我建议获取JetBrains dotTrace并使用时间线模式获取应用程序的配置文件，它将显示线程休眠、线程争用和许多其他信息，这些信息将帮助您找到问题根源。您可以使用命令行工具获取配置文件数据，以避免在服务器端安装GUI应用程序。

导致CaliEventHandlerDelegateProxy和ArglessEventHandlerProxy事件泄漏迅速增加。

dotMemory不会更改应用程序代码，也不会在配置过程中分配任何托管对象。在分析过程中注入一个dll (用c++编写)，它是dotMemory的一部分，名为Profiling，扮演“服务器”的角色(其中用C#编写的独立dotMemory是客户端)。分析Core在将收集到的数据发送到客户端之前做一些工作，它需要一些内存，这当然是在分析过程的地址空间中分配的，但它不会影响托管内存。

内存分析可能会影响应用程序的性能。例如，分析API在应用程序处于分析或内存分配数据收集时禁用并发GC，可以显著降低应用程序的速度。为什么CaliEventHandlerDelegateProxy和ArglessEventHandlerProxy只在dotMemory分析下分配？你能描述一下你是如何探索这个的吗？

事件处理程序是未订阅的-在我们的代码库中很少。

dotMemory将事件处理程序报告为泄漏，这意味着只有一个引用--来自事件源的引用不可能取消订阅该事件。检查所有这些漏洞，看看代码是如何发生的。不管怎么说，这些对象只保留了110.3 KB，为什么您决定您的站点因为它们而崩溃呢？

我现在不知所措了，我相信我已经用尽了我们代码库中内存泄漏的所有可能性

在内存消耗增加的一段时间内拍摄几张快照，打开这些快照的全部比较，查看所有不应该生存的幸存对象，并找出它们存活的原因。这是证明您的应用程序没有内存泄漏的唯一方法，查看代码并不能证明这一点，对不起。

希望如果您执行我建议您做的所有活动(性能分析、完整快照和快照比较调查，而不仅仅是检查视图，检查为什么有大量未释放的对象)，您将找到并修复根本问题。