최근에 진행된 지원 케이스에서 ASP.Net 페이지의 서비스 속도 저하와 관련된  이슈에서 조금은 특이한 부분이 있어서 정리차원에서 블로그 글을  포스팅 합니다.

우선 문제 상황에 대한 간단한 내용을 보면 다음과 같습니다.

Windows 2003 서버에 .Net Framework 2.0 (또는 그 이상)이 설치되어 있고 ASP.Net 페이지들은 단순하게 사용자의 입력을 받고 서비스를 호출 한 후 결과를 보여주는 기능을 하고 있습니다. 이때 서비스는 역시 .Net Framework 2.0 C#으로 제작된 Serviced Component 형태로 COM+ 서버에서 작동 중 이었습니다.

COM+는 다시 실제 Business Logic을 구현하고 Exchange 2007 메일 서버에 EWS로 접근 하여 ASPX 페이지들이 보여줄 자료를 가공하는 역활을 하도록 제작되어 있습니다.

서비스 중에 느끼게 되는 문제의 형태는

1. Peak Time에 CPU나 메모리 사용량이 높거나 많지 않고,

2. netstat 등으로 확인해 보면 IIS 또는 COM+ 프로세스에서 사용하는 Network Connection 역시 많지 않은 상황 있었습니다.

어떤 이유에서 인지 서버들이 늘어난 처리 요청에 따라서 적절하게 시스템 리소스를 사용하지 못하고 의도 되지 않은 어떤 설정에 의해서 성능 저하를 가져오는 상태에 있었습니다.

문제 확인을 위해서 사용자가 많은 시점에 IIS의 Worker Process (W3WP.EXE)와 COM+ 프로세스 (DLLHOST.EXE)의 행모드 덤프(Hang-mode Debug Dump)를 수집 해서 상태 파악을 시도 했습니다.

W3WP.EXE에서 실행되는 모든 사용자 요청은 실제 아래의 형태와 같이 COM+ 서버에 전달된 자료 처리 요청에 대한 결과를 대기 중인 상태에 있었습니다.

ESP       EIP    
02c9eee8 7c96860c [ComPlusMethodFrameStandaloneCleanup: 02c9eee8] System.EnterpriseServices.IRemoteDispatch.RemoteDispatchAutoDone(System.String)
02c9eef8 0435ef72 System.EnterpriseServices.RemoteServicedComponentProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage)
02c9ef40 794abdb3 System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(System.Runtime.Remoting.Proxies.MessageData ByRef, Int32)
02c9f1e0 79f3cb53 [TPMethodFrame: 02c9f1e0] SomeBusinessModule.GetDataList(SomeBusinessData.DataEntry, System.String)
02c9f1f4 042a5feb ViewBusinessData.Page_Load(System.Object, System.EventArgs)
02c9f224 698a1928 System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr, System.Object, System.Object, System.EventArgs)
02c9f234 0300d73f System.Web.Util.CalliEventHandlerDelegateProxy.Callback(System.Object, System.EventArgs)
02c9f248 02eba5a4 System.Web.UI.Control.OnLoad(System.EventArgs)
02c9f258 042a06cc BasePage.OnLoad(System.EventArgs)
02c9f264 02eba5f0 System.Web.UI.Control.LoadRecursive()
02c9f278 02ecbbf6 System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)
02c9f430 02ecb521 System.Web.UI.Page.ProcessRequest(Boolean, Boolean)
02c9f460 02ecb487 System.Web.UI.Page.ProcessRequest()
02c9f498 02ecb3a7 System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext)
02c9f4a0 02ecb33a System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)
02c9f4b4 042a0165 ASP.ViewBusinessData_aspx.ProcessRequest(System.Web.HttpContext)
02c9f4b8 02d788df System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
02c9f4ec 02d4a071 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)
02c9f52c 02d4a39b System.Web.HttpApplication.ResumeSteps(System.Exception)
02c9f574 02d4912d System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback, System.Object)
02c9f590 02d4e0bd System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)
02c9f5c4 02d4dd72 System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)
02c9f5d0 02d4c447 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)
02c9f780 79f1ef33 [ContextTransitionFrame: 02c9f780]
02c9f7d0 79f1ef33 [GCFrame: 02c9f7d0]
02c9f928 79f1ef33 [ComMethodFrame: 02c9f928]

프로세서의 사용 정보와 ThreadPool의 상태를 확인해 보면 사용자 요청이 많은 시간대 임에도 불구 하고 CPU 사용량이 8% 정도 이며 100개 까지 생성 될 수 있는 Worker Thread들 중 실행 중인 Thread가 1개 (Running : 1) 뿐 임을 할 수 있습니다.

Work Request in Queue: 0
--------------------------------------
Number of Timers: 0
--------------------------------------
CPU utilization 8%
--------------------------------------
Worker Thread: Total: 1 Running: 1 Idle: 0 MaxLimit: 100 MinLimit: 4
Completion Port Thread:Total: 0 Free: 0 MaxFree: 8 CurrentLimit: 0 MaxLimit: 1000 MinLimit: 4

문제 확인을 위해서 SyncBlock을 확인해 보니 아래와 같이 많은 숫자의 Thread들이 System.Net.ServicePoint 관련 SyncBlock에 대해 블로킹 된 상태로 사용 Thread의 완료를 기다리는 상태 임을 확인 할 수 있습니다.

0:000> !SyncBlk
Index SyncBlock MonitorHeld Recursion Owning Thread Info  SyncBlock Owner
  352 1a3387e4          115         1 1a353728  23e8  17   09332f2c System.Net.ServicePoint
        Waiting threads: 14 15 16 18 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 38 …

  353 001728ec            3         1 1a353728  23e8  17   013a2ec8 System.Collections.ArrayList
        Waiting threads: 19
  354 1a391dcc            3         1 00162c70  24b4  19   013a2f1c System.Net.Connection
        Waiting threads: 17
-----------------------------
Total           458
CCW             225
RCW             0
ComClassFactory 0
Free            150

실행 중인 Managed Thread들 중에 위의 SyncBlock 리스트의 Head에 해당하는 17번, 19번 Thread의 Call Stack은 아래와 같습니다.

이들은 System.Net.Connection 객체의 사용이 완료되어서 Close/Release를 진행 중인 상태에 있었습니다.

0:019> !ClrStack
OS Thread Id: 0x24b4 (19)
ESP       EIP    
1a29f7b0 7c96860c [GCFrame: 1a29f7b0]
1a29f880 7c96860c [HelperMethodFrame_1OBJ: 1a29f880] System.Threading.Monitor.Enter(System.Object)
1a29f8d8 7a5b0034 System.Net.ConnectionGroup.Disassociate(System.Net.Connection)
1a29f904 7a5aeaa7 System.Net.Connection.PrepareCloseConnectionSocket(System.Net.ConnectionReturnResult ByRef)
1a29f968 7a5ae293 System.Net.Connection.AbortOrDisassociate(System.Net.HttpWebRequest, System.Net.WebException)
1a29f9a0 7a57d9ff System.Net.HttpWebRequest.Abort(System.Exception, Int32)
1a29f9d4 7a57dbd1 System.Net.HttpWebRequest.AbortWrapper(System.Object)
1a29f9e8 793d91f6 System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(System.Object)
1a29fb78 79e88f63 [GCFrame: 1a29fb78]

