【问题标题】:Azure Web App Memory Leaks ResearchAzure Web 应用程序内存泄漏研究
【发布时间】:2018-06-01 07:34:19
【问题描述】:

问题: 在我的一个网络项目中,我在网络应用程序上遇到了一些难题。 我们为我们的系统使用了 Azure Web App 服务。曾几何时,我们遇到了任何大型应用程序最头疼的问题——内存泄漏。 当您使用简单的桌面应用程序或在虚拟机上发布您的应用程序时 - 有很多不同的方法 - 如何捕获泄漏。 您可以安装不同的监控和诊断解决方案并实时捕捉。

但是,当您使用 Azure Web 应用程序时,您应该怎么做? (或任何其他网络服务,这真的会切断您的诊断机会)。 最好的方法 - 获取转储并研究它。您会在任何网站、评论和博客上看到此建议。 但是您必须花费很多时间才能找到任何信息,您可以如何做到这一点。

所以我只想从有关 Web 应用程序内存泄漏研究的大量信息中提取内容。 当然,我会提供与 Azure 有关的最多信息,但本地转储研究信息您可以应用于任何其他平台。

【问题讨论】:

    标签: c# azure memory web memory-leaks


    【解决方案1】:

    回答:

    如何识别内存泄漏

    应用滞后 - 不是最佳和安全的答案)您应该在 azure 门户上监控您的诊断统计信息(更多信息在这里 - https://docs.microsoft.com/en-gb/azure/monitoring-and-diagnostics/

    如何从 Azure Web App 捕获转储。

    每个 Azure Web 应用都有自己的沙箱 - 一个环境。您可以使用“.scm”后缀访问它。例如,如果您的站点域是“latvianmarksman.azurewebsites.net”,那么您的 sanbox 地址:“latvianmarksman.scm.azurewebsites.net em>”。 您应该通过您的天蓝色凭据登录。 在 Azure Web App Sandbox 上,您可以找到不同的有用信息:

    1. 工具 > 支持。您可以在此处找到事件、诊断图和 进行当前内存转储(分析 > 指标)。 Azure 将花费一些 是时候获取转储了,并进行简单的分析。你可以下载 在“分析 > 诊断”页面上转储和分析报告;

    2. 调试 > Cmd。您可以找到 Your Web App 的任何本地文件。有用的 当您在本地编写自定义日志或遇到问题时 与网络应用程序大小;

    3. 进程导出器。此选项卡可以为您提供有关主要的信息 Web App Sandbox 的进程,也在此选项卡上您可以获得和 也下载转储;

    4. 网站扩展。您可以安装不同的站点扩展 研究您的问题;

    5. 工具 > 诊断转储。第三种制作转储的方法;

    如何处理 Azure Web 应用转储。

    当您的问题很简单时 - 您可以在 Web App Events 或简单的 Dump Analize 中找到答案; 但是要解决更复杂的问题,您应该进行真正的深度转储分析。 最正向的方式:使用Win Dbg。

    首先让我们谈谈其他信息来源:

    1. 您可以从 Azure 分析中获取一些切碎但有时有用的信息
      报告(在 dump lynk 附近的“工具>支持”选项卡中下载)。
    2. DebugDiag2 - 下载转储分析的好工具;
    3. 您还可以使用 MS Visual Studio 对转储进行简单分析。
      • 您只能分析托管内存;
      • 您只能在 MS Studio 的专业版或企业版(不是免费社区)上进行分析;
    4. Azure Web 应用程序诊断:仅 azure Web 应用程序计数器信息。
      • Azure 不那么频繁地刷新此计数器;
      • Azure 提供大致信息;
    5. Azure Sql 诊断:仅 azure sql 计数器信息。
      • Azure 不那么频繁地刷新此计数器;
      • Azure 提供大致信息;
      • 如果您现在需要计数器值,请使用下一个脚本:
        SELECT sqltext.TEXT, req.session_id, req.status, req.command, req.cpu_time, req.total_elapsed_time, req.* FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS sqltext

    但无论如何,关于任何困难的内存泄漏的最完整信息你都可以使用 WinDbg 捕获; 该工具结合了高级接口和低级分析能力) WinDbg 使用了很多库,但其中最重要的是: -netext

    我们应该如何处理转储:

    1. 了解哪些内存(托管或非托管泄漏)

      • 托管内存泄漏,当对象没有正确销毁时,通常意味着垃圾收集器问题。在这个泄漏上你会在高级缓存中发现很多对象;
      • 非托管内存泄漏,通常意味着未正确释放非托管资源。在这个泄漏上你会发现堆的不规则使用; 只需下载 Azure Dump Analyze 并找到 GC 部分和 Heap 部分,对其进行分析并指定泄漏类型; 如果它管理内存泄漏或您不理解它的类型 - 转到 2 点) 或者如果是非托管内存泄漏则转到 3 点;
    2. 分析托管内存 使用 MS Visual Studio(如果您有专业版或企业版)。调试托管内存。
      您可以找到哪些对象使用最多的托管内存。
      如果您没有 MS Visual Studio(专业版或企业版) - 尝试使用 Azure 分析报告、使用标准 Windows 转储分析、DebugDiag2 或使用 WinDbg; 互联网上的所有 WinDbg 信息都是关于托管内存分析的。例如: https://stackify.com/using-windbg-to-analyze-net-crash-dumps-async-crash/

    3. 分析非托管内存 很难找到有关这种内存泄漏类型的任何信息。 WinDbg 也可以在这里为我们提供帮助。你可以在这里阅读关于它的非常酷的文章: http://kate-butenko.blogspot.ru/2012/07/investigating-issues-with-unmanaged.html

    我的 WinDbg 帮助文件

    • 设置符号:.sympath SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols 

    • 加载 netext 库:.load netext

    • 索引转储文件:!windex

    • 获取netext命令列表,当然使用你的路径:.cmdtree C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\netext.tl

    • 获取堆信息,所有对象>2Mb:!dumpheap -stat -min 2000

    • 获取堆信息,所有对象>2Mb,将结果写入文件:.logopen C:\DumpAnalyse\crash.log; !dumpheap -stat -min 2000; .logclose;

    • 修复加载符号时出现的问题: .symfix+ C:\localsymbols.reload

    • 获取对象信息:!address -summary

    • 获取 GC 信息(托管内存分析):!eeheap -gc

    附言

    对于沙漠:我们的应用有什么问题?)

    1. 非托管和托管内存同时出现问题;
    2. 在托管内存中,我们只有很多一种类型的对象。我们在我们的项目中使用了 SignalR,因此它是位于高级现金对象之上的 SignalR 对象(GC 不会清理)。当然,很多时候我们认为这是 SignalR 问题,内部或我们的代码中。
      但是解决 SignalR 使用的所有问题并没有帮助(应用程序崩溃很少发生,但确实会发生)。有时应用程序只是溢出内存,仅此而已。因此,经过数小时的研究,我偶然发现了有关非托管内存的文章,在接下来的几个小时后,我找到了 Kates 的文章。
    3. 然后我发现我们也有堆内存溢出。因此,当我使用 WinDbg 进入堆时,我发现了这样的字符:“S.y.s.t.e.m..T.h.r.e.a.d.i.n.g..E.x.c.e.p.t.i.o.n”。 只是标准异常文本字符串。许多异常线程字符串。
      我们使用 log4net 日志记录服务器异常。 所以,问题是 signalR 在某些情况下会周期性地向服务器发送 500 垃圾邮件,因此 log4net 试图将此 stackTrace 写入日志并溢出服务器; + stackTraces 保留托管内存对象,因此您在两种内存类型中都有问题。 修复这种情况会引发内存泄漏。所以我现在睡得很好)

    我希望这些信息对您有用。没有泄漏,没有头痛,睡得很好,重复)

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-02-20
      • 1970-01-01
      • 2012-11-09
      • 2012-05-05
      • 1970-01-01
      • 1970-01-01
      • 2020-07-25
      • 2011-10-09
      相关资源
      最近更新 更多