xperf WinDBG C#.NET 4.5.2 अनुप्रयोग-प्रक्रिया डंप समझना




jit (2)

इसे हाथ से करने से बहादुरी की जरूरत होती है;) कृपया इस आधिकारिक एमएस डिबगडिआग 2.2 की जांच करें: https://www.microsoft.com/en-us/download/details.aspx?id=49924 यह विश्लेषक के साथ आया है, इसलिए आपके पास नहीं है अपने हाथ से करना। DebugDiag के साथ, मुझे लगता है कि आप अपनी समस्या को और तेज़ी से पा लेंगे ...

एक भारी लोड के तहत, हमारा एप्लिकेशन एक बीफ़ सर्वर को 100% सीपीयू उपयोग के लिए जा रहा है। प्रक्रिया को डंप करते हुए, थ्रेड्स को देखते हुए, उनमें से कुछ 10 मिनट ऊपर हैं। उनमें से कोई भी उपयोग करते समय मुझे कोई जानकारी नहीं देता!

भगोड़ा मुझे दे रहा है:

0:030> !runaway
 User Mode Time
  Thread       Time
  53:2e804      0 days 0:10:04.703
  30:31894      0 days 0:07:51.593
  33:47100      0 days 0:07:24.890
  42:11e54      0 days 0:06:45.875
  35:35e18      0 days 0:06:07.578
  41:54464      0 days 0:05:49.796
  47:57700      0 days 0:05:45.000
  44:3c2d4      0 days 0:05:44.265
  32:3898c      0 days 0:05:43.593
  50:54894      0 days 0:05:41.968
  51:5bc58      0 days 0:05:40.921
  43:14af4      0 days 0:05:40.734
  48:35074      0 days 0:05:40.406
  ...

कॉलिंग! उन थ्रेड्स में से एक पर डंपस्टैक, मुझे मिल रहा है:

0000001ab442f900 00007ff9ef4c1148 KERNELBASE!WaitForSingleObjectEx+0x94, calling ntdll!NtWaitForSingleObject
0000001ab442f980 00007ff9e920beb2 clr!SVR::gc_heap::compute_new_dynamic_data+0x17b, calling clr!SVR::gc_heap::desired_new_allocation
0000001ab442f9a0 00007ff9e90591eb clr!CLREventWaitHelper2+0x38, calling kernel32!WaitForSingleObjectEx
0000001ab442f9b0 00007ff9e90e0d2c clr!WriteBarrierManager::UpdateEphemeralBounds+0x1c, calling clr!WriteBarrierManager::NeedDifferentWriteBarrier
0000001ab442f9e0 00007ff9e9059197 clr!CLREventWaitHelper+0x1f, calling clr!CLREventWaitHelper2
0000001ab442fa40 00007ff9e9059120 clr!CLREventBase::WaitEx+0x70, calling clr!CLREventWaitHelper
0000001ab442fa70 00007ff9ef4c149c KERNELBASE!SetEvent+0xc, calling ntdll!NtSetEvent
0000001ab442faa0 00007ff9e90ef1e1 clr!SVR::gc_heap::set_gc_done+0x22, calling clr!CLREventBase::Set
0000001ab442fad0 00007ff9e90e9331 clr!SVR::gc_heap::gc_thread_function+0x8a, calling clr!CLREventBase::WaitEx
0000001ab442fb00 00007ff9e92048e7 clr!SVR::gc_heap::gc_thread_stub+0x7a, calling clr!SVR::gc_heap::gc_thread_function
0000001ab442fb60 00007ff9e91a0318 clr!Thread::CLRSetThreadStackGuarantee+0x48, calling kernel32!SetThreadStackGuaranteeStub
0000001ab442fb90 00007ff9e91a01ef clr!Thread::CommitThreadStack+0x10, calling clr!Thread::CLRSetThreadStackGuarantee
0000001ab442fbd0 00007ff9e910df0b clr!ClrFlsSetValue+0x57, calling kernel32!SetLastErrorStub
0000001ab442fc00 00007ff9e92048dc clr!SVR::gc_heap::gc_thread_stub+0x6f, calling clr!_chkstk
0000001ab442fc40 00007ff9f0d316ad kernel32!BaseThreadInitThunk+0xd
0000001ab442fc70 00007ff9f1e54409 ntdll!RtlUserThreadStart+0x1d

यह मुझे क्या बता रहा है? मैं सीएलआर को बहुत सारे कॉल देखता हूं, लेकिन मैं यह नहीं समझ सकता कि समस्या कहां होगी। .Reload (थॉमस द्वारा सुझाए गए) के बाद अब मैं GC कॉल देख सकता हूं।

अपडेट १

Xperf चलाने के बाद, प्रत्येक w3wp.exe लगभग 45% CPU का उपभोग कर रहा है। उनमें से एक द्वारा फ़िल्टर करना और फ़ंक्शन द्वारा समूहीकरण करना, "" के रूप में लेबल किया गया एक फ़ंक्शन है? यह 13.62% के लिए जिम्मेदार है, अन्य लोग 2.67% या उससे कम हैं। मैं यह कैसे जान सकता हूं कि यह "" क्या है?

