調試，CPU使用率過高

所以，我對我們的生產環境中的問題，即2個線程已經運行了像9小時5小時，他們所造成的CPU佔用率保持在99％調試，CPU使用率過高

我已經包括了從堆棧跟蹤！Clrstack和kb 2000 我一直在google等等......徘徊，我找不到任何東西可以幫助我找出這些線程正在做什麼以及爲什麼他們在資源上消耗如此之多

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

來源

2009-11-06 Shane

你有代碼，改爲分享？ – marcc 2009-11-06 19:50:01

張貼的callstack沒有代碼就沒用了。小心編輯並提供一些？如果沒有它，任何人都可以幫助你。 – 2009-11-06 19:54:35

如果我能找到導致問題的代碼，我不需要問這個問題......這是一個Web應用程序，它有200,000行代碼，當前運行的51個線程和100個併發用戶。我試圖使用WinDbg來確定代碼是什麼......那些調用堆棧跟蹤來自2個線程，它們處於繁忙的等待循環中，使用了cpu ......我所知道的在這一點上該怎麼做是知道的導致問題並打印調用棧的線程。如果您有任何關於如何發現有問題的代碼可幫助我解決問題的信息...... – Shane 2009-11-06 20:05:47

如果你可以附加一個調試器，那麼行爲異常的線程通常會是你在'Break Al L」。

否則，我可能會採取一堆線程位置快照，並查看是否有任何線程始終不在等待（即WaitForMultipleObjectEx）。這應該讓你知道哪些線程行爲不當，以及他們通常運行哪些代碼。

並確保你沒有像任何代碼：

while(1) 
    ;

來源

2009-11-06 19:56:21 Aaron

我知道導致問題的2個線程。！當我做暴走他們是在列表頂部失控 41：34200天5：31：57.781 48：3450天1：23：23.421 但我在一個失去了辯別瞭解爲什麼這兩個線程都在堅持，他們究竟在做什麼，以及代碼是由哪些代碼創建的...... 如果還有其他的事情你知道，我可以做的就是弄清楚創建這些線程的真棒： - ） – Shane 2009-11-06 20:08:11

您可以隨時與調試器停止處理，並檢查堆棧跟蹤了幾次。如果一個線程經常不在空閒並且處於同一個位置，那麼您將更多地瞭解它在所有時間花費的位置。

在你粘貼的東西，我只看到一個線程的堆棧跟蹤，你可以得到所有線程的堆棧跟蹤？（對不起，如果是這樣，我已經習慣在unix中做這件事了）

來源

2009-11-06 20:03:53

是的，我已經這樣做了......所有其他線程正在運行和退出，並做他們做得很好....只是這2個線程是堅持和使用了100％的CPU。目前是負載平衡，我有所有流量指向一個不同的網站，所以違規網站現在有零負載，只有這2個線程是活躍的，並用盡資源 – Shane 2009-11-06 20:11:00

使用ProcDump可以在CPU處於高電平時獲取內存轉儲。然後檢查所有線程的調用堆棧。同時運行perfmon並繼續檢查使用大部分CPU的線程。希望這有助於

來源

2009-11-06 21:48:24 Naveen

同時檢查％時間花費在GC在perfmon – Naveen 2009-11-06 21:49:39

是啊我有一個內存轉儲。 CPU不斷高漲...它只是坐在99％......我用perfmon來檢查正在運行的線程，並且只有2個線程正在忙着運行（上面公佈的那些線程）。每個線程有完全相同的內存啞和clrstack轉儲（上面公佈），每個線程分別佔用資源的50％... 但我不知道接下來要做什麼提示這些什麼提示兩個線程正在做或他們來自哪裏 – Shane 2009-11-06 22:55:50

％在GC上花費的時間不是那麼高，它保持在0.2左右，我不認爲這是高... – Shane 2009-11-06 23:40:54

好吧，讓我找到了問題我做了！clrstack -p 和比！做對system.net部分，它揭示了問題的線索是一個System.net.Servicepoint指着我們SMTP服務器..

周圍一派，發現這是問題 http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=337557 這裏還描述 http://www.vbforums.com/showthread.php?t=584384 這是一個問題的服務點不正確地發送quit命令和斷開..這，他們會解決.net 4.0

現在我只是在解決方法代碼，以確保服務點靠攏，並應制定出

感謝大家的幫助

來源

2009-11-07 08:57:51 Shane

+1的位置......感謝您的跟蹤！ – 2009-11-07 12:45:59

沒有問題如果有人很好奇這個魔術修復是什麼...我找到了2個方法 1）只使用IIS皮卡 2） client.ServicePoint.MaxIdleTime = 1; client.ServicePoint.ConnectionLimit = 1; – Shane 2009-11-07 18:25:26

調試，CPU使用率過高

回答

相關問題