windbg 故障转储分析，cpu 使用率高 -答案

【问题标题】：windbg crash dump analysis, high cpu usage -windbg 故障转储分析，cpu 使用率高 -
【发布时间】：2017-02-12 05:35:28
【问题描述】：

我的应用程序（web api）受到高 cpu 的影响，在分析转储时，我看到我的大多数线程都有这个 !dumpstack -:

  Child-SP         RetAddr          Caller, Callee
00000030497bec00 00007ffbb19e1118 KERNELBASE!WaitForSingleObjectEx+0x94, 

    calling ntdll!NtWaitForSingleObject
    00000030497beca0 00007ffba8375dda clr!CLRSemaphore::Wait+0xee, calling kernel32!WaitForSingleObjectEx
    00000030497becd0 00007ffba837345d clr!GCCoop::GCCoop+0xe, calling clr!GetThread
    00000030497bed60 00007ffba8375842 clr!ThreadpoolMgr::WorkerThreadStart+0x482, calling clr!CLRSemaphore::Wait
    00000030497bee00 00007ffba8393e1e clr!Thread::intermediateThreadProc+0x7d
    00000030497bee30 00007ffbb19e1f86 KERNELBASE!ConsoleCallServerGeneric+0xf2, calling KERNELBASE!_security_check_cookie
    00000030497bee50 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset
    00000030497beed0 00007ffbb450d0c6 ntdll!LdrpGetProcedureAddress+0x66, calling ntdll!RtlImageNtHeaderEx
    00000030497bef50 00007ffbb450c6f5 ntdll!LdrpResolveNonStaticDependency+0x1cd, calling ntdll!LdrpDereferenceNode
    00000030497befd0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf000 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset
    00000030497bf020 00007ffbb450f5f3 ntdll!LdrGetProcedureAddressForCaller+0x153, calling ntdll!_security_check_cookie
    00000030497bf030 00007ffb93fc8c84 mfc120u!DllMain+0x210, calling mfc120u!__security_check_cookie
    00000030497bf080 00007ffba8ce2cbb mscoreei!operator delete+0x34, calling kernel32!HeapFreeStub
    00000030497bf0d0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
    00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain
    00000030497bf1e0 00007ffb979dbc9d clrcompression!calloc_impl+0x5d, calling ntdll!RtlAllocateHeap
    00000030497bf210 00007ffb979d8eff clrcompression!initptd+0xb7, calling clrcompression!unlock
    00000030497bf230 00007ffbb44ebf57 ntdll!RtlDeactivateActivationContextUnsafeFast+0xc7, calling ntdll!_security_check_cookie
    00000030497bf240 00007ffb979d7919 clrcompression!CRT_INIT+0x135, calling kernel32!GetCurrentThreadId
    00000030497bf270 00007ffb979d7a0e clrcompression!__DllMainCRTStartup+0x8a, calling clrcompression!DllMain
    00000030497bf280 0000000056b32052 msvcr100!_initptd+0xaa, calling msvcr100!_unlock
    00000030497bf2a0 00007ffbac051779 IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0x679, calling IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0xf0
    00000030497bf2b0 0000000056b31308 msvcr100!__CRTDLL_INIT+0x16c, calling msvcr100!_CrtEndBoot
    00000030497bf2d0 00007ffbb450bee8 ntdll!LdrpReleaseModuleEnumLock+0x1c, calling ntdll!RtlReleaseSRWLockShared
    00000030497bf2e0 00007ffbb44ec0f4 ntdll!LdrpCallInitRoutine+0x4c
    00000030497bf300 00007ffbb450be9b ntdll!LdrpReleaseLoaderLock+0x27, calling ntdll!LdrpReleaseModuleEnumLock
    00000030497bf340 00007ffbb44ebe53 ntdll!LdrpInitializeThread+0x1f3, calling ntdll!LdrpReleaseLoaderLock
    00000030497bf3b0 00007ffbb44ebd93 ntdll!LdrpInitializeThread+0x133, calling ntdll!RtlActivateActivationContextUnsafeFast
    00000030497bf3b8 00007ffbb44ebdc6 ntdll!LdrpInitializeThread+0x166, calling ntdll!RtlDeactivateActivationContextUnsafeFast
    00000030497bf420 00007ffbb44e8d73 ntdll!_LdrpInitialize+0x93, calling ntdll!NtTestAlert
    00000030497bf490 00007ffbb44e8c98 ntdll!LdrInitializeThunk+0x18, calling ntdll!NtContinue
    00000030497bf900 00007ffba8393e07 clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk
    00000030497bf940 00007ffbb43613d2 kernel32!BaseThreadInitThunk+0x22
    00000030497bf970 00007ffbb44e54e4 ntdll!RtlUserThreadStart+0x34

我的疑惑在于这 3 行 -:

ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext
00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain

这个线程会不会是 CPU 使用率高的原因？

【问题讨论】：