अपडेट २

Ran xperf फिर से, और फ़ंक्शन JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel CPU उपयोग के 12.31% के लिए जिम्मेदार है। "?" फंक्शन अभी भी वहीं रहता है।

ढेर द्वारा समूहीकरण:

Line #, Stack, Count, Weight (in view), TimeStamp, % Weight
2,   |- ?!?, 501191, 501222.365294, , 35.51
3,   |    |- clr.dll!JITutil_MonContention, 215749, 215752.552227, , 15.28
4,   |    |- clr.dll!JIT_MonEnterWorker_InlineGetThread_GetThread_PatchLabel, 170804, 170777.100191, , 12.10

जैसा कि आप देख सकते हैं, वे दोनों 27% से अधिक सीपीयू उपयोग के लिए जिम्मेदार हैं (प्रत्येक प्रक्रिया के लिए, इसलिए यह महत्वपूर्ण है)।

अपडेट ३

Wpr.exe (@ Magicandre1981 द्वारा सुझाव) का उपयोग करने के बाद:

wpr.exe -start cpu and wpr -stop result.etl

मुझे पता चला कि फॉर्म्यूथेंटिकेशन और महत्वपूर्ण पथ पर निनजेक्ट के लिए कुछ अनावश्यक कॉल लगभग 16% CPU उपयोग में योगदान कर रहे थे। मुझे अभी भी 10 मिनट या उससे अधिक समय तक चलने वाले धागे की समझ नहीं है।

अद्यतन ४

डीबगडिआग (@leppie से सुझाव) की कोशिश की और इसने पुष्टि की कि लटके हुए धागे सभी के समान हैं:

Thread ID: 53     Total CPU Time: 00:09:11.406     Entry Point for Thread: clr!Thread::intermediateThreadProc 
Thread ID: 35     Total CPU Time: 00:07:26.046     Entry Point for Thread: clr!SVR::gc_heap::gc_thread_stub 
Thread ID: 50     Total CPU Time: 00:07:01.515     Entry Point for Thread: clr!SVR::gc_heap::gc_thread_stub 
Thread ID: 29     Total CPU Time: 00:06:02.264     Entry Point for Thread: clr!SVR::gc_heap::gc_thread_stub 
Thread ID: 31     Total CPU Time: 00:06:41.281     Entry Point for Thread: clr!SVR::gc_heap::gc_thread_stub 

या StackExchange.Redis के कारण:

DomainBoundILStubClass.IL_STUB_PInvoke(Int32, IntPtr[], IntPtr[], IntPtr[], TimeValue ByRef)+e1 
[[InlinedCallFrame] (StackExchange.Redis.SocketManager.select)] StackExchange.Redis.SocketManager.select(Int32, IntPtr[], IntPtr[], IntPtr[], TimeValueByRef) 
StackExchange.Redis.SocketManager.ReadImpl()+889 
StackExchange.Redis.SocketManager.Read()+66 

या

[[GCFrame]] 
[[HelperMethodFrame_1OBJ] (System.Threading.Monitor.ObjWait)] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object) 
mscorlib_ni!System.Threading.Monitor.Wait(System.Object, Int32)+19 
StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[[System.__Canon, mscorlib]](StackExchange.Redis.Message, StackExchange.Redis.ResultProcessor`1, StackExchange.Redis.ServerEndPoint)+24f 
StackExchange.Redis.RedisBase.ExecuteSync[[System.__Canon, mscorlib]](StackExchange.Redis.Message, StackExchange.Redis.ResultProcessor`1, StackExchange.Redis.ServerEndPoint)+77 
[[StubHelperFrame]] 
StackExchange.Redis.RedisDatabase.SetMembers(StackExchange.Redis.RedisKey, StackExchange.Redis.CommandFlags)+ee 

धीमा ऐप, धीमे कोड से हो सकता है या शायद .NET इंजन से होता है

सबसे पहले अगर आपने clr.dll की जाँच की थी, अगर इसमें कोई समस्या है तो आप इसे डाउनलोड कर सकते हैं और इसे अपने कंप्यूटर पर बदल सकते हैं यदि यह कोई समस्या नहीं है तो इसे आज़माएं

मुझे लगता है कि आपको अपने एप्लिकेशन कोड की समीक्षा करनी चाहिए, और हर कोने को चिकी करना चाहिए जो बहुत सारी प्रक्रिया लेता है और सीपीयू और रैम के बीच कोड संचालन भार को संतुलित करने का प्रयास करता है। लूप्स, ऑब्जेक्ट इनिशियलाइज़ेशन या रिकर्सन फ़ंक्शंस आदि .. सभी सीपीयू पर लोड करता है, स्टैड ऑब्जेक्ट्स को स्टैटिक या कॉन्स्टेंट पर स्टोर करने की कोशिश करें





xperf