0:017> !ClrStack
OS Thread Id: 0x23e8 (17)
ESP       EIP    
00dfe0d4 7c96860c [GCFrame: 00dfe0d4]
00dfe1a4 7c96860c [HelperMethodFrame_1OBJ: 00dfe1a4] System.Threading.Monitor.Enter(System.Object)
00dfe1fc 7a5ae107 System.Net.Connection.CloseOnIdle()
00dfe228 7a5b0403 System.Net.ConnectionGroup.DisableKeepAliveOnConnections()
00dfe25c 7a58be63 System.Net.ServicePoint.ReleaseConnectionGroup(System.String)
00dfe28c 7a5c227f System.Net.NegotiateClient.Update(System.String, System.Net.WebRequest)
00dfe2ac 7a5a43c7 System.Net.AuthenticationState.Update(System.Net.HttpWebRequest)
00dfe2ec 7a57c04c System.Net.HttpWebRequest.DoSubmitRequestProcessing(System.Exception ByRef)
00dfe320 7a57e50a System.Net.HttpWebRequest.ProcessResponse()
00dfe358 7a57e4a3 System.Net.HttpWebRequest.SetResponse(System.Net.CoreResponseData)
00dfe39c 7a57e11a System.Net.HttpWebRequest.CheckWriteSideResponseProcessing()
00dfe3a8 7a57f51e System.Net.HttpWebRequest.EndSubmitRequest()
00dfe3d8 7a57dec6 System.Net.HttpWebRequest.SetRequestSubmitDone(System.Net.ConnectStream)
00dfe3ec 7a5ab8ff System.Net.Connection.CompleteStartRequest(Boolean, System.Net.HttpWebRequest, System.Net.TriState)
00dfe41c 7a5ab56b System.Net.Connection.SubmitRequest(System.Net.HttpWebRequest)
00dfe460 7a58b1b4 System.Net.ServicePoint.SubmitRequest(System.Net.HttpWebRequest, System.String)
00dfe498 7a57ef21 System.Net.HttpWebRequest.SubmitRequest(System.Net.ServicePoint)
00dfe4c8 7a57cae2 System.Net.HttpWebRequest.GetResponse()
00dfe510 6990bf7d System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(System.Net.WebRequest)
00dfe540 6990c915 System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(System.Net.WebRequest)
00dfe544 69919eb1 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(System.String, System.Object[])
00dfe588 19aa5560 ExchangeServiceBinding.FindItem(FindItemType)
00dfe598 1a300e14 AccessMailServer.GetMailList(...)
00dfefc8 79e88f63 [HelperMethodFrame_PROTECTOBJ: 00dfefc8] System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
00dff10c 794be820 System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(System.RuntimeMethodHandle, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
00dff12c 794bdf4b System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage, Int32, Boolean)
00dff1ac 794b6233 System.Runtime.Remoting.RemotingServices.ExecuteMessage(System.MarshalByRefObject, System.Runtime.Remoting.Messaging.IMethodCallMessage)
00dff1bc 673fd83d System.EnterpriseServices.ServicedComponentProxy.LocalInvoke(System.Runtime.Remoting.Messaging.IMessage)
00dff1fc 673fd64e System.EnterpriseServices.ServicedComponentProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage)
00dff20c 673fb5a4 System.EnterpriseServices.ServicedComponent.RemoteDispatchHelper(System.String, Boolean ByRef)
00dff21c 673fb317 System.EnterpriseServices.ServicedComponent.System.EnterpriseServices.IRemoteDispatch.RemoteDispatchAutoDone(System.String)
00dff424 79f1ef33 [GCFrame: 00dff424]
00dff57c 79f1ef33 [ComMethodFrame: 00dff57c]

나머지 Thread들은 전부 아래와 같은 형태로 네트워크 관련 처리를 위해서 System.Net.ServicePoint 객체를 사용하기 위한 Monitor에 대해서 Waiting을 하고 있는 상태 였습니다.

ESP       EIP    
1a90e874 7c96860c [GCFrame: 1a90e874]
1a90e9ac 7c96860c [HelperMethodFrame: 1a90e9ac] System.Threading.Monitor.Enter(System.Object)
1a90ea00 7a58b151 System.Net.ServicePoint.SubmitRequest(System.Net.HttpWebRequest, System.String)
1a90ea38 7a57ef21 System.Net.HttpWebRequest.SubmitRequest(System.Net.ServicePoint)
1a90ea68 7a57bd92 System.Net.HttpWebRequest.GetRequestStream()
1a90ea9c 69919e6c System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(System.String, System.Object[])
1a90eae0 1a307f60 AccessMailServer.GetItem(GetItemType)
1a90eaf0 1a2f8414 SomeBusinessModule.GetChangedPArts(DataEntry, System.String)
1a90eb2c 1a2f8f74 SomeBusinessModule.Method1(DataEntry, System.String ByRef)
1a90eb84 1a2f2ff9 SomeBusinessModule.SendData(DataEntry, System.String ByRef)
1a90ec40 79e88f63 [ProtectByRefsFrame: 1a90ec40]
1a90efc8 79e88f63 [HelperMethodFrame_PROTECTOBJ: 1a90efc8] System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
1a90f10c 794be820 System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(System.RuntimeMethodHandle, System.Object[], System.Object, Int32, Boolean, System.Object[] ByRef)
1a90f12c 794bdf4b System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage, Int32, Boolean)
1a90f1ac 794b6233 System.Runtime.Remoting.RemotingServices.ExecuteMessage(System.MarshalByRefObject, System.Runtime.Remoting.Messaging.IMethodCallMessage)
1a90f1bc 673fd83d System.EnterpriseServices.ServicedComponentProxy.LocalInvoke(System.Runtime.Remoting.Messaging.IMessage)
1a90f1fc 673fd64e System.EnterpriseServices.ServicedComponentProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage)
1a90f20c 673fb5a4 System.EnterpriseServices.ServicedComponent.RemoteDispatchHelper(System.String, Boolean ByRef)
1a90f21c 673fb317 System.EnterpriseServices.ServicedComponent.System.EnterpriseServices.IRemoteDispatch.RemoteDispatchAutoDone(System.String)
1a90f424 79f1ef33 [GCFrame: 1a90f424]
1a90f57c 79f1ef33 [ComMethodFrame: 1a90f57c]

위현상은 아래의 .Net Framework 성능 조정과 관련된 KB 문서에서 언급하고 있는 Connection 설정인 MaxConnection=2와 유사한 것으로 보입니다.

Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
http://support.microsoft.com/kb/821268/en-us

덤프에서 확인해 보면 실제 ServicePoint객체에서 확인 가능한 Connection Limit가 2로 설정되어 있음을 확인 할 수 있습니다. 즉, 문제가 되고 있는 현상은 .Net Framework과 관련된 설정이 성능에 문제를 일으키고 있다는 것 입니다. 하지만 위의 KB 문서를 보면 .Net Framework 2.0의 경우는 autoConfig를 설정하는 경우 maxconnection이 12*CPU 갯수라고 지정되어 있으며 문제 서버의 경우 AutoConfig가 Enable 되어 있는 상태 였습니다.

