.net Application висит. Weird crash-dump

Question

Производственный сервер имеет приложение, работающее 24x7, и иногда оно начинает потреблять около 50% CPU. Я не мог воспроизвести его локально, но я сделал дамп памяти с adplus. На сервере имеется 64-битный Windows Server 2008, .NET 3.5. Приложение прослушивает MSMQ и имеет пул потоков для выполнения операций, когда я делал дамп памяти, в котором, как предполагалось, ничего не запускалось, но он все еще потреблял процессор.

Ниже дамп. Вы знаете, что может случиться? Странно, что медленная нить также говорит GC Disabled! Что это?

Странно. У меня есть приложение 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 

Answer 1

Я далеко не эксперт здесь, но кое-что может быть полезно:

• Согласно this, GC потоки создаются при запуске среды CLR, по крайней мере, для сервера GC, так не имея достаточное количество потоков для GC перспективы, возможно, даже не возможно ;-)

• «заблокирован» в колонке «ГК» из нити 21 просто означает, что он не решил на нет t быть предварительно обработанной GC . Это происходит, когда код на потоке решает, что выполняет критическую операцию, которую не должен нарушать GC (например, погрузка и сборка, следовательно, слияние).

• С «КБ» вывода команды я бы догадаться, что вы на самом деле с помощью GC сервера (StackFrame «mscorwks SVR :: gc_heap :: make_heap_segment!»; рабочая станция GC будет иметь что-то с классом/namespace "WKS"). Это не является неожиданным, так как должно быть по умолчанию на «сервере ». Вы должны убедиться в этом, используя команду «! Eeversion». Кроме того, вы должны узнать, сколько ядер у вас есть, потому что если сервер GC работает,
  будет использовать столько потоков (по одному на каждое логическое/физическое ядро).

Может случиться так, что таймер стреляет довольно часто или быстрее, чем предыдущий закончен. Вы можете получить обзор использования потока threadpool с помощью команды «! ThreadPool».

Также вы можете проверить фактические аргументы методам и locals (! Clrstack -a) и/или текущим объектам в стеке (! Dso). Может быть, это может пролить немного света.

Как можно предположить, некоторые поисковые запросы для «System.Net.ConnectionPool.CleanupCallbackWrapper» дают следующие ссылки, может быть, это может быть вашей проблемой?

• Debugging high cpu usage
• SmtpClient does not close session after sending message
• issue with high cpu usage in web app with no load