我已经运行了 !runaway 命令，这是堆栈跟踪之一.. 它们是具有相同堆栈跟踪的许多线程.. 只是想了解这个堆栈跟踪试图告诉什么..虽然我怀疑，这个线程是CPU使用的罪魁祸首..
是的。这是否回答你的问题？线程是在 CPU 上执行的，所以是线程使用 CPU 时间并制造高 CPU。与记忆相反。内存不在CPU上执行，所以不会造成高CPU的麻烦。也许您想重新表述问题以获得适合您需求的答案。
WinDbg 是一个很棒的工具，但 imo 不适合这项工作。它只能为您提供有关某个特定时间点的信息。为了更好地全面了解您的应用程序正在做什么，您应该使用诸如 ETW （或 procmon） 之类的东西并从中得出结论。也就是说，你似乎在压缩一些东西，所以我会 expect 高 CPU。
它是 webapi 调用.. web api 做 gzip 压缩（基于配置）.. 我怎样才能看到压缩是什么，这实际上是真正的问题..？
是的。如果您继续挖掘和搜索，您最终会发现 WinDbg 不是这项工作的正确工具，您需要另一个像 ETW 这样的工具;)

标签： memory gzip windbg

【解决方案1】：

您要运行的第一个 WinDBG 命令是：!runaway。
此命令将显示哪个线程使用 CPU 的时间最长。
收到此命令的输入后，我们可以向前思考关于这是怎么回事...

【讨论】：

如果 !runaway 使用率很高，则线程当前可能会执行与高 CPU 原因完全无关的事情。 !runaway 会产生许多误报。
@Thomas: !runaway 显示了哪个线程使用 CPU 的时间最长，从应用程序开始开始。如果您的可执行文件正在消耗 CPU，那么 !runaway 应该在列表的开头显示最有问题的线程，这将帮助您分析正在执行的密集任务。我用了很多次，从来没有遇到过误报。
那么您很幸运，您捕获了当前执行正确堆栈时的状态。 !runaway 可能会报告一个在 3 天前处于活动状态但目前什么都不做的线程。
这是我感到困惑的地方...上面的线程，我提供的堆栈跟踪在过去 13 小时内根据转储处于活动状态，查看跟踪似乎它什么都不做并等待让 clr 提供一些工作.. 但就我而言，它不应该长时间处于非活动状态，或者它实际上卡在我不知道的某个地方..
是的，就像我上面提到的那样.. 70 左右有很多线程处于相同的状态..

【解决方案2】：

Windbg 不是这项工作的正确工具。转储只是快照，因此您不知道之前发生了什么。使用 ETW 并在此处使用 CPU 采样，它汇总所有调用并详细显示 CPU 使用情况。

安装 Windows 性能工具包，它是 Windows 10 SDK 的一部分（V1607 works on Win8/8.1(Server2012/R2) 和 Win10 或 V1511 SDK，如果您使用 Windows 7/Server2008R2)），运行 WPRUi.exe并选择CPU Usage

然后按Start。捕获 1 分钟的高 CPU 使用率，然后单击 Save。使用 WPA.exe（Perf 分析器）打开生成的 ETL，将 CPU Usage (Sampled) 图形拖放到分析窗格中

和load the Debug Symbols。现在在图中选择您的进程，放大并展开堆栈，这里您可以看到所有调用的 CPU 使用权重

在此示例中，Internet Explorer 的大部分 CPU 使用来自 HTML 内容。

对于 .NET 应用程序，WPA 向您显示 .net 相关的分组，例如 GC 或 JIT：

【讨论】：

生产环境有问题，支持不允许安装工具。
支持很可能不知道 ETW 是什么。向他们解释这是 Microsoft 用于对系统进行故障排除的方法，including production systems。如果您仍然不允许 xcopy 启动跟踪所需的文件，我会将案例交给他们或询问他们的偏好：添加您自己的重量级日志记录以进一步分析问题或使用轻量级内置日志记录Microsoft 提供的。
ETW 是生产中最好的支持工具，该工具可以通过 xcopied 复制到服务器，您也可以使用 comamndlin 版本的脚本。 .每个说 ETW 不好的人都是没有受过教育的巨魔。你的支持应该被解雇
另请注意，Microsoft 提供了内置于 Windows 的工具，允许在不同的机器上捕获和分析这些 ETW 跟踪。例如，logman 应默认安装。另一个用于分析捕获的 ETL 文件的有用工具是PerfView。

【解决方案3】：

在任何分析后设置正确的符号路径。
在 File->Symbol File Path 菜单中设置： YOUR_SYMBOLS_PATH;OTHERS_PATH;SRVC:\symcachehttp://msdl.microsoft.com/download/symbols

尝试使用以下命令查看托管堆栈：

.cordll -ve -u -l ld* !EEStack

【讨论】：

您认为 !EEStack 比 !DumpStack 有什么好处？如何解决性能问题？
用于显示一些可能导致问题根源的相关信息。对于那些通常调查崩溃的人来说，这很重要。

【解决方案4】：

根据文章 - http://msdn.microsoft.com/en-us/library/bb742546.aspx 我不应该关注这个线程.. 因为它正在等待并且可能处于睡眠模式 -WaitForSingleObjectEx 并且睡眠不会导致 cpu 使用..

如果有人处于相同情况，请提供更多资源-： https://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment

https://msdn.microsoft.com/en-IN/library/ms182372.aspx

【讨论】：