Name: System.Net.ServicePoint
MethodTable: 7a772e10
EEClass: 7a7d0b68
Size: 116(0x74) bytes
GC Generation: 2
(C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll)
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
790fed1c  40020af       38         System.Int32  1 instance       -1 m_ConnectionLeaseTimeout
7a77a4c4  40020b0        4 ...TimerThread+Queue  0 instance 05310044 m_ConnectionLeaseTimerQueue
79104f64  40020b1       54       System.Boolean  1 instance        0 m_ProxyServicePoint
79104f64  40020b2       55       System.Boolean  1 instance        0 m_UserChangedLimit
79104f64  40020b3       56       System.Boolean  1 instance        1 m_UseNagleAlgorithm
7a772738  40020b4       3c         System.Int32  1 instance        0 m_HostLoopbackGuess
790fed1c  40020b5       40         System.Int32  1 instance       -1 m_ReceiveBufferSize
79104f64  40020b6       57       System.Boolean  1 instance        1 m_Expect100Continue
79104f64  40020b7       58       System.Boolean  1 instance        0 m_Understands100Continue
7a772504  40020b8       59          System.Byte  1 instance        3 m_HttpBehaviour
790fa3e0  40020b9        8        System.String  0 instance 0535b350 m_LookupString
790fed1c  40020ba       44         System.Int32  1 instance        2 m_ConnectionLimit
790fea70  40020bb        c ...ections.Hashtable  0 instance 0535b400 m_ConnectionGroupList
7a746d44  40020bc       10           System.Uri  0 instance 0535b0dc m_Address
790fa3e0  40020bd       14        System.String  0 instance 0535b13c m_Host
790fed1c  40020be       48         System.Int32  1 instance       80 m_Port
7a77a4c4  40020bf       18 ...TimerThread+Queue  0 instance 093325fc m_IdlingQueue
7a77a50c  40020c0       1c ...TimerThread+Timer  0 instance 053c42ac m_ExpiringTimer
79105ef0  40020c1       60      System.DateTime  1 instance 0535b3ec m_IdleSince
790fa3e0  40020c2       20        System.String  0 instance 7a72fa60 m_ConnectionName
790fed1c  40020c3       4c         System.Int32  1 instance        0 m_CurrentConnections
79104f64  40020c4       5a       System.Boolean  1 instance        0 m_HostMode
7a772d88  40020c5       24 ...et.BindIPEndPoint  0 instance 00000000 m_BindIPEndPointDelegate
790f9c18  40020c7       28        System.Object  0 instance 00000000 m_ServerCertificateOrBytes
790f9c18  40020c8       2c        System.Object  0 instance 00000000 m_ClientCertificateOrBytes
790fa3e0  40020c9       30        System.String  0 instance 053622c8 m_HostName
79124228  40020ca       34      System.Object[]  0 instance 0536233c m_IPAddressInfoList
790fed1c  40020cb       50         System.Int32  1 instance        0 m_CurrentAddressInfoIndex
79104f64  40020cc       5b       System.Boolean  1 instance        1 m_ConnectedSinceDns
79104f64  40020cd       5c       System.Boolean  1 instance        0 m_AddressListFailed
79105ef0  40020ce       68      System.DateTime  1 instance 0535b3f4 m_LastDnsResolve
79104f64  40020cf       5d       System.Boolean  1 instance        0 m_IPAddressesAreLoopback
79107d2c  40020c6      7ec System.AsyncCallback  0   shared   static m_ConnectCallbackDelegate
    >> Domain:Value  000de060:NotInit  <<

실제 이부분이 설정의 문제인지 .Net Framework의 버그 인지 확인을 위해서 아래의 MSDN 문서를 확인해 본 결과 이는 실제 설계된 동작임을 알 수 있습니다.

즉, IIS Worker Process에서 실행되는 ASP.Net 응용프로그램을 제외한 (즉, W3WP 프로세스 이외에) 모든 프로세스들은 실행 시 autoConfig 설정이 적용용되지 않고, 별도의 설정을 하지 않는 경우 시스템 디폴트 값을 따르게 된다는 것 입니다.

ASP.Net 2.0

processModel Element (ASP.NET Settings Schema)
http://msdn.microsoft.com/en-us/library/7w2sway1.aspx

이 포스팅에서 설명하는 문제는 machine.config (또는 DLLHOST.EXE.CONFIG ) 설정을 변경 후 KB821268에서 언급하고 있는 시스템 가이드를 참조하여 변경 한 이후 해결이 되었습니다.

이외 비슷하게 ASP.Net 이외에 별도의 프로세스에서 Network에 접근하여 자료를 수집/분석/제공하는 서비스를 이용하는 경우 성능 조정을 위한 파라미터를 설정해 주셔야 합니다.

비교적(겨우 2년 전이네요 :-) 최근에 Tess의 블로그에 ASP.Net 2.0 에서 같은 맥락으로 Hang Dump 분석시 참고가 되는 글이 올라와서 같이 번역(사실 거의 복사에 가깝습니다만) 해서 올립니다.

Tess의 글에서 언급하고 있습니다만 서버 프로세스가 처리를 하지 않거나 메모리 사용량이 늘어나거나 CPU 점유율이 높아지면서 Hang Dump를 수집하게 되면 고객들 께서는 "무슨 일을 하기에" 그런 일이 벌어지는지 문의를 하십니다.

바로 이전 포스팅과 본 포스팅은 "무슨일" 이 아니라 "나머지 무시할 수 있는 것"들에 대한 얘기 입니다. 즉, 사용자의 Request를 처리하지 않는 "Normal"한 (또는 Idle 상태의) Thread들은 어떻게 생겼는가 에 대해서 언급하고 있습니다.

일단 이전 포스팅에서 IIS 6.0의 W3WP 프로세스의 Thread들이 소개 되어 있기 때문에 간단하게 넘기고 여기서는 제목 처럼 .Net Framework 2.0(또는 ASP.Net 2.0)에서 이전의 .Net Framework 1.1과 달라진 부분에 집중 해 보겠습니다.

우선 놀고 있는 CLR Worker Thread를 보죠.

혹시 이전 번젼과 차이가 느껴지시나요? 참고를 위해서 이전 버젼의 CLR Worker Thread의 Stack Trace를 비교해 보시죠.

이전 포스팅에서 잠시 언급을 했습니다만, .Net Framework 1.1은 GC Version이 서로 많이 다르고

서버 프로세스와 일반 클라이언트 프로세스에 로딩 되는 DLL 역시 바뀝니다.

ASP.Net 2.0에서는 서버 프로세스에서도 mscrowks (Workstation version)이 올라가고 있다는 뜻일까요? 그렇지는 않습니다.

이는 현재 구현상 이름이 남아 있는 것 뿐이 실행시 모양은 차이가 있습니다.

아래 GC Thread 부분을 참고하세요.

Idle CLR Completion Port/IO Thread

18 Id: efc.12b8 Suspend: 1 Teb: fff82000 Unfrozen
ChildEBP RetAddr Args to Child 
0257fe6c 7d4d8c56 000002dc 00000000 00000000 ntdll!ZwWaitForSingleObject+0x15
0257fedc 79e718fd 000002dc ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac
0257ff20 79e718c6 000002dc ffffffff 00000000 mscorwks!PEImage::LoadImage+0x199
0257ff70 79e7187c ffffffff 00000000 00000000 mscorwks!CLREvent::WaitEx+0x117
0257ff80 7a0d6f16 ffffffff 00000000 00000000 mscorwks!CLREvent::Wait+0x17
0257ffa8 7a0d722e 00000000 fcb9fe5a 0257ffec mscorwks!SVR::gc_heap::gc_thread_function+0x2f
0257ffb8 7d4dfff1 001b20e8 00000000 00000000 mscorwks!SVR::gc_heap::gc_thread_stub+0x9b
0257ffec 00000000 7a0d7192 001b20e8 00000000 kernel32!BaseThreadStart+0x34

아래의 Stack Trace는 Client Application 상에서 실행되고 있는 GC Thread의 Snapshot 입니다,.

특히, 붉게 표시된 부분은 GC가 위의 Thread와 달리 열심히 살아 있는 (즉, 사용되고 있는) 객체를 표시하고 있는 중이라는 것을 보실 수 있습니다.

위의 내용과 비교해 보시면 mscorwks!SVR이 아니네요.

이전에는 없던 AppDomain Unload Thread라는 것이 생겼는데요. 관련 설명은 다음의 MSDN URL을 참고하세요.

AppDomain.Unload 메서드

http://msdn.microsoft.com/ko-kr/library/system.appdomain.unload.aspx

