WinDbg анализ аварийного дампа, высокая загрузка процессора -

Моего приложение (веб-апи) страдают с высоким центральным процессором, анализируя дамп, я вижу свою большую часть нитей имеет эту dumpstack -:WinDbg анализ аварийного дампа, высокая загрузка процессора -

Child-SP   RetAddr   Caller, Callee 
00000030497bec00 00007ffbb19e1118 KERNELBASE!WaitForSingleObjectEx+0x94, 

    calling ntdll!NtWaitForSingleObject 
    00000030497beca0 00007ffba8375dda clr!CLRSemaphore::Wait+0xee, calling kernel32!WaitForSingleObjectEx 
    00000030497becd0 00007ffba837345d clr!GCCoop::GCCoop+0xe, calling clr!GetThread 
    00000030497bed60 00007ffba8375842 clr!ThreadpoolMgr::WorkerThreadStart+0x482, calling clr!CLRSemaphore::Wait 
    00000030497bee00 00007ffba8393e1e clr!Thread::intermediateThreadProc+0x7d 
    00000030497bee30 00007ffbb19e1f86 KERNELBASE!ConsoleCallServerGeneric+0xf2, calling KERNELBASE!_security_check_cookie 
    00000030497bee50 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset 
    00000030497beed0 00007ffbb450d0c6 ntdll!LdrpGetProcedureAddress+0x66, calling ntdll!RtlImageNtHeaderEx 
    00000030497bef50 00007ffbb450c6f5 ntdll!LdrpResolveNonStaticDependency+0x1cd, calling ntdll!LdrpDereferenceNode 
    00000030497befd0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext 
    00000030497bf000 00007ffbb45011a5 ntdll!RtlpLowFragHeapAllocFromContext+0x355, calling ntdll!memset 
    00000030497bf020 00007ffbb450f5f3 ntdll!LdrGetProcedureAddressForCaller+0x153, calling ntdll!_security_check_cookie 
    00000030497bf030 00007ffb93fc8c84 mfc120u!DllMain+0x210, calling mfc120u!__security_check_cookie 
    00000030497bf080 00007ffba8ce2cbb mscoreei!operator delete+0x34, calling kernel32!HeapFreeStub 
    00000030497bf0d0 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext 
    00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext 
    00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain 
    00000030497bf1e0 00007ffb979dbc9d clrcompression!calloc_impl+0x5d, calling ntdll!RtlAllocateHeap 
    00000030497bf210 00007ffb979d8eff clrcompression!initptd+0xb7, calling clrcompression!unlock 
    00000030497bf230 00007ffbb44ebf57 ntdll!RtlDeactivateActivationContextUnsafeFast+0xc7, calling ntdll!_security_check_cookie 
    00000030497bf240 00007ffb979d7919 clrcompression!CRT_INIT+0x135, calling kernel32!GetCurrentThreadId 
    00000030497bf270 00007ffb979d7a0e clrcompression!__DllMainCRTStartup+0x8a, calling clrcompression!DllMain 
    00000030497bf280 0000000056b32052 msvcr100!_initptd+0xaa, calling msvcr100!_unlock 
    00000030497bf2a0 00007ffbac051779 IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0x679, calling IitTlsCleanupHelper!UnregisterTLSCleanupCallback+0xf0 
    00000030497bf2b0 0000000056b31308 msvcr100!__CRTDLL_INIT+0x16c, calling msvcr100!_CrtEndBoot 
    00000030497bf2d0 00007ffbb450bee8 ntdll!LdrpReleaseModuleEnumLock+0x1c, calling ntdll!RtlReleaseSRWLockShared 
    00000030497bf2e0 00007ffbb44ec0f4 ntdll!LdrpCallInitRoutine+0x4c 
    00000030497bf300 00007ffbb450be9b ntdll!LdrpReleaseLoaderLock+0x27, calling ntdll!LdrpReleaseModuleEnumLock 
    00000030497bf340 00007ffbb44ebe53 ntdll!LdrpInitializeThread+0x1f3, calling ntdll!LdrpReleaseLoaderLock 
    00000030497bf3b0 00007ffbb44ebd93 ntdll!LdrpInitializeThread+0x133, calling ntdll!RtlActivateActivationContextUnsafeFast 
    00000030497bf3b8 00007ffbb44ebdc6 ntdll!LdrpInitializeThread+0x166, calling ntdll!RtlDeactivateActivationContextUnsafeFast 
    00000030497bf420 00007ffbb44e8d73 ntdll!_LdrpInitialize+0x93, calling ntdll!NtTestAlert 
    00000030497bf490 00007ffbb44e8c98 ntdll!LdrInitializeThunk+0x18, calling ntdll!NtContinue 
    00000030497bf900 00007ffba8393e07 clr!Thread::intermediateThreadProc+0x66, calling clr!_chkstk 
    00000030497bf940 00007ffbb43613d2 kernel32!BaseThreadInitThunk+0x22 
    00000030497bf970 00007ffbb44e54e4 ntdll!RtlUserThreadStart+0x34

Моих сомнения находится в этих трех строках -:

ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext 
00000030497bf140 00007ffbb4500d07 ntdll!RtlAllocateHeap+0xd7, calling ntdll!RtlpLowFragHeapAllocFromContext 
00000030497bf180 00007ffbac0c51bd gzip!DllMainCRTStartup+0x139, calling gzip!DllMain

