2010-07-08 5 views
10

मैं ट्रैक करने की कोशिश कर रहा हूं कि मेरे आवेदन में एक स्ट्रिंग कितनी देर तक संग्रहीत की जाती है, और अत्यधिक मात्रा में मेमोरी खाती है। मेरे पास एक विंडोज सेवा है जो नियमित रूप से चलती है।WinDbg मुझे नहीं बता रहा है कि मेरी स्ट्रिंग रूट है

यह डेटाबेस से डेटा (डेटासेट के रूप में) पढ़ता है और फिर कुछ प्रोसेसिंग करता है - सभी प्रबंधित .NET।

विंडोज सेवा प्रत्येक 5 या इतने मिनट में एक बार ट्रिगर होती है, जो कुछ क्रॉस-रेफरेंसिंग करती है। डेटासेट की प्रत्येक पंक्ति को एक दूसरे से अधिक नहीं लेना चाहिए - सबसे खराब मामला!

एक चरण में निजी बाइट्स> 1.2 जीबी, भले ही प्रक्रिया के लिए कोई डेटा उपलब्ध न हो। कोई वैश्विक चर नहीं है, और सभी प्रक्रियाओं को व्यक्तिगत तरीकों से किया जाता है।

मैंने एक स्नैपशॉट लिया और WinDbg के साथ संसाधित किया।

0:000> !dumpheap -min 85000 
Address  MT  Size 
02027f40 00166620 101432 Free 
28411000 79330b24 536870936  
48c11000 79333594 226273040  
08411000 79330b24 452546504  
total 4 objects 
Statistics: 
     MT Count TotalSize Class Name 
00166620  1  101432  Free 
79333594  1 226273040 System.Byte[] 
79330b24  2 989417440 System.String 
Total 4 objects 

और इसलिए हम 2 तार है कि समस्या उत्पन्न कर रहे हैं पता लगाना चाहते हैं:

0:000> !dumpheap -mt 79330b24 -min 85000 
Address  MT  Size 
28411000 79330b24 536870936  
08411000 79330b24 452546504  
total 2 objects 
Statistics: 
     MT Count TotalSize Class Name 
79330b24  2 989417440 System.String 
Total 2 objects 

अब मैं पता लगाने के लिए जहां इन 2 स्थित हैं चाहते हैं, लेकिन जब मैं का उपयोग यहाँ के परिणाम हैं ! gcroot, यह कोई फल प्राप्त नहीं करता है:

0:000> !gcroot 28411000 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for 
more info. 
Scan Thread 0 OSTHread 2970 
Scan Thread 2 OSTHread 2ab4 
Scan Thread 3 OSTHread 12ac 
Scan Thread 4 OSTHread 1394 
Scan Thread 5 OSTHread 1b78 
Scan Thread 8 OSTHread 1364 
Scan Thread 9 OSTHread 226c 
Scan Thread 10 OSTHread 1694 
0:000> !gcroot 08411000 
Note: Roots found on stacks may be false positives. Run "!help gcroot" for 
more info. 
Scan Thread 0 OSTHread 2970 
Scan Thread 2 OSTHread 2ab4 
Scan Thread 3 OSTHread 12ac 
Scan Thread 4 OSTHread 1394 
Scan Thread 5 OSTHread 1b78 
Scan Thread 8 OSTHread 1364 
Scan Thread 9 OSTHread 226c 
Scan Thread 10 OSTHread 1694 

मुझे समझ नहीं आता मैं गलत क्या कर रहा हूँ, या क्यों स्ट्रिंग की जड़ नहीं पाया जा सकता है। मैंने किया है उस पर करते हैं, और यह सिर्फ कहते हैं तार गंदा कर रहे हैं:

0:000> !do 28411000 
Name: System.String 
MethodTable: 79330b24 
EEClass: 790ed65c 
Size: 536870930(0x20000012) bytes 
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll) 
String: <String is invalid or too large to print> 

Fields: 
     MT Field Offset     Type VT  Attr Value Name 
79332d70 4000096  4   System.Int32 0 instance 268435457 m_arrayLength 
79332d70 4000097  8   System.Int32 0 instance 226273026 m_stringLength 
79331804 4000098  c   System.Char 0 instance  57 m_firstChar 
79330b24 4000099  10  System.String 0 shared static Empty 
    >> Domain:Value 00159f38:01021198 << 
79331754 400009a  14  System.Char[] 0 shared static WhitespaceChars 
    >> Domain:Value 00159f38:010217d4 << 

और

0:000> !do 08411000 
Name: System.String 
MethodTable: 79330b24 
EEClass: 790ed65c 
Size: 452546502(0x1af94fc6) bytes 
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll) 
String: <String is invalid or too large to print> 

Fields: 
     MT Field Offset     Type VT  Attr Value Name 
79332d70 4000096  4   System.Int32 0 instance 226273243 m_arrayLength 
79332d70 4000097  8   System.Int32 0 instance 226273242 m_stringLength 
79331804 4000098  c   System.Char 0 instance  45 m_firstChar 
79330b24 4000099  10  System.String 0 shared static Empty 
    >> Domain:Value 00159f38:01021198 << 