이 포스트는 Tess의 Things to ignore when debugging an ASP.NET hang(http://blogs.msdn.com/tess/archive/2005/12/20/505862.aspx) 을 약간 번역(오역?) 한 내용 입니다. 기술 내용의 특징상 사람이 보려고 만든 내용은 아닐 듯 한데 생각보다 많은 분들이 관련 내용에 관심을 가지시더군요.

어떤 문제가 발생한 덤프를 분석한다는 것이 쉬운 일은 아닙니다. 특히, 어느 특정 시점에 작동 중이 프로세스의 Snapshot인 Dump만으로 이전/이후 상황을 설명하고 파악한다는 것은 나름 많은 기반 지식과 경험이 필요한 일 입니다.

분석 중 가장 필요한 내용 중 하나가 정상 적인 Thread의 Stack trace를 빨리 무시(?) 해 나가는 것 입니다.

아래의 Stack Trace들은 IIS 6.0 W3WP.EXE 프로세스에서 실행 중인 Thread들의 내용입니다. 특이 이들 Thread들은 대부분 대기 상태인 Worker Thread들이기 때문에 (일이 없어서 쉬는 상태 - Idle)  덤프 분석 중 무시 하실 수 있습니다. 분석의 속도를 높여 줄 수 있겠지요.

Tess의 포스트에서 노트로도 나옵니다만 아래 Thread의 Stack Trace는 실제 프로세스 덤프에서 확인 하실 수 있는 대표적인 것들만 요약한 것이며 더 많은 복잡한 Thread들이 작동 중일 수 있습니다.

원래 IIS에서 실행되는 Thread들의 종료가 많기 때문에 Tess는 아래와 같이 Thread들을 분류 하고 있습니다.

- CLR Threads
- W3WP Threads
- RPC Threads
- Other COM Threads

CLR Threads

.Net Framework과 관련된 Thread들 입니다. .Net Framework의 ThreadPool은 5가지 종류의 Thead 가 있습니다.

프로그래머가 작성한 코드 (Managed 내지는 .Net CLR 코드) 는 Completion Port/IO Threads와 Worker Thread들에 의해서 실행 됩니다.

Gate Thread( 문지기)는 서버 CPU 사용량, GC(Garbage Collection) 주기와 Worker Queue의 크기를 전반적으로 고려해서 필요한 경우 Worker Thread와 IO Thread들을 만들거나 파괴 합니다. Wait Thread들은 동기화 객체들에 대해서 대기하는 경우 사용 됩니다. 즉, 개발자가 사용하는 WaitHandle 클래스를 사용하는 경우 결과적으로 "WaitForSingleObject"가 호출이 되겠지요. 마지막으로 Timer Callback을 구현하는데는 Timer Thread들에 사용 됩니다.

그럼 이들 Thread들이 ASP.Net 1.1을 서비스하는 W3WP.exe 프로세스의 덤프에서 어떻게 나타나는지 보도록 하겠습니다.

Idle CLR WorkerThread

Idle CLR Completion Port / IO Thread

9  Id: fb8.ef8 Suspend: 0 Teb: 7ffac000 Unfrozen ChildEBP RetAddr  Args to Child              0191fec0 7c821bf4 77e6611a 0000023c 0191ff1c ntdll!KiFastSystemCallRet 0191fec4 77e6611a 0000023c 0191ff1c 0191ff08 ntdll!NtRemoveIoCompletion+0xc 0191fef0 791fdb22 0000023c 0191ff18 0191ff1c kernel32!GetQueuedCompletionStatus+0x29 0191ff24 791fdacc 00000001 809a05fe 7ffac000 mscorsvr!ThreadpoolMgr::CompletionPortThreadStart+0x49 0191ffb8 77e66063 000b6da8 00000000 00000000 mscorsvr!ThreadpoolMgr::intermediateThreadProc+0x44 0191ffec 00000000 791fda8b 000b6da8 00000000 kernel32!BaseThreadStart+0x34

Idle CLR Gate Thread

  10  Id: fb8.bdc Suspend: 0 Teb: 7ffab000 Unfrozen
ChildEBP RetAddr  Args to Child              
0195fe50 7c821364 77e42439 00000000 0195fe94 ntdll!KiFastSystemCallRet
0195fe54 77e42439 00000000 0195fe94 00000000 ntdll!NtDelayExecution+0xc
0195febc 77e424b7 000001f4 00000000 0195ffb8 kernel32!SleepEx+0x68
0195fecc 791bf4f9 000001f4 0b2646e6 00000939 kernel32!Sleep+0xf
0195ffb8 77e66063 00000000 00000000 00000000 mscorsvr!ThreadpoolMgr::GateThreadStart+0x54
0195ffec 00000000 791bf4a5 00000000 00000000 kernel32!BaseThreadStart+0x34

Idle CLR Wait Thread 

Idle CLR Timer Thread

.Net Framework의 수행 과정에서 빠질 수 없는 중요 Thread 몇가지를 아래에서 설명하고 있습니다.

이들중 가장 중요한 것으로 GC(Garbage Collector) Thread가 있습니다. GC Thread는 CLR의 Managed Heap 메모리를 관리합니다.

프로세서(Processor, CPU가 여러개 설치 되어 있거나 최근의 Multi-Core CPU를 사용하는 경우) 서버 버젼의 GC Thread는 CPU 들 마다 하나 씩 생성이 됩니다. Hyper-Threading 방식의 다중 CPU의 경우에는 서버 설정에 따라서 2개 CPU당 (Task Manager에서 확인되는) 하나의 GC Thread가 만들어 질 수 있습니다.

잠시 서버 버젼이라는 얘기가 나와서 부연 설명을 하자면 .Net Framework 1.1에서는 Server 버젼과 Workstation 버젼의 2개의 GC가 존재하며 서버 버젼의 경우 프로세스에 MSCORSVR.DLL 이, 클라이언트의 경우 (WinForm Application과 같은 경우) MSCORWKS.DLL이 로딩됩니다.

GC Thread와 달리 Finalizer Thread는 프로세스당 하나가 실행 됩니다. Hang이나 메모리 사용량이 많은 문제가 있는 프로세스에서는 Finalizer를 자세히 관찰할 필요가 있습니다. Finalize가 정상 작동 하지 않고 멈춰있는 경우 Finalzing이 정상적으로 되지 못해 완전히 파괴되지 못한 객체들 때문에 memory leak (점진적인 메모리 점유 현상)이 발생할 수 있고 이때문에 잦은 GC 가 발생하여 CPU 사용량이 높아지는 경우도 있습니다.

마지막으로 Debugging 시 사용되는 Debugger Thread도 나오네요.

Idle CLR GC Thread

Idle CLR Finalizer Thread

Idle CLR Debugger Thread

W3wp Thread들

W3WP 프로세서에서는 기본적으로 main Thread, W3WP Thread Pool Thread와 Compression Thread(HTTP Stream 압축용) 가 생성/작동 됩니다.

Main Thread는 프로세스의 시작고 종료를 담당 합니다. 웹서버에 전달되는 Request들은 Thread Pool Thread가 처리 합니다.

아래 Thread들의 Stack Trace들 여기 일없이 대기 중인 것 들 입니다.

W3wp main thread

.  0  Id: fb8.fd8 Suspend: 0 Teb: 7ffdf000 Unfrozen ChildEBP RetAddr  Args to Child              0006fc08 7c822124 77e6baa8 00000184 00000000 ntdll!KiFastSystemCallRet 0006fc0c 77e6baa8 00000184 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 0006fc7c 77e6ba12 00000184 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac 0006fc90 5a36467a 00000184 ffffffff 00000000 kernel32!WaitForSingleObject+0x12 0006fca0 5a366e63 00254ff8 5a3af41d 00000000 w3dt!WP_CONTEXT::RunMainThreadLoop+0x10 0006fca8 5a3af41d 00000000 64711da9 00000000 w3dt!UlAtqStartListen+0x2d 0006fcb8 5a3bc259 0100141c 010013e4 010012d0 w3core!W3_SERVER::StartListen+0xbd 0006ff0c 0100187c 00000007 002538e0 00000000 w3core!UlW3Start+0x26e 0006ff44 01001a23 00000007 002538e0 002543d0 w3wp!wmain+0x22a 0006ffc0 77e523cd 00000000 00000000 7ffd7000 w3wp!wmainCRTStartup+0x12b 0006fff0 00000000 010018f8 00000000 78746341 kernel32!BaseProcessStart+0x23

Idle w3wp ThreadPoolThread 

   2  Id: fb8.c5c Suspend: 0 Teb: 7ffd9000 Unfrozen
ChildEBP RetAddr  Args to Child              
00c8ff24 7c821bf4 77e6611a 00000170 00c8ff80 ntdll!KiFastSystemCallRet
00c8ff28 77e6611a 00000170 00c8ff80 00c8ff6c ntdll!NtRemoveIoCompletion+0xc
00c8ff54 5a30249e 00000170 00c8ff7c 00c8ff80 kernel32!GetQueuedCompletionStatus+0x29
00c8ff8c 5a3026bc 00000000 00258580 5a300000 w3tp!THREAD_POOL_DATA::ThreadPoolThread+0x33
00c8ffa0 5a301db9 00000102 00000000 00000000 w3tp!THREAD_POOL_DATA::ThreadPoolThread+0x24
00c8ffb8 77e66063 00258580 00000000 00000000 w3tp!THREAD_MANAGER::ThreadManagerThread+0x39
00c8ffec 00000000 5a301d80 00258580 00000000 kernel32!BaseThreadStart+0x34

Idle w3wp Compression Thread

7  Id: fb8.b20 Suspend: 0 Teb: 7ffaf000 Unfrozen ChildEBP RetAddr  Args to Child              017dfa84 7c822124 77e6baa8 000001d0 00000000 ntdll!KiFastSystemCallRet 017dfa88 77e6baa8 000001d0 00000000 00000000 ntdll!NtWaitForSingleObject+0xc 017dfaf8 77e6ba12 000001d0 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xac 017dfb0c 5a3b8147 000001d0 ffffffff 00000000 kernel32!WaitForSingleObject+0x12 017dffb8 77e66063 00000000 00000000 00000000 w3core!HTTP_COMPRESSION::CompressionThread+0x126 017dffec 00000000 5a3b8021 00000000 00000000 kernel32!BaseThreadStart+0x34

RPC Threads

놀고 있는 (Idle) LRPC Worker Thread들이 보인다면 이는 프로세스가 좀더 많은 리모트 COM 객체를 활성화 하거나 로컬 또는 리모트 COM method call들을 처리 할 수 있다는 뜻 입니다.

RPC Threading Model에 대해서는 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/scalability.asp  을 참고하세요.

Idle RPC Worker Thread

29  Id: fb8.7fc Suspend: 0 Teb: 7ffa1000 Unfrozen ChildEBP RetAddr  Args to Child              02ddfeac 7c821bf4 77e6611a 00000078 02ddff04 ntdll!KiFastSystemCallRet 02ddfeb0 77e6611a 00000078 02ddff04 02ddfef4 ntdll!NtRemoveIoCompletion+0xc 02ddfedc 77c604c3 00000078 02ddff14 02ddff04 kernel32!GetQueuedCompletionStatus+0x29 02ddff18 77c60655 ffffffff 02ddff6c 02ddff70 rpcrt4!COMMON_ProcessCalls+0xa1 02ddff84 77c5f9f1 02ddffac 77c5f7dd 00090250 rpcrt4!LOADABLE_TRANSPORT::ProcessIOEvents+0x117 02ddff8c 77c5f7dd 00090250 00000000 00000000 rpcrt4!ProcessIOEventsWrapper+0xd 02ddffac 77c5de88 0008e610 02ddffec 77e66063 rpcrt4!BaseCachedThreadRoutine+0x9d 02ddffb8 77e66063 029515e8 00000000 00000000 rpcrt4!ThreadStartRoutine+0x1b 02ddffec 00000000 77c5de6d 029515e8 00000000 kernel32!BaseThreadStart+0x34

Idle LRPC Worker Thread

33  Id: fb8.b24 Suspend: 0 Teb: 7ffdb000 Unfrozen ChildEBP RetAddr  Args to Child              02e1fe18 7c821c54 77c7538c 00000138 02e1ff74 ntdll!KiFastSystemCallRet 02e1fe1c 77c7538c 00000138 02e1ff74 00000000 ntdll!ZwReplyWaitReceivePortEx+0xc 02e1ff84 77c5778f 02e1ffac 77c5f7dd 0009d660 rpcrt4!LRPC_ADDRESS::ReceiveLotsaCalls+0x198 02e1ff8c 77c5f7dd 0009d660 00000000 00000000 rpcrt4!RecvLotsaCallsWrapper+0xd 02e1ffac 77c5de88 0008e610 02e1ffec 77e66063 rpcrt4!BaseCachedThreadRoutine+0x9d 02e1ffb8 77e66063 05057c08 00000000 00000000 rpcrt4!ThreadStartRoutine+0x1b 02e1ffec 00000000 77c5de6d 05057c08 00000000 kernel32!BaseThreadStart+0x34

기타 COM Threads 

STA컴퍼넌트(Single threaded component)들은 Main STA Thread에서 처리가 됩니다. Main STA는 최초로 실행된 COM STA Thread가 생성을 하게 되구요.

이전과 마찬 가지로 STA Thread들이 놀고 있다는 얘기는 현재 전달되어  Request가 적거나 없고 앞으로 전달 되는 Request들을 더 많이 처리 할 수 있다는 뜻 입니다.

Host STA Thread

31  Id: fb8.b3c Suspend: 0 Teb: 7ff4e000 Unfrozen ChildEBP RetAddr  Args to Child              049cff14 7739c78d 7739c7c0 049cff58 00000000 ntdll!KiFastSystemCallRet 049cff34 77694ff1 049cff58 00000000 00000000 user32!NtUserGetMessage+0xc 049cff74 776cf35b 00007530 77e6ba20 02a40fe0 ole32!CDllHost::STAWorkerLoop+0x72 049cff90 776cf2a3 049cffb8 776b2307 77790438 ole32!CDllHost::WorkerThread+0xc8 049cff98 776b2307 77790438 00000000 02a40fe0 ole32!DLLHostThreadEntry+0xd 049cffac 776b2374 00000000 049cffec 77e66063 ole32!CRpcThread::WorkerLoop+0x1e 049cffb8 77e66063 02a40fe0 00000000 00000000 ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x20 049cffec 00000000 776b2354 02a40fe0 00000000 kernel32!BaseThreadStart+0x34

Idle STA Thread

14  Id: e5c.d90 Suspend: 1 Teb: 7ffac000 Unfrozen ChildEBP RetAddr  Args to Child              0140fdcc 77f4372d 77e41bfa 00000003 0140fe1c SharedUserData!SystemCallStub+0x4 0140fdd0 77e41bfa 00000003 0140fe1c 00000001 ntdll!NtWaitForMultipleObjects+0xc 0140fe78 77d076f5 00000003 0140fea0 00000000 kernel32!WaitForMultipleObjectsEx+0x11a 0140fed4 77d077f5 00000002 0140ff74 ffffffff USER32!RealMsgWaitForMultipleObjectsEx+0x13f 0140fef0 7563439d 00000002 0140ff74 00000000 USER32!MsgWaitForMultipleObjects+0x1d 0140ff84 77bc91ed 000b6eb8 00000000 00000000 COMSVCS!CSTAThread::WorkerLoop+0x1e3 0140ffb8 77e4a990 00268a58 00000000 00000000 msvcrt!_threadstartex+0x6f 0140ffec 00000000 77bc917e 00268a58 00000000 kernel32!BaseThreadStart+0x34

COM Threading에 대해서는 다음의 URL을 참고 하세요.

COM Threading and Application Architecture in COM+ Applications

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomser/html/comthread.asp

문제가 발생하는 시점에 보면 아래와 같은 오류 메시지가 이벤트에 기록이 되면 Orchestration으로의 자료 전달시 오류가 발생합니다.

3/19/2009         오후 2:27:10      1        1        5815     BizTalk Server 2006        N/A      HCIFWEB1
A response message sent to adapter "WCF-Custom" on receive port "ReceivePort_From_SAP_RFC" with URI "sap://Client=XXX;lang=EN;@A/SOME_IP_ADDR/12?ListenerGwHost=SOME_IP_ADDR&ListenerGwServ=SAP_GW_SRV&ListenerProgramId=SAP_BIZTALK" is suspended.

     Error details: System.Xml.XmlException: '.', 16진수 값 0x00은(는) 잘못된 문자입니다. 줄 1, 위치 377

     위치: Microsoft.BizTalk.Component.XmlAsmStreamWrapper.Read(Byte[] buffer, Int32 offset, Int32 count)

     위치: System.Xml.XmlTextReaderImpl.InitStreamInput(Uri baseUri, String baseUriStr, Stream stream, Byte[] bytes, Int32 byteCount, Encoding encoding)

     위치: System.Xml.XmlTextReaderImpl..ctor(Stream stream, Byte[] bytes, Int32 byteCount, XmlReaderSettings settings, Uri baseUri, String baseUriStr, XmlParserContext context, Boolean closeInput)

     위치: System.Xml.XmlReader.CreateReaderImpl(Stream input, XmlReaderSettings settings, Uri baseUri, String baseUriStr, XmlParserContext inputContext, Boolean closeInput)

     위치: System.Xml.XmlReader.Create(Stream input, XmlReaderSettings settings, String baseUri)

     위치: System.Xml.XmlReader.Create(Stream input, XmlReaderSettings settings)

     위치: Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkBodyWriter.WriteBizTalkBody(XmlDictionaryWriter writer)

     위치: Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkBodyWriter.OnWriteBodyContents(XmlDictionaryWriter writer)

     위치: System.ServiceModel.Channels.BodyWriter.WriteBodyContents(XmlDictionaryWriter writer)

     위치: System.ServiceModel.Channels.BodyWriterMessage.OnWriteBodyContents(XmlDictionaryWriter writer)

     위치: System.ServiceModel.Channels.Message.OnGetReaderAtBodyContents()

     위치: System.ServiceModel.Channels.Message.GetReaderAtBodyContents()

     위치: Microsoft.Adapters.SAP.SAPInboundCountractReply.AdapterReply(Message message, TimeSpan timeout)

     위치: Microsoft.Adapters.AdapterUtilities.AdapterInboundReply.Reply(Message message, TimeSpan timeout)

     위치: Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestContext.Reply(Message message, TimeSpan timeout)

     위치: Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestContext.Reply(Message message)

     위치: System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.Reply(MessageRpc& rpc)     MessageId:  {xxxxxxxxx}    InstanceID: {YYYYYYYYYY}

문제는 자료를 아래와 같이 필드의 길이에 맞는 ASCII 문자만을 보낼 경우는 문제가 없었습니다. (아래의 Schema는 원래 자료의 내용을 바탕으로 재구성하였으며 SAP 서버에서 실제 생성된 것은 아닙니다.)

<?xml version="1.0" encoding="utf-8"?>
<SAP_Data_Root xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
  <TableDataElement>
    <TableData01 xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">
      <ProductCode>A100</ProductCode>
      <StandardCode>111</StandardCode>
      <TransitionType>2</TransitionType>
      <ProductName>333</ProductName>
      <RealNAME></RealNAME>
      <ShippingDate></ShippingDate>
    </TableData01>
  </TableDataElement>
</SAP_Data_Root>

한글을 포함한 자료를 SAP에서 보내게 되면 아래와 같이 공백과 함께 NULL Entity(&#x0;) 가 Field의 길이에 맞게 Padding 되는 듯하면서 추가되고 있는 것을 볼 수 있습니다. 이들 문자에 의해서 XML Validation이 실패하면서 Request를 정상처리하지 못하고 있었습니다.

<?xml version="1.0" encoding="utf-8"?>
<SAP_Data_Root xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
  <TableDataElement>
    <TableData01 xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">
      <ProductCode>A100</ProductCode>
      <StandardCode>111</StandardCode>
      <TransitionType>1</TransitionType>
      <ProductName>한글 한글 한글                                                        &#x0;&#x0;&#x0;&#x0;&#x0;&#x0;</ProductName>
      <RealNAME>한글 2 한                     &#x0;&#x0;&#x0;</RealNAME>
      <ShippingDate></ShippingDate>
    </TableData01>
  </TableDataElement>
</SAP_Data_Root>

관련 문제는 SAP RFC SDK 7.1 UNICODE 를 SAP RFC SDK 7.0 UNICODE로 downgrade 하면서 해결 되었습니다. 아마도 SAP RFC SDK 7.1 UNICODE 버젼에 MBCS 스트링 자료 처리에 문제가 있었을 것으로 보입니다만 정확한 원인 확인은 좀 더 시간일 걸릴 것으로 보입니다.

SAP RFC SDK를 다운로드 하는 방법은 아래의 Blog 글을 참고하세요. 물론 SAP쪽의 지원 계약이 있으셔야 다운로드가 가능합니다.

http://blogs.msdn.com/adapters/archive/2007/10/07/obtaining-the-rfc-sdk-unicode-libraries-from-sap-service-marketplace.aspx

BizTalk Server 설치 이후에 SAP의 TABLE Type이 지원되는 않을 경우, 아래의 KB에서 언급하는 Hotfix를 설치해야 할 수 있습니다.

FIX: The Windows Communication Foundation (WCF) based SAP adapter from BizTalk Server 2006 Adapter Pack v1.0 does not support the SAP TABLE type

http://support.microsoft.com/kb/956635]]> https://docs.microsoft.com/archive/blogs/yonghp/microsoft-net-micro-framework-netmf-porting-kit-3-0 Thu, 26 Mar 2009 12:11:00 GMT https://blogs.msdn.microsoft.com/yonghp/2009/03/26/microsoft-net-micro-framework-netmf-porting-kit-3-0/ PDA들은 Windows Mobile(Windows CE라고 불린던) 을 쓴다 치더라도 기능이 좀 어중간한 ARM7 CPU 보드에서 .Net Framework을 쓸 수 있으면 좋겠구나 하는 생각을  왔습니다. 

처음 .Net Micro Framework에 대해서 들었을 때는 드디어 그게 가능해 졌구나 하는 생각을 했습니다. 하지만, 좀 자세히 들어가서 보니 조금은 실망스러운 것이 역시나 인증된 (즉, 상대적으로 가격이 비싼) 보드 매이커의 제품만을 사용해야 한다는 것 이었습니다.

얼마전에 출시된  .Net Micro Framework Porting Kit을 이용해서 새로운 플랫폼이나 기존의 플랫폼에  .NetMF의 포팅이 쉬워졌네요.

Getting Started with the Porting Kit
http://blogs.msdn.com/netmfteam/pages/getting-started-with-the-porting-kit.aspx

그런데, 여기에 더 놀라운 것은 기존의 Embedded Software 개발시 구입해야 했던 비싼 개발 도구를 반드시 쓸 필요는 없다는 것 이지요.  .NetMF팀에서 GCC로 이미 테스트를 했고 써도 된 답니다.

Update on Using GCC to Port the .NET Micro Framework in .NET Micro Framework Porting
https://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.dotnet.framework.microframework.porting&tid=e6575c5e-f1ce-4bab-897f-96be45b818f9&cat=en_US_38A7B5A8-BCC6-4cc8-BE52-832E765A449B&lang=en&cr=US&sloc=&p=1

In version 3.0, .NET Micro Framework team added support for the Gnu Compiler
Collection (GCC) for evaluation purposes as noted in the documentation. Due
to customer requests, we have reviewed this policy and now fully support the
GCC as a toolchain for porting the .NET Micro Framework. We on the .NET Micro
Framework team wish to thank all of our partners, customers, and enthusiasts
for their feedback, ideas, and input.

Please be aware that it is our experience that using GCC to port the .NET
Micro Framework results in firmware that is larger and slower than the
firmware produced by toolchains such as RVDS or MDK. We have reduced the
memory footprint of the framework in the version 3.0 release to extend the
.NET Micro Framework support for even smaller processors. To get the smallest
and most efficient binaries, we still recommend the use of the ARM or Keil
toolchains.

아래의 링크들을 참고 하시기 바랍니다.

Precompiled GCC Toolchains for the Porting Kit
http://msmicroframework.blogspot.com/2009/02/precompiled-gcc-toolchains-for-porting.html

Configuring Eclipse + OpenOCD + GCC to Debug NativeSample
http://msmicroframework.blogspot.com/2009/02/configuring-eclipse-openocd-gcc-to.html

How to use Eclipse and GDB to debug the .NET Micro Framework
http://discovertheexperience.blogspot.com/2008/11/how-to-use-eclipse-and-gdb-to-debug-net_09.html

Sourcery G++ Lite 2007q3-53 for ARM EABI
http://www.codesourcery.com/sgpp/lite/arm/portal/release316

.NET Micro Framework Porting Kit V3.0 with GCC Support?
http://discovertheexperience.blogspot.com/2008/11/net-micro-framework-porting-kit-v30.html

링크에서 Physical Memory관련 설정도 확인 할 수 있습니다.

Memory Limits for Windows Releases

http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx

Memory and Address Space Limits

The following table specifies the limits on memory and address space for supported releases of Windows.

Advances in Memory Management for Windows

http://www.microsoft.com/whdc/system/sysinternals/memmgt.mspx

Dynamic Allocation of Kernel Virtual Address Space

In Windows Vista and later Windows releases, kernel VA space is dynamically allocated. The sizes and locations of important system resources—including the paged and nonpaged memory pools—are no longer fixed, but instead are dynamically adjusted according to operational requirements. As a result, system tuning is automatic. Administrators are not typically required to manually reconfigure systems to prevent resource imbalances.

Figure 2. Kernel Virtual Address Space

기타 메모리 관련 참고 사항 (위 문서에서 언급하고 있는 내용들 입니다) :

MSDN:

Windows Vista ISV Security

http://msdn2.microsoft.com/en-us/library/bb430720.aspx

Memory Management Registry Keys

http://msdn2.microsoft.com/en-us/library/bb870880.aspx

Windows Driver Kit:

http://msdn2.microsoft.com/en-us/library/aa972908.aspx

Kernel-Mode Driver Architecture Design Guide
Memory Management
Interrupt Affinity and Priority
Standard Event Objects

Kernel-Mode Driver Architecture Reference
Standard Driver Routines
Driver Support Routines

Driver Development Tools
Boot Options for Driver Testing and Debugging

Network Design Guide
NDIS MSI-X

Windows Hardware and Driver Central:

Driver Signing Requirements for Windows [home page]

http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx

Digital Signatures for Kernel Modules on Systems Running
      Windows Vista
Summary of Windows Kernel-Mode Driver Signing Requirements

Windows PC Accelerators: Performance Technology for Windows Vista

http://www.microsoft.com/whdc/system/sysperf/accelerator.mspx

What Is Really in That MDL?

http://www.microsoft.com/whdc/driver/tips/mdl.mspx

Interrupt Architecture Enhancements in Windows

http://www.microsoft.com/whdc/system/bus/PCI/MSI.mspx

NUMA I/O Optimizations

http://download.microsoft.com/download/a/f/d/afdfd50d-6eb9-425e-84e1-b4085a80e34e/SVR-T332_WH07.pptx

Microsoft TechNet:

Inside the Windows Vista Kernel: Part 3 (April 2007)

http://www.microsoft.com/technet/technetmag/issues/2007/04/VistaKernel/

Book:

Windows Internals, Fourth Edition,
Russinovich, Mark, and David A. Solomon. Redmond, WA: Microsoft Press, 2005

http://www.microsoft.com/MSPress/books/6710.aspx

2. 기본 설정일 경우 아래와 같은 다이얼로그 박스가 기본적으로 표시됩니다. 그렇지 않은 경우 DebugDiag 의 메인 화면에서 “Add Rule” 버튼을 클릭 하시기 바랍니다.

3. Rule Type을 선택하는 화면에서 3번째 형태인 “Memory and Handle Leak”을 선택하시고 “Next”버튼을 클릭 하세요.

4. 현재 버젼에서는 DebugDiag의 LeakTrack Rule 을 이용해서 여러개의 프로세스를 동시에 감시할 수 없습니다. 아래 그림과 같이 현재 실행 중인 프로세스 중에 문제 프로세스를 선택하시고 “Next”를 선택 합니다.

5. 다음 화면에서 아래 그림과 같이 Leak Rule을 설정 합니다. 일단 프로세스에 대한 Leak Rule의 작동과 동시에 Tracking을 시작하도록 하고

6. 원래 10개의 덤프를 수집하도록 한 “Maximum number of userdumps created by this rule”을 적절한 값을 설정해 주시기 바랍니다. 아래 그림에서는 5로 변경해 놓은 상태 입니다.

7. 좀더 자세한 모니터링을 위해서 화면 중간의 “Configure…” 버튼을 클릭 합니다.

8. 새로 표시되는 아래와 같은 다이얼로그 박스 화면에서 “Generate a userdump when virtual bytes reach” 를 설정하세요.

9. 이경우 프로세스의 메모리 사용량이 500메가 바이트가 넘는 시점 부터 덤프를 생성하기 시작합니다. 프로세스 초기 실행시 메모리 사용량에 따라서 이값을 변경해 주시면 됩니다.

즉, 최초 실행 시 Private Bytes가 200메가 바이트라면 이값을 250메가 바이트로 설정해 주시면 메모리 사용량이 증가하기 시작하는 시점에 덤프를 생성하기 시작합니다.

10. LeakTrace은 프로세스 실행시에 메모리나 핸들을 사용하는 콜들을 Hooking해서 관련 Call이 일어나는 Thread의 Stack Trace를 메모리에 저장하게 됩니다. 이들 메모리에 의해서 실제 프로세스에서 나타나는 메모리 문제가 좀더 빨리 진행 될 수도 있으니 유의 하시기 바랍니다.

11. “add each addition ???MB there after” 를 선택 하시면 이후 어느 정도 메모리가 증가할 때 마다 추가적으로 덤프를 수집하도록 할 수 있습니다. 아래 설정에서는 200 메가 바이트가 증가하게 되면 덤프를 수집하도록 해 놨습니다.

12. 만일 Leak과 함께 Crash 현상이 같이 발생하는 경우 “Auto-create a crash rule to get userdump on unexpected process exit.”를 선택 하시면 프로세스 종료시에 덤프가 생성 됩니다. 이는 Hang과 Crash를 동시에 감시하도록 합니다.

13. “Save & Close” 버튼을 클릭하셔서 새로 표시된 다이얼로그 박스를 닫으신 후 “Next” 버튼을 클릭하세요.

14. 다음 화면에서 새로생성된 “Rule”의 이름과 덤프가 저장될 기본 위치를 확인 하세요.

15. “Next” 버튼을 클릭하세요.

16. 마지막으로 “Activate the rule now”를 선택 하셔서 Rule이 바로 모니터링을 시작하도록 하신 후 “Finish” 버튼을 클릭 하세요.

17. 여러개의 프로세스에 대한 LeakTrack을 하고 싶으신 경우 각각의 프로세스에 대해서 별도의 Rule을 추가하시거나 아래 그림과 같이 개별 프로세스에 대한 LeakTrace을 Eanble하시고 메모리 상태를 감시하면서 감시하시면서 Hang Dump를 수집하실 수 있습니다.

* LeakTrack이 Enable된 프로세스는 아래 그림과 같이 “LeakTrack Status” column에 “Tracking”이라고 표시가 됩니다.

Private Bytes와 Virtual Bytes 및 성능모니터로 Leak 을 확인하는 방법은 아래의 링크 내용을 참고하세요.

Using Performance Monitor to Find a User-Mode Memory Leak

http://msdn.microsoft.com/en-us/library/cc267846.aspx

The Private Bytes counter indicates the total amount of memory that a process has allocated, not including memory shared with other processes.

The Virtual Bytes counter indicates the current size of the virtual address space that the process is using. ]]> https://docs.microsoft.com/archive/blogs/yonghp/registry-biztalk-server-version Wed, 04 Feb 2009 03:54:57 GMT https://blogs.msdn.microsoft.com/yonghp/2009/02/04/registry-biztalk-server-version/ 이 포스트는 아래 블로그 포스팅 내용을 한글화 한 것 입니다.

