最大承载CPU负载的自托管WCF服务

Question

我正在研究WindowsService在使用16个CPU的计算机上占用100％CPU的问题。

该服务托管一个自托管的.NET WCF服务。

我已收到一个崩溃转储，该文件已在windbg中加载，以寻找线索。

所以我尝试了：

• ！threads：

  线程数：646UnstartedThread：0BackgroundThread：643待处理线程：0死线程：2托管运行时：否642个线程是Threadpool工作器，如下所示：8 29 2a34 000000002068b510 3029220可抢占0000000000000000：00000000000000 0000000000563f50 0 MTA（线程池工作者）

• 〜29s->！CLRStack

  000000003c66eb70 00000000770512fa [GCFrame：000000003c66eb70]000000003c66ec40 00000000770512fa [GCFrame：000000003c66ec40]000000003c66ec78 00000000770512fa [HelperMethodFrame：000000003c66ec78] System.Threading.Monitor.Enter（System.Object）000000003c66ed70 000007fef7af1c9c System.Threading.TimerQueueTimer.Fire（）000000003c66ede0 000007fef7a6c2f3 System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem（）000000003c66ee30 000007fef7a6c92a System.Threading.ThreadPoolWorkQueue.Dispatch（）000000003c66f388 000007fef8d57d33 [DebuggerU2MCatchHandlerFrame：000000003c66f388]

• 〜29s-> K

  000000003c66e858 000007fefd7010dc ntdll！NtWaitForSingleObject + 0xa000000003c66e860 000007fef8d049bf KERNELBASE！WaitForSingleObjectEx + 0x79000000003c66e900 000007fef8d04977 clr！CLREventBase :: WaitEx + 0x16c000000003c66e940 000007fef8d048f8 clr！CLREventBase :: WaitEx + 0x103000000003c66e9a0 000007fef8e9c5de clr！CLREventBase :: WaitEx + 0x70000000003c66ea30 000007fef8dc5a34 clr！WKS :: GCHeap :: WaitUntilGCComplete + 0x2b000000003c66ea60 000007fef8d0c4f4 clr！Thread :: RareDisablePreemptiveGC + 0x176000000003c66eaf0 000007fef8dd1f3d clr！GCCoop :: GCCoop + 0x3d000000003c66eb20 000007fef8e898cf clr！AwareLock :: Contention + 0x137000000003c66ebe0 000007fef7af1c9c clr！JITutil_MonContention + 0xaf000000003c66ed70 000007fef7a6c2f3 mscorlib_ni + 0x521c9c000000003c66ede0 000007fef7a6c92a mscorlib_ni + 0x49c2f3000000003c66ee30 000007fef8d57d33 mscorlib_ni + 0x49c92a000000003c66eef0 000007fef8d556e6 clr！CallDescrWorkerInternal + 0x83000000003c66ef30 000007fef8d557af clr！CallDescrWorkerWithHandler + 0x4a000000003c66ef70 000007fef8eda2c9 clr！MethodDescCallSite :: CallTargetWorker + 0x2e6000000003c66f120 000007fef8ee51b0 clr！QueueUserWorkItemManagedCallback + 0x2a000000003c66f200 000007fef8ee513e clr！DebuggerU2MCatchHandlerFrame :: DebuggerU2MCatchHandlerFrame + 0xa0000000003c66f240 000007fef8ee50b5 clr！ManagedPerAppDomainTPCount :: DispatchWorkItem + 0x38e000000003c66f340 000007fef8ee51eb clr！ManagedPerAppDomainTPCount :: DispatchWorkItem + 0x2bd000000003c66f3d0 000007fef8eda224 clr！ManagedPerAppDomainTPCount :: DispatchWorkItem + 0x23b000000003c66f430 000007fef8ee6baf clr！ManagedPerAppDomainTPCount :: DispatchWorkItem + 0xb4000000003c66f5c0 000007fef8ee6ab3 clr！ThreadpoolMgr :: ExecuteWorkRequest + 0x4c000000003c66f5f0 000007fef8eda8a6 clr！ThreadpoolMgr :: WorkerThreadStart + 0xf3000000003c66f6b0 0000000076c9652d clr！Thread :: intermediateThreadProc + 0x7d000000003c66f7f0 000000007702c541 kernel32！BaseThreadInitThunk + 0xd000000003c66f820 0000000000000000 ntdll！RtlUserThreadStart + 0x1d

我很难解释堆栈跟踪信息，因为它们没有命中我的任何应用程序代码。他们都只是闲着的线程工作者，正在等待工作吗？

Answer 1

具有WaitForSingleObject的线程并不重要，因为它们正在等待并且不占用CPU时间。但是请注意，您的转储只是一个快照，拍摄快照时可能运气不佳。

Answer 2

类似问题的声音可能与GC有关。由于这是一项自托管服务，因此默认情况下它将使用Workstation GC，除非您手动启用服务器GC：

Answer 3

Microsoft的观点可能会有所帮助。从链接：

Answer 4

使用WPRUI.exe捕获跟踪并通过WPA.exe分析CPU使用率。

Answer 5

使用Perfview收集ETW并遵循较大的％数。