79331754 400009a  14  System.Char[] 0 shared static WhitespaceChars 
    >> Domain:Value 00159f38:010217d4 << 

कोई मदद कर सकता हूँ कृपया?

-

अद्यतन:

eeheap -gc

Number of GC Heaps: 1 
generation 0 starts at 0x01175764 
generation 1 starts at 0x011756dc 
generation 2 starts at 0x01021000 
ephemeral segment allocation context: none 
segment begin allocated  size 
01020000 01021000 0117b770 0x0015a770(1419120) 
Large object heap starts at 0x02021000 
segment begin allocated  size 
02020000 02021000 02040d88 0x0001fd88(130440) 
28410000 28411000 48411018 0x20000018(536870936) 
48c10000 48c11000 563db710 0x0d7ca710(226273040) 
08410000 08411000 233a5fc8 0x1af94fc8(452546504) 
Total Size 0x488d9be8(1217240040) 
------------------------------ 
GC Heap Size 0x488d9be8(1217240040) 

अद्यतन 2: के रूप में इस विशेष कार्यक्रम एक्सएमएल पर कार्रवाई नहीं करता है मैं एक्सएमएल के लिए संदर्भ हटा दिया - मेरा बुरा!। 3


अद्यतन:

यहाँ psscor2.dll

0:000> !heapstat -inclUnrooted 
Heap  Gen0   Gen1   Gen2   LOH 
Heap0 32780  68316  1324728  1217845888 

Free space:             Percentage 
Heap0 12   67212  59764  101640  SOH: 8% LOH: 0% 

Unrooted objects:           Percentage 
Heap0 2684   1104   757416  1217715448 SOH: 53% LOH: 99% 
+0

की तुलना में है कैसे है आप एक स्ट्रिंग मान 512 है कि यह एमबी बड़ा है? क्या आप इसके बजाय डेटा पढ़ने के लिए XMLReader का उपयोग कर सकते हैं? –

उत्तर

7

संपादित (डी 'ओह, अधिक कॉफी अपेक्षित) ये तार से बड़े 85,000 बाइट्स इसलिए कर रहे हैं का उपयोग करने का परिणाम है वे बड़े ऑब्जेक्ट ढेर पर रहेंगे जो शायद ही कभी कचरा इकट्ठा होता है और संकुचित नहीं होता है (विखंडन की ओर अग्रसर होता है, खासकर यदि आप बहुत कम छोटी वस्तुओं को आवंटित कर रहे हैं)।

क्या WinDbg आपको बता रहा है कि सही है - इनके पास जड़ नहीं है और वे कचरे हैं, लेकिन क्योंकि वे LOH पर हैं, वे जल्दी से साफ़ नहीं हो सकते हैं (यदि बिल्कुल)।

आपको निश्चित रूप से फिर से सोचने की आवश्यकता है कि आप एक्सएमएल को कैसे संसाधित कर रहे हैं, मेमोरी अप-फ्रंट में लोड/बनाने के बजाय डेटा स्ट्रीमिंग/आउट करने के लिए देखें।

+0

तो क्या आप कह रहे हैं कि LOD पर रहने वाली कोई वस्तु WinDBG का उपयोग करके नहीं मिल सकती है? जैसा कि मेरे पास 226 एमबी बाइट सरणी है जो मुझे यकीन नहीं है? –

+0

मेरा जवाब दोबारा संपादित किया गया क्योंकि मुझे एहसास हुआ कि मैं LOH एकत्र नहीं होने के बारे में बकवास कर रहा था (यह * कॉम्पैक्ट * नहीं है)। जहां तक ​​मैं देख सकता हूं, WinDBG आपके LOH जुर्माना पर ऑब्जेक्ट ढूंढ रहा है, मुद्दा यह है कि कचरा वस्तुओं को जल्दी से एकत्र नहीं किया जा रहा है क्योंकि वे LOH पर हैं, आपके नवीनतम अपडेट से पता चलता है कि सख्त राहत में। – Paolo

+0

तो जब हम अनियंत्रित कहते हैं, तो हम केवल उन वस्तुओं का मतलब रखते हैं जिन्हें अब संदर्भित नहीं किया जाता है, लेकिन मेरे मामले में वे कचरा नहीं एकत्र किया गया है? –

1

LOH में ऑब्जेक्ट केवल तभी एकत्र किए जाएंगे जब स्मृति दबाव हो। जीसी केवल एलओएच में वस्तुओं को इकट्ठा करेगा जब यह एक पूर्ण संग्रह कर रहा है।

psscor2.dll (एक्सटेंशन प्रबंधित कोड डिबग करने के लिए) के लिए एक कमांड

!HeapStat [-inclUnrooted | -iu] 

जो वैध जड़ों डंप हो जाएगा, !eeheap

संबंधित मुद्दे

 संबंधित मुद्दे