Identify the version of installed BizTalk
http://blogs.msdn.com/kerreybpi/archive/2009/01/12/identify-the-version-of-installed-biztalk.aspx

현재 서버에서 작동 중인 BizTalk Server의 버젼을 확인을 쉽게 할 수 있는 방법 입니다.

아래그림과 같이 레지스트리 에티터를 여신 후 HKEY_LOCAL_MACHINE -> Software -> Microsoft -> BizTalk Server -> 3.0 아래에 ProductVersion 값을 확인 하시면 됩니다.

위의 값고 아래 테이블을 참고하세요.

일단 메시지 파일을 Receive Location에서 설정된 Pickup 폴더에 복사하고 이파일이 없어지는 것을 보고 일단 메시지가 전달된 것으로 생각할 수 있습니다.

문제는 이 파일의 복사본을 유지하고 싶은 경우 현재 BizTalk Server가 지원하지 않는다는 것 입니다. 관련 기능을 원하시는 경우 아래의 CodePlex에서 제공되는 Message Archive Pipeline Component를 사용해 보시기 바랍니다.

대신 소스 코드가 같이 제공이 되고 있기 때문에 관련 Component에 기능추가 역시 가능 합니다. 물론 기능사용 전에 라이센스 역시 주의 해서 읽어 보시기 바랍니다.

