c# - DebugDiag メッセージ スレッドがリモート サーバーで応答を待機していないように見える

Question

複数のタスクに分割されたプロセスを実行する C# Windows サービスがあります。ほとんどのタスクは、WCF を使用して Web サービスに接続し、データベースに対して作業を実行します。サービスのタスクは複数のスレッドで実行されます。

お客様から、Windows サービスが時々応答しなくなり、再起動する必要があるとのサポート ケースが提出されました。Windows サービスからメモリダンプを取得しました。DebugDiag 2.0を実行して、ダンプ ファイルを分析しました。

DebugDiag レポートの概要に興味深いエントリがありました。

WindowsService.DMP の次のスレッドは HttpWebRequest を作成しようとしていますが、リモート サーバーでの応答を待機していないようです (たとえば、「通信中」ではありません)。これらの要求の 1 つ以上が、使用可能な接続の最大数の少なくとも半分を使用しています。

( 17 18 27 31 32 33 42 ) ブロックされたスレッドの 12.07% (7 スレッド)

多くのスレッドがこの状態にある場合は、多くの場合、スロットリング制限 (つまり、'maxconnection' 設定) を使い果たしたことを示しています。左側のリストの任意のスレッドをクリックして、待機中の WebRequest のスロットリングの詳細を確認します。

必要に応じて、アプリケーション構成ファイルの「maxconnection」パラメーターを変更するか (「<connectionManagement>要素」を参照)、適切な ConnectionLimit プロパティをプログラムで変更することにより (「接続の管理」を参照)、使用可能な接続の数を増やすことができます。

スレッド17にジャンプして、これを見ました：

スレッド 17 - システム ID 4612

エントリ ポイント mscorwks!Thread::intermediateThreadProc 作成時刻 2015 年 9 月 10 日 10:13:14 AM ユーザー モードで費やされた時間 0 日 00:00:00.000 カーネル モードで費やされた時間 0 日 00:00:00.000

このスレッドは HttpWebRequest を作成しようとしていますが、リモート サーバーでの応答を待機していないようです (たとえば、「通信中」ではありません)。これらの要求の 1 つ以上が、使用可能な接続の最大数の少なくとも半分を使用しています。

警告、利用可能な接続の少なくとも半分が使用されています

HttpRequest URI: http://WebServer/MyWebSite/SubDir/MyService.svc ServicePoint - ConnectionLimit:48 CurrentConnections:44

HttpWebRequest オブジェクトはループバック アドレスですが、接続制限が定義されているため (processModel セクションで autoconfig を true に設定するか、connectionManagement セクション内に * エントリを追加することによって) 接続制限がこの Webrequest オブジェクトに適用されます。

.NET コール スタックは次のとおりです。

Function

[[HelperMethodFrame_1OBJ] (System.Threading.WaitHandle.WaitOneNative)] System.Threading.WaitHandle.WaitOneNative(Microsoft.Win32.SafeHandles.SafeWaitHandle, UInt32, Boolean, Boolean) 
mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int64, Boolean)+2f 
mscorlib_ni!System.Threading.WaitHandle.WaitOne(Int32, Boolean)+25 
System_ni!System.Net.LazyAsyncResult.WaitForCompletion(Boolean)+d3 
System_ni!System.Net.Connection.SubmitRequest(System.Net.HttpWebRequest)+2b7 
System_ni!System.Net.ServicePoint.SubmitRequest(System.Net.HttpWebRequest, System.String)+7c 
System_ni!System.Net.HttpWebRequest.SubmitRequest(System.Net.ServicePoint)+f9 
System_ni!System.Net.HttpWebRequest.GetRequestStream(System.Net.TransportContext ByRef)+1d3 
System_ni!System.Net.HttpWebRequest.GetRequestStream()+e 
System_ServiceModel_ni!System.ServiceModel.Channels.HttpOutput+WebRequestHttpOutput.GetOutputStream()+45 
System_ServiceModel_ni!System.ServiceModel.Channels.HttpOutput.Send(System.TimeSpan)+f6 
System_ServiceModel_ni!System.ServiceModel.Channels.HttpChannelFactory+HttpRequestChannel+HttpChannelRequest.SendRequest(System.ServiceModel.Channels.Message, System.TimeSpan)+121 
System_ServiceModel_ni!System.ServiceModel.Channels.RequestChannel.Request(System.ServiceModel.Channels.Message, System.TimeSpan)+cb 
System_ServiceModel_ni!System.ServiceModel.Dispatcher.RequestChannelBinder.Request(System.ServiceModel.Channels.Message, System.TimeSpan)+17 
System_ServiceModel_ni!System.ServiceModel.Channels.ServiceChannel.Call(System.String, Boolean, System.ServiceModel.Dispatcher.ProxyOperationRuntime, System.Object[], System.Object[], System.TimeSpan)+1a2 
System_ServiceModel_ni!System.ServiceModel.Channels.ServiceChannel.Call(System.String, Boolean, System.ServiceModel.Dispatcher.ProxyOperationRuntime, System.Object[], System.Object[])+33 
System_ServiceModel_ni!System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(System.Runtime.Remoting.Messaging.IMethodCallMessage, System.ServiceModel.Dispatcher.ProxyOperationRuntime)+43 
System_ServiceModel_ni!System.ServiceModel.Channels.ServiceChannelProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage)+65 
mscorlib_ni!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(System.Runtime.Remoting.Proxies.MessageData ByRef, Int32)+bd
[[TPMethodFrame] (IMyWebService.GetDataSet)]
IMyWebService.GetDataSet(System.Guid, System.String, System.Data.DataSet)
<service code snipped>
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+66
mscorlib_ni!System.Threading.ExecutionContext.runTryCode(System.Object)+51 
[[HelperMethodFrame_PROTECTOBJ] (System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup)]
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object) 
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+67 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+45 
mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()+44 
[[GCFrame]] 

