Windbg 调试高cpu使用率

因此，我在我们的生产环境中遇到了一个问题，其中两个线程已经运行了9小时和5小时，导致cpu使用率保持在99%左右

我已经包含了来自的堆栈跟踪！Clrstack和kb 2000 我一直在谷歌搜索等等。。。永远，我找不到任何东西可以帮助我弄清楚这些线程在做什么，以及它们为什么要消耗这么多资源

0:048> !clrstack
OS Thread Id: 0x345c (48)
ESP       EIP     
01e5f068 7c8285ec [HelperMethodFrame_1OBJ: 01e5f068] System.Threading.WaitHandle.WaitOneNative(Microsoft.Win32.SafeHandles.SafeWaitHandle, UInt32, Boolean, Boolean)
01e5f114 792b687f System.Threading.WaitHandle.WaitOne(Int64, Boolean)
01e5f130 792b6835 System.Threading.WaitHandle.WaitOne(Int32, Boolean)
01e5f144 7a9390a2 System.Net.ConnectionPool.CleanupCallback()
01e5f154 7a938fc3 System.Net.ConnectionPool.CleanupCallbackWrapper(Timer, Int32, System.Object)
01e5f184 7aa97f5f System.Net.TimerThread+TimerNode.Fire()
01e5f1cc 7a584c84 System.Net.TimerThread+TimerQueue.Fire(Int32 ByRef)
01e5f20c 7a55db8b System.Net.TimerThread.ThreadProc()
01e5f25c 792d6cf6 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
01e5f268 792f5611 System.Threading.ExecutionContext.runTryCode(System.Object)
01e5f698 79e71b4c [HelperMethodFrame_PROTECTOBJ: 01e5f698] System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)
01e5f700 792f5507 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
01e5f71c 792e0175 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
01e5f734 792d6c74 System.Threading.ThreadHelper.ThreadStart()
01e5f960 79e71b4c [GCFrame: 01e5f960] 
01e5fc50 79e71b4c [ContextTransitionFrame: 01e5fc50] 