BizTalk 2006 Message Archiving Pipeline Component

http://www.codeplex.com/btsmsgarchcomp

위의 URL에서 다운로드 가능한 컴퍼넌트를 BizTalk Server에 설치 하신 후 Receive/Send Pipeline의 Decode stage에 넣어주신 후 관련 컴퍼넌트의 Properties를 설정해 주시면 됩니다.

사용법은 다음과 같습니다.

1. 웹사이트에서 복사하신 파일의 압축을 푸신 후 Modhul.BizTalk.Pipelines.ArchiveMessages.dll 파일을 BizTalk 서버의 설치 폴더내 Pipeline Component 폴더 (일반적으로 C:\Program Files\Microsoft BizTalk Server 2006\Pipeline Components) 에 복사 하세요.

2. Message File의 Archive 기능이 필요한 BizTalk Application Project에서 Receive Pipeline 을 추가하시고 (이미 있는 경우는 다음으로 진행하세요)

3. 파이프 라인 파일을 여신 후 BizTalk Pipeline Components Toolxbox 에서 오른쪽 마우스 버튼을 클릭하셔서 “아이템 선택”을 클릭하시면 아래와 같은 다이얼로그 박스가 나타납니다.

4. 아래 그림과 같이 “BizTalk Pipeline Components” 탭을 선택 하시고 Browser 버튼을 선택하셔서 1번에서 복사한 폴더로 이동 하신 후 컴퍼넌트를 선택하세요.