私はそれが行った推奨事項を見て、それらの調査を開始しました。私の質問は：

DebugDiag で、スレッドがサーバーの応答を待っていないように見えるのはなぜですか?

.NET Reference Sourceを見ると、リクエストは正常に送信されたように見え、サービスは応答を待っているように見えます。

アップデート

通常の呼び出しに割り込むと、以下の Puneet Gupta によって提案されているように、ws2_2 で待機している呼び出しスタックが表示されます。

ntdll.dll!_NtWaitForSingleObject@12()
mswsock.dll!_SockWaitForSingleObject@16()
mswsock.dll!_WSPRecv@36()
***ws2_32.dll!_recv@16()***
System.ni.dll!6c084a13()
[Managed to Native Transition]  
System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags, out System.Net.Sockets.SocketError errorCode)
System.dll!System.Net.Sockets.Socket.Receive(byte[] buffer, int offset, int size, System.Net.Sockets.SocketFlags socketFlags)
System.dll!System.Net.Sockets.NetworkStream.Read(byte[] buffer, int offset, int size)
System.dll!System.Net.PooledStream.Read(byte[] buffer, int offset, int size)
System.dll!System.Net.Connection.SyncRead(System.Net.HttpWebRequest request, bool userRetrievedStream, bool probeRead)
System.dll!System.Net.ConnectStream.ProcessWriteCallDone(System.Net.ConnectionReturnResult returnResult)
System.dll!System.Net.HttpWebRequest.WriteCallDone(System.Net.ConnectStream stream, System.Net.ConnectionReturnResult returnResult)
System.dll!System.Net.ConnectStream.CallDone(System.Net.ConnectionReturnResult returnResult)
System.dll!System.Net.ConnectStream.ResubmitWrite(System.Net.ConnectStream oldStream, bool suppressWrite)
System.dll!System.Net.HttpWebRequest.EndWriteHeaders_Part2()
System.dll!System.Net.HttpWebRequest.EndWriteHeaders(bool async)
System.dll!System.Net.HttpWebRequest.WriteHeadersCallback(System.Net.WebExceptionStatus errorStatus, System.Net.ConnectStream stream, bool async)
System.dll!System.Net.ConnectStream.WriteHeaders(bool async)
System.dll!System.Net.HttpWebRequest.EndSubmitRequest()
System.dll!System.Net.HttpWebRequest.CheckDeferredCallDone(System.Net.ConnectStream stream)
System.dll!System.Net.HttpWebRequest.GetResponse()
System.ServiceModel.dll!System.ServiceModel.Channels.HttpChannelFactory<System.ServiceModel.Channels.IRequestChannel>.HttpRequestChannel.HttpChannelRequest.WaitForReply(System.TimeSpan timeout)
System.ServiceModel.dll!System.ServiceModel.Channels.RequestChannel.Request(System.ServiceModel.Channels.Message message, System.TimeSpan timeout)
System.ServiceModel.dll!System.ServiceModel.Dispatcher.RequestChannelBinder.Request(System.ServiceModel.Channels.Message message, System.TimeSpan timeout)  Unknown
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.Call(string action, bool oneway, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation, object[] ins, object[] outs, System.TimeSpan timeout)
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(System.Runtime.Remoting.Messaging.IMethodCallMessage methodCall, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation)
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage message)
mscorlib.dll!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(ref System.Runtime.Remoting.Proxies.MessageData msgData, int type)

したがって、通常は Windows ソケットからの応答を待ちます。この場合、他の DebugDiag メッセージで示されているように、スレッドはおそらく接続がリクエストを処理できるようになるのを待っています。

Answer 1

!dso (!DumpStackObjects) は現在のスレッドに接続オブジェクトを表示しますか? もしそうなら、System.Net.Connection オブジェクトの m_WaitList 値と m_CurrentRequest の値は何ですか? コールスタックは、ws2_32 (WinSock) で待機していることを示していないため、HWR が利用可能な接続またはソケットの取得をまだ待機していることを示しています。

Answer 2

ネットワーク上で待機していないように見えるというメッセージが表示される理由は、スレッドの最後のフレームが waithandle.waitone であるためです。

ネットワーク上で実際に待機しているスレッドの場合、Windows ソケット ライブラリである ws2_32 (ネイティブ スタック内) またはマネージ スタック内の system.net.sockets の関数が表示されます。

複数のダンプをキャプチャできましたか? はいの場合、1 つのダンプと 2 番目のダンプでスレッドの状態が変化したことを確認しましたか?