【发布时间】：2017-02-22 03:10:19
【问题描述】：
我怀疑我可能在 WebJob 中存在内存泄漏，但我不确定如何明确证明我这样做。我怀疑我可以通过转到 Kudu 管理控制台中的 /processExplorer 找到信息，启动配置文件并下载结果。但是，我不完全确定这是否是要走的路线，或者一旦我得到它应该如何处理该文件。
任何建议将不胜感激。
【问题讨论】：
标签： azure azure-webjobs azure-web-app-service
【发布时间】：2017-02-22 03:10:19
【问题描述】：
我可以通过转到 Kudu 管理控制台中的 /processExplorer 找到信息，启动配置文件并下载结果
获得 .diagsession 文件后，您可以使用 Visual Studio 打开它。您将看到 CPU 使用趋势，但内存数据不包含在此文件中。为了轻松识别是否存在内存泄漏，以下步骤供您参考。
- 手动及时刷新 kudu 上的 Process Explorer（例如每 30 秒一次）。
- 刷新 Process Explorer 后，需要记录私有内存和虚拟内存，用于诊断内存泄漏。点击进程名称后的属性按钮，可以看到当前进程的私有内存和虚拟内存。
- 记录足够的数据后，需要比较虚拟内存和私有内存的增长速度。如果虚拟内存和私有内存都增长得很快，或者虚拟内存增长得比私有内存快，则意味着存在内存泄漏。
如果您需要更多关于内存泄漏的信息，您可以从进程属性页面下载内存转储文件，并使用 WinDbg 查看它的详细信息。您还可以使用 Azure 网站的诊断即服务在线分析转储文件。有关如何使用它的更多信息。以下链接供您参考。
【讨论】：
-
我能够使用 DaaS 看到我有一堆占用资源的孤立线程。感谢您指出 DaaS。
-
@RobReagan 您如何确保 Azure 处理了孤立线程？
-
@zgirod，我们的问题是我们正在根据每个请求从 WebJob 创建到 Hub 的新连接。使用 SignalR 2.2.0 时，这会导致连接和线程成为孤立的问题。我们更改了连续 WebJob 中的逻辑，以便我们只建立一次代理连接，然后重用该连接与我们的 Hub 对话。这解决了我们的问题。
-
@RobReagan 非常感谢您的回复。我正在努力解决一些内存问题，无法弄清楚它到底是什么。不使用集线器，所以有些不同..
-
@zgirod，抱歉 - 我刚刚在这里阅读了整个线程并意识到它不是 SignalR 特定的。您是否访问过 Web 应用程序的诊断和解决问题刀片并仔细查看应用程序事件和失败的请求跟踪日志？这是一个很好的起点。此外，每个实例（应用程序）的指标可以显示您是否有失控的内存泄漏（如果您尚未明确确定）。 Mitigate 选项非常适合设置内存阈值并自动终止进程、进行内存转储并为您分析转储。