5. 컴퍼넌트의 선택이 정상적으로 완료되면 아래와 같이 Toolbox 내에 “Archive Messages”라는 컴퍼넌트가 추가 됩니다.

6. 추가된 컴퍼넌트를 선택하신 후 Drag 하셔서 “Decode” stage내의 추가 하시기 바랍니다.

7. 선택된 컴퍼넌트의 설정가능한 속성은 아래와 같습니다. 저장될 폴더 위치와 파일 이름등이 제공되고 있습니다. 기존에 사용 중인 MacroDefinition 파일이 있으시면 File이나 FTP 관련 부분을 추가 하신 후 MacroDefinitionFile Property에 위치를 적어주셔도 됩니다.

좀더 자세한 기능은 Readme.txt파일을 확인하시기 바랍니다.

실제 파일을 저장하는 부분은 “ArchiveMessages.cs” 파일내의 StreamOnReadEvent EnentHandler에서 아래와 같이 코딩되어 있습니다.

private void StreamOnReadEvent(object src, EventArgs args)
{
    ReadEventArgs rargs = args as ReadEventArgs;

    if (rargs != null)
    {
        try
        {
            using (
                FileStream FileArchiveStream =
                    new FileStream(_archiveFilePath, FileMode.Append, FileAccess.Write))
            {
                using (BinaryWriter FileBinaryWriter = new BinaryWriter(FileArchiveStream))
                {
                    FileBinaryWriter.Write(rargs.buffer, 0, rargs.bytesRead);

                    // Close the file writer.
                    FileBinaryWriter.Flush();
                    FileBinaryWriter.Close();
                }
            }
        }
        catch (IOException Ex)
        {
            ...
        }
    }
    else
    {
        ....

    }
}

