【发布时间】：2018-07-27 03:59:47
【问题描述】：
我有内存泄漏，仅在生产中发生（webapp (Asp.Net MVC)）。
我想用 dotMemory（或类似工具）拍摄内存快照，看看发生了什么。
但是我不确定这是否会导致生产暂停并弄乱当前的任何请求。
我的机器上有 32 GB 的 RAM
所以我的问题是：
我能否获得内存快照而不会阻碍/影响请求？
【问题讨论】：
标签： production-environment dotmemory
【发布时间】：2018-07-27 03:59:47
【问题描述】：
是的，dotMemory 和任何其他通过 Microsoft Profiling API 工作的内存分析器都会暂停应用程序一段时间，从几毫秒到几分钟不等，具体取决于内存中的数据量。
我建议使用标准的 Windows 内存转储，在正常情况下也需要一些时间，但有一种技术可以帮助避免它。 然后您可以在 dotMemory 或任何其他支持 Windows 内存转储的工具中对其进行分析。
当我在运行内部 Team Foundation Server (TFS) 时 微软，我们有时遇到的问题只能是 通过分析内存转储来理解。这在 运行 Beta 版之前的 Pioneer 和 Dogfood 服务器。如果 问题足够严重（崩溃、内存泄漏等）以至于它 需要内存转储，这可能意味着它很快就需要它 我们可以回收应用程序池并使服务器健康 再次。
转储 ASP.NET 应用程序池的问题在于，所有 应用程序池使用 w3wp.exe 进程名称。所以，在你可以之前 取转储，您需要确定哪个进程对应于 您定位的应用程序池。如果你看不出来 在进程所有者处（例如服务帐户/应用程序池身份）。这 简单（但缓慢）的方法是打开任务管理器并添加 显示的“命令行”列。然后你会看到每个 w3wp.exe 进程的命令行中的应用程序池名称。
应用程序池消耗大量资源的另一个问题 内存，就是进程会暂停很长一段时间 内存被转储到磁盘。如果这比配置的时间长 ASP.NET 进程“ping 时间”，然后 IIS 将终止您的进程（并且 开始一个新的）在转储中途，你会失去你的再现。
为了解决这个问题，在 Sysinternals Procdump.exe。它利用了 Windows 7/Windows 的功能 2008 R2 “克隆”一个进程以获取转储并取消挂起 原始过程比正常速度更快。
-r Reflect (clone) the process for the dump to minimize the time
the process is suspended (Windows 7 and higher only).
然后我们可以使用 IIS 管理工具来查找进程 ID 一个特定的应用程序池，现在我们有一个简单的批处理文件，我们可以 放在我们的 TFS 服务器的桌面上以便快速访问。
DumpTfsAppPool.cmd 创建如下批处理文件并将其放入 与 Procdump.exe 相同的目录。不要忘记创建/更新路径 到转储位置。
%windir%\system32\inetsrv\appcmd list wps /apppool.name:"Microsoft
Team Foundation Server Application Pool" /text:WP.NAME >
"%temp%\tfspid.txt"
:: ProcDump.exe (faster, reflects/clones the process for the dump to
minimize the time the process is suspended (Windows 7 and higher
only))
for /F %%a in (%temp%\tfspid.txt) do "%~dp0\procdump.exe" -accepteula
-64 -ma -r %%a f:\dumps pause
【讨论】：