0:048> kb 2000
ChildEBP RetAddr  Args to Child              
01e5edf8 7c827cfb 77e6202c 00000001 01e5ee48 ntdll!KiFastSystemCallRet
01e5edfc 77e6202c 00000001 01e5ee48 00000000 ntdll!NtWaitForMultipleObjects+0xc
01e5eea4 79f4c88a 00000001 01e5f0e4 00000001 kernel32!WaitForMultipleObjectsEx+0x11a
01e5ef0c 79f4c4bb 00000001 01e5f0e4 00000001 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
01e5ef2c 79f4c5c4 00000001 01e5f0e4 00000001 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
01e5efb0 79f4c659 00000001 01e5f0e4 00000001 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
01e5f000 79f159e8 00000001 01e5f0e4 00000001 mscorwks!Thread::DoAppropriateWait+0x40
01e5f104 792b687f 00000000 00000000 00000000 mscorwks!WaitHandleNative::CorWaitOneNative+0x156
01e5f120 792b6835 00000000 00000000 7aa3488c mscorlib_ni+0x1f687f
01e5f138 7a9390a2 00000000 21b09738 01e5f168 mscorlib_ni+0x1f6835
01e5f14c 7a938fc3 041c7bcc 00000000 00000000 System_ni+0x4f90a2
01e5f178 7aa97f5f 041c7bcc 1b790a40 1b790a40 System_ni+0x4f8fc3
01e5f1c4 7a584c84 00000000 21b09738 01e5f224 System_ni+0x657f5f
01e5f204 7a55db8b 0a62018c 0574ea00 00000000 System_ni+0x144c84
01e5f254 792d6cf6 22124c7c 01e5f270 792f5611 System_ni+0x11db8b
01e5f260 792f5611 00000000 1b790a40 01e5f280 mscorlib_ni+0x216cf6
01e5f270 79e71b4c 00000000 00000000 01e5f300 mscorlib_ni+0x235611
01e5f280 79e821b1 01e5f350 00000000 01e5f320 mscorwks!CallDescrWorker+0x33
01e5f300 79e96501 01e5f350 00000000 01e5f320 mscorwks!CallDescrWorkerWithHandler+0xa3
01e5f444 79e96534 79241ff0 01e5f578 01e5f498 mscorwks!MethodDesc::CallDescr+0x19c
01e5f460 79e96552 79241ff0 01e5f578 01e5f498 mscorwks!MethodDesc::CallTargetWorker+0x1f
01e5f478 79f8a3e1 01e5f498 57d102af 1b790a40 mscorwks!MethodDescCallSite::CallWithValueTypes+0x1a
01e5f644 79f8a536 01e5f6d4 57d1021f 22124cc4 mscorwks!ExecuteCodeWithGuaranteedCleanupHelper+0x9f
01e5f6f4 792f5507 01e5f698 0574ea6c 06cc1310 mscorwks!ReflectionInvocation::ExecuteCodeWithGuaranteedCleanup+0x10f
01e5f710 792e0175 041c7828 01e5f76c 0574ea6c mscorlib_ni+0x235507
01e5f728 792d6c74 041c7828 00000000 1b790a40 mscorlib_ni+0x220175
01e5f740 79e71b4c 77e40000 00000000 01e5f7d0 mscorlib_ni+0x216c74
01e5f750 79e821b1 01e5f820 00000000 01e5f7f0 mscorwks!CallDescrWorker+0x33
01e5f7d0 79e96501 01e5f820 00000000 01e5f7f0 mscorwks!CallDescrWorkerWithHandler+0xa3
01e5f90c 79e96534 7924290c 01e5fa68 01e5f9a0 mscorwks!MethodDesc::CallDescr+0x19c
01e5f928 79e96552 7924290c 01e5fa68 01e5f9a0 mscorwks!MethodDesc::CallTargetWorker+0x1f
01e5f940 79f3d803 01e5f9a0 57d10fc3 1b790a40 mscorwks!MethodDescCallSite::CallWithValueTypes+0x1a
01e5fb28 79e9845f 01e5fe50 1b790a40 00000000 mscorwks!ThreadNative::KickOffThread_Worker+0x192
01e5fb3c 79e983fb 01e5fdc4 01e5fbc4 79f7759b mscorwks!Thread::DoADCallBack+0x32a
01e5fbd0 79e98321 01e5fdc4 57d108e7 1b790a40 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3
01e5fc0c 79fd876a 01e5fdc4 1b790a40 01e5fccc mscorwks!Thread::ShouldChangeAbortToUnload+0x30a
01e5fc1c 79fd96f9 01e5fdc4 01e5fcc0 79f7759b mscorwks!Thread::RaiseCrossContextException+0x434
01e5fccc 79fd878b 00000003 79fd8756 01e5fdc4 mscorwks!Thread::DoADCallBack+0xda
01e5fce8 79e983fb 01e5fdc4 01e5fd70 79f7759b mscorwks!Thread::DoADCallBack+0x310
01e5fd7c 79e98321 01e5fdc4 57d10953 00000000 mscorwks!Thread::ShouldChangeAbortToUnload+0xe3
01e5fdb8 79e984ad 01e5fdc4 00000003 00000000 mscorwks!Thread::ShouldChangeAbortToUnload+0x30a
01e5fde0 79f3d5d4 00000003 79f3d6e9 01e5fe50 mscorwks!Thread::ShouldChangeAbortToUnload+0x33e
01e5fdf8 79f3d6ae 00000003 79f3d6e9 01e5fe50 mscorwks!ManagedThreadBase::KickOff+0x13
01e5fe94 79f92015 1bb9e468 80a5e56d 80865927 mscorwks!ThreadNative::KickOffThread+0x269
01e5ffb8 77e64829 0014d9c0 00000000 00000000 mscorwks!Thread::intermediateThreadProc+0x49
01e5ffec 00000000 79f91fcf 0014d9c0 00000000 kernel32!BaseThreadStart+0x34

---

如果您可以附加一个调试器，那么行为不端的线程通常就是“全部中断”时出现的线程