파일이 저장되도록 하기 위한 Event Handler의 등록은 IComponent Interface의 Execute Method를 Implement하는 코드에 나타납니다.

IComponent.Execute Method

http://msdn.microsoft.com/en-us/library/microsoft.biztalk.component.interop.icomponent.execute.aspx

public IBaseMessage Execute(IPipelineContext Context, IBaseMessage InMsg)
{
    // Validate the Macro Definition configuration file.
    if (ValidationHelper.ValidateMacroDefinitionsXmlConfiguration(_macroDefinitionsFile))
    {
        // Validate number of macro identifiers.
        if ((ValidationHelper.ValidateMacros(InMsg.MessageID, "Archive Directory", _archiveDirectoryMacroPath) &&
             (ValidationHelper.ValidateMacros(InMsg.MessageID, "Archive Filename", _archiveFilenameMacroPath))))
        {
            if (InMsg.BodyPart != null)
            {
                // Expand macros and build the archive file path.
                _archiveFilePath = BuildArchiveFilePath(InMsg);

                // Wrap original stream in a Forward Only Event Stream (FOES) and
                // configure the read-event.
                Stream dataStream = InMsg.BodyPart.GetOriginalDataStream();
                CForwardOnlyEventingReadStream eventingStream = new CForwardOnlyEventingReadStream(dataStream);
                eventingStream.ReadEvent += new ReadEventHandler(StreamOnReadEvent);

                // Assign FOES wrapper back to the BodyPart.
                InMsg.BodyPart.Data = eventingStream;
            }
        }
    }

    return (InMsg);
}

Blocking on sql can occur if the Maximum job history log size is greater than 1000 on the sql server agent

http://blogs.msdn.com/biztalkcpr/archive/2008/05/08/blocking-on-sql-can-occur-if-the-maximum-job-history-log-size-is-greater-than-1000-on-the-sql-server-agent.aspx

위의 글에서 언급하는 것과 같이 특별한 이유 없이 (즉, MessageBox나 DTADB의 크기나 부하에 크게 연관이 없이) 서비스 작동 중 BizTalk 서버의 메시지 전달 속도가 간헐적으로 현저하게 저하되는 문제가 발생하는 경우가 있습니다. 이때 문제 원인 확인을 위해서 SQL Profiler 로그를 확인한 결과 다음의 stored procedure에 의해서 SQL Blocking이 발생하고 있는 경우 아래의 내용을 참고하셔서 SQL Agent Job의 Maximum job history log의 size를 설정해 주시기 바랍니다.

CREATE PROCEDURE sp_jobhistory_row_limiter    @job

SELECT @current_rows_per_job = COUNT(*)    FROM msdb.dbo.sysjobhistory with (TABLOCKX)    WHERE (job_id = @job_id)      ...

위의 SP는 MsgBoxPerfCounters_GetPurgeJobInfo SP에 의해서 호출이되며 각각의 BizTalk Agent Job들이 얼마나 호출되었는지를 확인하는 위해서 사용 됩니다.

원본 블로그 글의 경우 이 SP가 만드는 Temp Table의 Row Count가 50000을 넘어가면서 문제가 나타났다고 합니다.

다음 내용은 SQL 2005서버에서의 설정 방법 입니다.

1. BizTalk Server가 사용하는 SQL Server 에서 아래의 그림과 같이 “SQL Server Management Studio”를 실행 하신 후 왼쪽의 Object Explorer에서 “SQL Server Agent”를 선택 하시고 오른쪽 마우스 버튼을 클릭 하신 후 속성창을 실행하세요.

2. 아래의 그림과 같은 SQL Server Agent Properties 창에서 왼쪽 항목의 마지막에 있는 “History” 를 선태하세요.

3. 아래의 그림에서 오른쪽의 붉은 박스 내용과 비교하셔서 “Limit size of history log” 항목을 선택하시고 “Maximum job history rows per job” 항목의 값이 1000을 넘지 않도록 설정해 주시기 바랍니다.