Может ли эта нить быть причиной высокого использования процессора?

источник

2016-10-04 user3359453

я уже бежать!runaway, это одна из трассировок стека .. и их много потоков с одной и той же трассировкой стека. Просто пытаюсь понять, что трассирует эта трассировка стека. Хотя я сомневаюсь, что этот поток является виновником использования процессора .. – user3359453

Да. Отвечает ли это на ваш вопрос? Потоки выполняются на процессоре, поэтому потоки используют процессорное время и делают высокий процессор. В отличие от памяти. Память не выполняется на CPU, поэтому она не вызывает больших проблем с ЦП. Возможно, вы хотите перефразировать вопрос, чтобы получить ответ, который соответствует вашим потребностям. –

WinDbg - отличный инструмент, но не подходящий инструмент для этой работы. Он может предоставить вам информацию только об одном конкретном моменте времени. Чтобы получить более целостное представление о том, что делает ваше приложение, вы должны использовать что-то вроде ETW * (или procmon) * и делать выводы оттуда. Тем не менее, вы, кажется, сжимаете что-то, чтобы я ожидал * высокий процессор. –

В соответствии со статьи - http://msdn.microsoft.com/en-us/library/bb742546.aspx Я не должен фокусироваться на этой теме .. потому что она ждет и, возможно, находится в спящем режиме -WaitForSingleObjectEx и сон не вызывает использования процессора.

Еще несколько ресурсов цы, если кто-то в такой же ситуации -: https://channel9.msdn.com/Series/-NET-Debugging-Stater-Kit-for-the-Production-Environment

https://msdn.microsoft.com/en-IN/library/ms182372.aspx

источник

2016-10-06 13:23:26 user3359453

Первой командой WinDBG, которую вы хотите запустить, является: !runaway.
Эта команда покажет вам, какой поток использовал процессор в течение самого долгого времени.
После получения ввода от этой команды мы можем думать о том, что происходит ...

источник

2016-10-04 09:40:40 PazO

Если runaway дает высокий уровень использования, поток может в настоящее время делать что-то совершенно не связанное с высокой причиной процессора. ! runaway создает много ложных срабатываний. –

@Thomas:! Runaway показывает, какая нить использовала процессор в течение самого длительного периода времени, в то же время с самого начала приложения. Если ваш исполняемый файл превосходит ЦП, тогда побег должен показать вам наиболее проблемные потоки в начале списка, которые помогут вам проанализировать, какие интенсивные задачи вы выполняете. Я использовал его много раз и никогда не сталкивался с ложными срабатываниями. – PazO

Тогда вам повезло, что вы захватили состояние во время выполнения правильного стека. ! runaway может сообщить о потоке, который был активен 3 дня назад и ничего не делает на данный момент. –

Windbg - это не тот подходящий инструмент для этой работы. Дампы - это только снимки, поэтому вы не знаете, что произошло раньше. Используйте ETW и здесь CPU Sampling, который суммирует все вызовы и подробно показывает использование ЦП.

Установите Toolkit Производительность Windows, которая является частью Windows 10 SDK (V1607 works на Win8/8.1 (Server2012/R2) и Win10 или V1511 SDK, если вы используете Windows 7/Server2008R2)), запустите WPRUi.exe и выберите CPU Usage

и нажмите Start. Захватите 1 минуту использования центрального процессора и нажмите на Save. Открыть полученный ETL с WPA.exe (Перф анализатор), перетащить CPU Usage (Sampled) график на панели Analysys

и load the Debug Symbols. Теперь выберите свой процесс на графике, увеличьте масштаб и разверните стек, здесь вы видите вес использования ЦП всех вызовов

В этом примере большинство использования ЦП в Internet Explorer происходит из материала HTML.

Для приложений .NET WPA показывает .net, связанные группировки, такие как GC или JIT:

источник

2016-10-04 15:56:03 magicandre1981

Проблема находится в рабочей среде, поддержка не позволяет устанавливать инструмент. – user3359453

Поддержка, скорее всего, не знает, что такое ETW. Объясните им, что именно это Microsoft использует для устранения неполадок в системах [включая производственные системы] (https://blogs.technet.microsoft.com/robertsmith/2012/02/07/analyzing-storage-performance-using-the-windows -performance-анализ-инструментарий-WPT /). Если вам по-прежнему не разрешено копировать файлы, необходимые для запуска трассировки, я бы любезно передал им дело или спросил, каковы их предпочтения: добавление собственного журнала в тяжелом режиме для дальнейшего анализа проблемы или использования облегченного встраивания протоколов что Microsoft предоставляет. –

Спасибо за ваш ответ .. Сегодня я пройду через ETW. – user3359453

-1

Установите правильные символы пути после какого-либо анализа.
Набора в Файл-> Символ меню Пути файла: YOUR_SYMBOLS_PATH; OTHERS_PATH; SRV C: \ symcachehttp://msdl.microsoft.com/download/symbols

Попробуйте команды для просмотра управляемого стека:

 
.cordll -ve -u -l 
ld* 
!EEStack

источник

2016-10-04 16:20:07 lsalamon

Какую пользу вы видите! EEStack over! DumpStack? Как решить проблемы с производительностью? –

, чтобы показать некоторую релевантную информацию, которая может привести к возникновению проблемы. Для тех, кто обычно исследует аварии, это важно. – lsalamon

WinDbg анализ аварийного дампа, высокая загрузка процессора -

ответ

Смежные вопросы