CaliEventHandlerDelegateProxy 泄漏
CaliEventHandlerDelegateProxy leaking
我们的网站出现问题，似乎随机（大约每天一次，最多每 7-10 天一次）网站会变得无响应。
我们在 Azure 上有两个 Web 服务器，我们使用 Redis。
我已经设法 运行 DotNetMemory 并在它崩溃时捕获了它，我观察到 Event handlers leak 在网站停止工作之前，两个项目的数量似乎增加到数千。这两项是 CaliEventHandlerDelegateProxy 和 ArglessEventHandlerProxy。一旦站点崩溃，我们会收到很多无法连接到 Redis 服务器的 Redis 异常。根据 Azure 门户，我们的 Redis 服务器负载在高峰时段从未超过 10%，我们正在遵循所有最佳实践。
我花了很长时间浏览我们的网站，以确保没有明显的内存泄漏，并修补了一些不为人知的案例。有趣的是，这些似乎稍微提高了网站的稳定性。我们检查过的内容：
- 所有 iDisposable 对象现在都包裹在 using 块中（我们之前严格这样做，但我们确实发现了一些未正确处理的对象）
- 事件处理程序已取消订阅 - 我们的代码库中很少
- 我们大量使用 WebUserControls。每一个都将当前母版页作为参数传入。我们已经删除了对此的依赖，因为我们认为它可能导致 GC 可能不收集页面
我们的最新问题是，当网络服务器 运行 正常时，但随后我们 运行 DotNetMemory 并将其附加到 w3wp.exe 进程，它导致 CaliEventHandlerDelegateProxy ArglessEventHandlerProxy 事件泄漏迅速增加，直到站点崩溃！因此，仅通过 运行ning DotNetMemory 即可重现崩溃。这是我们看到的截图：
我现在不知所措，我相信我已经用尽了我们代码库中内存泄漏的所有可能性，我们的 "solution" 是让应用程序池每隔几个小时回收一次，以便在安全的一面。
我们甚至尝试将 Redis 升级到高级层，甚至将网络服务器上的所有驱动器升级到 SSD 以查看它是否有助于它似乎没有的东西。
任何人都可以阐明可能导致这些问题的原因吗？
All iDisposable objects are now wrapped in using blocks (we did this
strictly before but we did find a few not disposed properly)
我们不能在没有任何关于它的信息的情况下就崩溃说太多，但我对此有一些猜测。
我看到 10 000 (!) 个未处理的对象由终结队列处理。让我们从它们开始，找到它们并在您的应用程序中添加 Dispose 调用。
我还建议检查您的应用程序使用了多少系统句柄。句柄数量有一个 OS 限制，如果超过，则无法创建更多的文件句柄、网络套接字等。我特别推荐它，因为未处理对象的数量。
此外，如果您在访问 Redis 时超时，请获取性能分析器并查看原因。我建议获取 JetBrains dotTrace 并使用 TIMELINE 模式来获取您的应用程序的配置文件，它将显示线程休眠、线程争用以及更多有助于您找到问题根源的信息.您可以使用命令行工具获取配置文件数据，以免在服务器端安装 GUI 应用程序。
it causes the CaliEventHandlerDelegateProxy and
ArglessEventHandlerProxy event leaks to increase rapidly
dotMemory 不会更改您的应用程序代码，也不会在分析过程中分配任何托管对象。 Microsoft Profiling API 在profiling过程中注入一个dll（用c++编写），它是dotMemory的一部分，命名为Profilng Core，扮演着"server"的角色（其中用C#编写的独立dotMemory是一个客户端).分析核心在将收集的数据发送到客户端之前对收集的数据进行一些处理，它需要一些内存，当然，这些内存分配在分析过程的地址 space 中，但它不会影响托管内存。
内存分析可能会影响应用程序的性能。例如，当应用程序正在分析或内存分配数据收集会显着降低您的应用程序时，分析 API 会禁用并发 GC。
您为什么认为 CaliEventHandlerDelegateProxy 和 ArglessEventHandlerProxy 仅在 dotMemory 分析下分配？能否请您描述一下您是如何对此进行探索的？
Event handlers are unsubscribed - there are very few in our code base
dotMemory 将事件处理程序报告为泄漏，这意味着只有一个对它的引用 - 来自事件源，无法取消订阅此事件。检查所有这些泄漏，找到你的泄漏，看看代码是如何发生的。无论如何，这些对象只保留了 110.3 KB，你为什么决定你的网站因为它们而崩溃？
I'm at a loss now, I believe I've exhausted all possibilities of memory leaks in our code base
在内存消耗增长的一段时间内拍几张快照，打开其中一些快照的完整比较，查看所有不应该存活的存活对象，找出它们存活的原因。这是唯一能证明你的应用没有内存泄漏的方法，看代码并不能证明，抱歉。
希望如果您执行我建议您执行的所有活动（性能分析、完整快照和快照比较调查，不仅是检查视图，检查为什么有大量未处理的对象）您会找到并修复根本问题。
我们的网站出现问题，似乎随机（大约每天一次，最多每 7-10 天一次）网站会变得无响应。
我们在 Azure 上有两个 Web 服务器，我们使用 Redis。
我已经设法 运行 DotNetMemory 并在它崩溃时捕获了它，我观察到 Event handlers leak 在网站停止工作之前，两个项目的数量似乎增加到数千。这两项是 CaliEventHandlerDelegateProxy 和 ArglessEventHandlerProxy。一旦站点崩溃，我们会收到很多无法连接到 Redis 服务器的 Redis 异常。根据 Azure 门户，我们的 Redis 服务器负载在高峰时段从未超过 10%，我们正在遵循所有最佳实践。
我花了很长时间浏览我们的网站，以确保没有明显的内存泄漏，并修补了一些不为人知的案例。有趣的是，这些似乎稍微提高了网站的稳定性。我们检查过的内容：
- 所有 iDisposable 对象现在都包裹在 using 块中（我们之前严格这样做，但我们确实发现了一些未正确处理的对象）
- 事件处理程序已取消订阅 - 我们的代码库中很少
- 我们大量使用 WebUserControls。每一个都将当前母版页作为参数传入。我们已经删除了对此的依赖，因为我们认为它可能导致 GC 可能不收集页面
我们的最新问题是，当网络服务器 运行 正常时，但随后我们 运行 DotNetMemory 并将其附加到 w3wp.exe 进程，它导致 CaliEventHandlerDelegateProxy ArglessEventHandlerProxy 事件泄漏迅速增加，直到站点崩溃！因此，仅通过 运行ning DotNetMemory 即可重现崩溃。这是我们看到的截图：
我现在不知所措，我相信我已经用尽了我们代码库中内存泄漏的所有可能性，我们的 "solution" 是让应用程序池每隔几个小时回收一次，以便在安全的一面。
我们甚至尝试将 Redis 升级到高级层，甚至将网络服务器上的所有驱动器升级到 SSD 以查看它是否有助于它似乎没有的东西。
任何人都可以阐明可能导致这些问题的原因吗？
All iDisposable objects are now wrapped in using blocks (we did this strictly before but we did find a few not disposed properly)
我们不能在没有任何关于它的信息的情况下就崩溃说太多，但我对此有一些猜测。 我看到 10 000 (!) 个未处理的对象由终结队列处理。让我们从它们开始，找到它们并在您的应用程序中添加 Dispose 调用。 我还建议检查您的应用程序使用了多少系统句柄。句柄数量有一个 OS 限制，如果超过，则无法创建更多的文件句柄、网络套接字等。我特别推荐它，因为未处理对象的数量。
此外，如果您在访问 Redis 时超时，请获取性能分析器并查看原因。我建议获取 JetBrains dotTrace 并使用 TIMELINE 模式来获取您的应用程序的配置文件，它将显示线程休眠、线程争用以及更多有助于您找到问题根源的信息.您可以使用命令行工具获取配置文件数据，以免在服务器端安装 GUI 应用程序。
it causes the CaliEventHandlerDelegateProxy and ArglessEventHandlerProxy event leaks to increase rapidly
dotMemory 不会更改您的应用程序代码，也不会在分析过程中分配任何托管对象。 Microsoft Profiling API 在profiling过程中注入一个dll（用c++编写），它是dotMemory的一部分，命名为Profilng Core，扮演着"server"的角色（其中用C#编写的独立dotMemory是一个客户端).分析核心在将收集的数据发送到客户端之前对收集的数据进行一些处理，它需要一些内存，当然，这些内存分配在分析过程的地址 space 中，但它不会影响托管内存。
内存分析可能会影响应用程序的性能。例如，当应用程序正在分析或内存分配数据收集会显着降低您的应用程序时，分析 API 会禁用并发 GC。 您为什么认为 CaliEventHandlerDelegateProxy 和 ArglessEventHandlerProxy 仅在 dotMemory 分析下分配？能否请您描述一下您是如何对此进行探索的？
Event handlers are unsubscribed - there are very few in our code base
dotMemory 将事件处理程序报告为泄漏，这意味着只有一个对它的引用 - 来自事件源，无法取消订阅此事件。检查所有这些泄漏，找到你的泄漏，看看代码是如何发生的。无论如何，这些对象只保留了 110.3 KB，你为什么决定你的网站因为它们而崩溃？
I'm at a loss now, I believe I've exhausted all possibilities of memory leaks in our code base
在内存消耗增长的一段时间内拍几张快照，打开其中一些快照的完整比较，查看所有不应该存活的存活对象，找出它们存活的原因。这是唯一能证明你的应用没有内存泄漏的方法，看代码并不能证明，抱歉。
希望如果您执行我建议您执行的所有活动（性能分析、完整快照和快照比较调查，不仅是检查视图，检查为什么有大量未处理的对象）您会找到并修复根本问题。