.net 애플리케이션이 중단되었습니다.이상한 크래시 덤프
-
19-09-2019 - |
문제
프로덕션 서버에는 연중무휴로 실행되는 애플리케이션이 있으며 때로는 CPU의 거의 50%를 소비하기 시작합니다.로컬에서 재현은 못했는데 adplus로 메모리 덤프를 해봤습니다.서버에 Windows 2008 Server 64비트, .NET 3.5가 있습니다.응용 프로그램은 MSMQ를 수신하고 작업을 실행하기 위한 스레드 풀을 가지고 있습니다. 메모리 덤프를 수행했을 때 아무것도 실행되지 않을 것으로 예상되었지만 여전히 CPU를 소비하고 있었습니다.
아래는 덤프입니다.무슨 일이 일어날 수 있는지 아시나요??느린 스레드에도 GC 비활성화라고 표시되는 것이 이상합니다!그게 뭐야?
같은 서버에 ASP.NET 앱이 있는데 가끔 같은 일이 발생한다는 것이 이상합니다.
0:000> !threads
ThreadCount: 23
UnstartedThread: 0
BackgroundThread: 6
PendingThread: 0
DeadThread: 5
Hosted Runtime: no
PreEmptive Lock
ID OSID ThreadOBJ State GC GC Alloc Context Domain Count APT Exception
0 1 1ec0 0000000000249c10 a020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
2 2 84c 0000000000253470 b220 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA (Finalizer)
3 3 10b8 0000000019d0f900 80a220 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA (Threadpool Completion Port)
5 4 2184 0000000019d4a550 880b220 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA (Threadpool Completion Port)
6 6 14a0 0000000019d602a0 180b220 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA (Threadpool Worker)
8 7 490 0000000019d7db70 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
9 8 2164 0000000019dae680 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
10 9 ac0 0000000019db4740 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
11 a 24cc 0000000019db51f0 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
12 b 1fb4 0000000019db5ca0 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
13 c 2408 0000000019db1520 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
14 d 1b44 0000000019db1fd0 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
15 e 1280 0000000019db2a80 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
16 f 206c 0000000019db8780 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
17 10 1ff8 0000000019db9230 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
18 11 2548 0000000019dc2120 200b020 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA
20 18 2588 0000000019dc49d0 180b220 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 MTA (Threadpool Worker)
21 1a 20a0 0000000019dc5570 b220 Disabled 0000000001653d88:0000000001655978 00000000002410b0 1 MTA
XXXX 26 0 0000000019dc89c0 9820 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 Ukn
XXXX 2c 0 0000000019dc5b40 9820 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 Ukn
XXXX 2b 0 0000000019dc3290 9820 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 Ukn
XXXX 5 0 0000000019dc8f90 9820 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 Ukn
XXXX 27 0 0000000019dc7850 9820 Enabled 0000000000000000:0000000000000000 00000000002410b0 0 Ukn
0:000> !runaway
User Mode Time
Thread Time
**21:20a0 0 days 0:27:21.718**
6:14a0 0 days 0:00:01.921
18:2548 0 days 0:00:01.015
2:84c 0 days 0:00:00.890
(18 more....)
0:000> ~21s
*** WARNING: Unable to verify checksum for System.ni.dll
mscorwks!JIT_WriteBarrier_Fast+0x3:
000007fe`f88de5c3 4881fa607f4701 cmp rdx,1477F60h
0:021> !clrstack
OS Thread Id: 0x20a0 (21)
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
Child-SP RetAddr Call Site
000000001b05f090 000007fef651b1ba System.Net.TimerThread+TimerNode..ctor(Callback, System.Object, Int32, System.Object)
000000001b05f0d0 000007fef69a0c3f System.Net.TimerThread+TimerQueue.CreateTimer(Callback, System.Object)
000000001b05f180 000007fef651b73e System.Net.ConnectionPool.CleanupCallbackWrapper(Timer, Int32, System.Object)
000000001b05f1d0 000007fef651b560 System.Net.TimerThread+TimerNode.Fire()
000000001b05f2a0 000007fef64e6388 System.Net.TimerThread+TimerQueue.Fire(Int32 ByRef)
000000001b05f330 000007fef271175b System.Net.TimerThread.ThreadProc()
000000001b05f400 000007fef27a95fd System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
000000001b05f450 000007fef88e1552 System.Threading.ThreadHelper.ThreadStart()
0:021> kb
RetAddr : Args to Child : Call Site
000007fe`f6a1b87e : 00000000 (Edited) : mscorwks!JIT_WriteBarrier_Fast+0x3
000007fe`f651b1ba : 00000000 (Edited) : System_ni+0x70b87e
000007fe`f69a0c3f : 00000000 (Edited) : System_ni+0x20b1ba
000007fe`f651b73e : 000007fe (Edited) : System_ni+0x690c3f
000007fe`f651b560 : 00000000 (Edited) : System_ni+0x20b73e
000007fe`f64e6388 : 00000000 (Edited) : System_ni+0x20b560
000007fe`f271175b : 00000000 (Edited) : System_ni+0x1d6388
000007fe`f27a95fd : 00000000 (Edited) : mscorlib_ni+0x2f175b
000007fe`f88e1552 : 00000000 (Edited) : mscorlib_ni+0x3895fd
000007fe`f877e5e3 : 00000000 (Edited) : mscorwks!CallDescrWorker+0x82
000007fe`f878c83f : 00000000 (Edited) : mscorwks!CallDescrWorkerWithHandler+0xd3
000007fe`f887ae8d : 00000000 (Edited) : mscorwks!MethodDesc::CallDescr+0x24f
000007fe`f8839374 : 00000000 (Edited) : mscorwks!ThreadNative::KickOffThread_Worker+0x191
000007fe`f8732045 : 00000000 (Edited) : mscorwks!TypeHandle::GetParent+0x5c
000007fe`f8846139 : 00000000 (Edited) : mscorwks!SVR::gc_heap::make_heap_segment+0x155
000007fe`f8700e15 : 00000000 (Edited) : mscorwks!ZapStubPrecode::GetType+0x39
000007fe`f8700ae7 : 00000000 (Edited) : mscorwks!ThreadNative::KickOffThread+0x401
000007fe`f88614fc : 00000002 (Edited) : mscorwks!ThreadNative::KickOffThread+0xd3
00000000`76bdbe3d : 00000000 (Edited) : mscorwks!Thread::intermediateThreadProc+0x78
00000000`76d16a51 : 00000000 (Edited) : kernel32!BaseThreadInitThunk+0xd
해결책
저는 여기 전문가는 아니지만 유용할 수 있는 추가 정보는 다음과 같습니다.
에 따르면 이것, GC 스레드는 적어도 서버 GC의 경우 CLR 스타트 업에서 생성되므로 GC 실행을위한 충분한 스레드가 없을 수도 있습니다. ;-)
스레드 21의 "GC"열에서 "비활성화"는 최종 GC 작업에 의해 예약되지 않기로 결정했음을 의미합니다.이는 스레드의 코드가 GC에 의해 방해해서는 안되는 중요한 작업을 수행한다고 결정하면 (로딩 및 어셈블리와 같은 융합).
"KB"명령 출력에서 실제로 서버 gc (stackframe "mscorwks! svr :: gc_heap :: make_heap_segment"를 사용하고 있다고 생각합니다.워크스테이션 GC에는 뭔가가 있을 것입니다. 클래스/네임스페이스 "WKS")를 사용합니다.이것은 예상치 못한 일이 아닙니다 "서버의 기본값이 되십시오. 운영" 시스템."!eeversion" 명령을 사용하여 이에 대해 확인해야 합니다.또한 서버 GC가 실행되면 보유하고 있는 코어 수를 확인해야 합니다.
많은 스레드(논리적/물리적 코어당 하나)를 사용합니다.
타이머가 꽤 자주 실행되거나 이전 타이머보다 빠르게 종료될 수도 있습니다."!ThreadPool" 명령을 사용하여 스레드풀 스레드 사용량에 대한 개요를 얻을 수 있습니다.
또한 메서드와 로컬(!clrstack -a) 및/또는 스택의 현재 개체(!dso)에 대한 실제 인수를 확인할 수도 있습니다.아마도 그것은 좀 더 많은 빛을 비출 수 있을 것입니다.
추측에 따르면 "System.Net.ConnectionPool.CleanupCallbackWrapper"에 대한 일부 인터넷 검색에서는 다음 링크가 표시됩니다. 아마도 이것이 문제일 수 있습니까?