0

私は Web アプリケーションを持っていますが、ハングアップしたり、パフォーマンスが非常に遅くなったりすることがあります。DebugDiag を使用して完全なダンプを取得し、クラッシュ/ハング分析を使用して分析を試みました。

要約によると、スレッドの 7.86% (10) がブロックされ、Monitor.Wait.

しかし、スレッドでコール スタック/スタック トレースを確認すると、以下が出力されます。

.NET Call Stack



Function 
System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 
System.Threading.Monitor.Wait(System.Object, Int32, Boolean) 
Quartz.Simpl.SimpleThreadPool+WorkerThread.Run() 
System.Threading.ThreadHelper.ThreadStart_Context(System.Object) 
System.Threading.ExecutionContext.runTryCode(System.Object) 
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object) 
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) 
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) 
System.Threading.ThreadHelper.ThreadStart() 


Full Call Stack



Function   Source 
ntdll!NtWaitForMultipleObjects+15    
KERNELBASE!WaitForMultipleObjectsEx+100    
kernel32!WaitForMultipleObjectsExImplementation+e0    
clr!WaitForMultipleObjectsEx_SO_TOLERANT+56    
clr!Thread::DoAppropriateAptStateWait+4d    
clr!Thread::DoAppropriateWaitWorker+17d    
clr!Thread::DoAppropriateWait+60    
clr!CLREvent::WaitEx+106    
clr!CLREvent::Wait+19    
clr!Thread::Wait+1d    
clr!Thread::Block+1a    
clr!SyncBlock::Wait+169    
clr!ObjHeader::Wait+2c    
clr!ObjectNative::WaitTimeout+147    
System.Threading.Monitor.Wait(System.Object, Int32, Boolean)    
System.Threading.ThreadHelper.ThreadStart_Context(System.Object)    
System.Threading.ExecutionContext.runTryCode(System.Object)    
clr!CallDescrWorker+33    
clr!CallDescrWorkerWithHandler+8e    
clr!MethodDesc::CallDescr+194    
clr!MethodDesc::CallTargetWorker+21    
clr!MethodDescCallSite::Call+1c    
clr!ExecuteCodeWithGuaranteedCleanupHelper+bb    
clr!ReflectionInvocation::ExecuteCodeWithGuaranteedCleanup+138    
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)    
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)    
System.Threading.ThreadHelper.ThreadStart()    
clr!CallDescrWorker+33    
clr!CallDescrWorkerWithHandler+8e    
clr!MethodDesc::CallDescr+194    
clr!MethodDesc::CallTargetWorker+21    
clr!ThreadNative::KickOffThread_Worker+1e1    
clr!Thread::DoExtraWorkForFinalizer+114    
clr!Thread::ShouldChangeAbortToUnload+101    
clr!Thread::ShouldChangeAbortToUnload+399    
clr!Thread::RaiseCrossContextException+3f8    
clr!Thread::DoADCallBack+358    
clr!Thread::DoExtraWorkForFinalizer+fa    
clr!Thread::ShouldChangeAbortToUnload+101    
clr!Thread::ShouldChangeAbortToUnload+399    
clr!Thread::ShouldChangeAbortToUnload+43a    
clr!ManagedThreadBase::KickOff+15    
clr!ThreadNative::KickOffThread+23e    
clr!Thread::intermediateThreadProc+4b    
kernel32!BaseThreadInitThunk+e    
ntdll!__RtlUserThreadStart+70    
ntdll!_RtlUserThreadStart+1b

彼らがどのロックを取得するのを待っているかは実際には表示されません-この情報を取得する方法について何か考えはありますか?

4

1 に答える 1

1

残念ながら、スレッドは Monitor.Wait を呼び出す前にあまり多くのメソッドを深く掘り下げていないように見えるため、正確な場所を特定するのは難しいかもしれません。スタック トレースに基づいて、Quartz.Simpl.SimpleThreadPool+WorkerThread.Run() のコードを調べ、Monitor.Wait を呼び出す場所を確認して、実際に待機しているものを確認します。

コードの量/品質にもよりますが、これがおそらく簡単な方法です。また、Windbg をインストールし、それがロックしているオブジェクトのアドレスを見つけて調べることもできますが、必要なすべてのシンボルを確実にロードできるようにするために、いくつかの初期設定が必要です。http://blogs.msdn.com/b/emeadaxsupport/archive/2011/04/10/setting-up-windbg-and-using-symbols.aspxでは、Windbg のセットアップについて説明しています。これは強力なツールですが、Quartz.Simpl.SimpleThreadPool+WorkerThread.Run() のコードをチェックするだけで、おそらくより簡単になります。

于 2012-11-28T23:08:23.197 に答える