否则，我可能会拍摄一组线程位置快照，并查看是否有任何线程始终不处于等待状态（即WaitForMultipleObjectEx）。这应该让您了解哪些线程行为不正常，以及它们通常运行的代码

并确保您没有以下代码：

while(1)
  ;

---

：）

您始终可以使用调试器停止进程，并多次检查堆栈跟踪。如果一个线程经常不处于空闲状态，并且处于同一位置，那么您将更多地了解它在哪里花费时间

在你粘贴的东西中，我只看到一个线程的堆栈跟踪，你能得到所有线程的堆栈跟踪吗？

---

（很抱歉，如果这太离谱了，我通常习惯在unix中这样做）

用于在CPU高峰值时获取内存转储。然后检查所有线程的调用堆栈。同时运行perfmon并不断检查占用大部分CPU的线程。希望这有帮助，好吧，我找到了问题所在 我做了一个测试 !clrstack-p 而不是一个！在system.net部分上执行，发现有问题的线程是指向smtp服务器的system.net.Servicepoint

谷歌搜索发现这就是问题所在 这里也有描述 这是服务点未正确发送quit命令和断开连接的问题。。他们将在.NET4.0中解决这些问题

现在，我只需编写变通方法代码，以确保服务点关闭，这应该可以解决问题

---

谢谢大家的帮助

你有代码可以共享吗？如果没有代码，发布的调用堆栈是无用的。想编辑并提供一些吗？如果没有它，任何人都不能帮助你。如果我能找到导致问题的代码，我就不需要问这个问题了。。。这是一个web应用程序，大约有200000行代码，51个线程正在运行，100个并发用户。我正在尝试使用WinDbg来确定代码是什么。。。这些调用堆栈跟踪来自使用cpu的繁忙等待循环中的2个线程。。。。此时我所知道的就是知道导致问题的线程并打印调用堆栈。。如果您对我如何发现有问题的代码有什么见解，可以帮助我解决…“2个线程处于繁忙等待循环中”？那么，“繁忙等待循环”中的代码是什么？我怀疑你在做一些愚蠢的事情，比如在常量while循环中调用Sleep（）或其他什么，但是如果没有代码，怀疑只是一个骗局。我的意思是，如果你知道wndbg中有任何其他命令，我可以运行这些命令来揭示有关代码的更多信息。。我洗耳恭听：-）但这是我目前所能从生产服务器上运行的进程推断出的知识集中绝对最多的。我知道导致问题的两个线程。当我这样做的时候！逃跑他们在名单的首位！失控41:3420 0天5:31:57.781 48:345c 0天1:23:23.421但我搞不清楚为什么这两个线程会粘在一起，它们到底在做什么，以及是哪一行代码创建了它们。。。。如果你知道我还能做些什么来找出是什么创造了这些线程，那就太棒了：-）是的，我已经做到了。。。所有其他线程都在运行和退出，并且做得很好。。。。只是这两个线程一直在使用，占用了100%的cpu。当前是负载平衡的，我将所有流量定向到另一个站点，因此有问题的站点现在没有负载，只有这两个线程处于活动状态，并且正在使用资源。因此，请检查性能中在GC上花费的时间百分比。我有一个内存转储。cpu一直处于高位。。。它只是坐在百分之九十九。。。我使用perfmon检查正在运行的线程，只有2个线程正在忙碌地运行（上面发布的那些线程的CLR堆栈）。每个线程都有完全相同的内存dumb和clrstack转储（见上文），每个线程分别占用50%的资源。。。但我不知道下一步该怎么做才能得到关于这两个线程正在做什么或它们来自何处的任何提示。花费在GC上的时间百分比并没有那么高，它保持在0.2左右，我认为没有那么高……我看到的调用堆栈只有线程id 48。另一个呢？是的，它们看起来都一样，所以我想我应该发布其中一个+1。。。感谢您的关注！没问题，如果有人想知道魔法修复是什么。。。我找到了两种方法1）只使用IIS拾取2）client.ServicePoint.MaxIdleTime=1；client.ServicePoint.ConnectionLimit=1；