मेरी याददाश्त कहां गई? बड़े निजी बाइट्स

Question

मेरे पास एक WPF ऐप है जो अन्य चीजों के साथ बड़ी और छोटी छवियों को प्रदर्शित करता है। मेरी समस्या यह है कि ऐप बहुत मेमोरी का उपयोग करता है और मैं यह नहीं समझ सकता कि यह कहां से आ रहा है।

परिदृश्य, जब अनुप्रयोग पर बल देते कुछ मैं इस ग्राफ परफ़ॉर्मेंस में मिलता है:

http://www.imagechicken.com/uploads/1244548604007097000.jpg

बड़ा काला लाइन प्रक्रिया \ निजी बाइट्स और अन्य लाइनों CLR मेम काउंटरों (गुलाबी एक हैं है कुल प्रतिबद्ध बाइट्स)

ग्राफ में संख्या में हैं:
निजी बाइट्स ~ 350 एमबी
प्रतिबद्ध बाइट्स ~ 100 एमबी

मैं WinDbg और अन्य उपकरणों के साथ एक बहुत चारों ओर से खुदाई कर दिया है, और वे सभी का कहना है कि कामयाब ढेर बर्ताव करता है (करीब 100 एमबी की! Eeheap रिपोर्ट में कामयाब कुल ढेर)

मैं चारों ओर जैसे एप्लिकेशन के साथ poking किया गया है लीकडिआग, एलडी ग्रैफर लेकिन कुछ भी नहीं मिला।

तो आखिरकार, मेरे प्रश्न पर, मेरी याददाश्त कहां जा रही है यह जानने में मैं आगे कैसे बढ़ूं?

यहां तक ​​कि ऐप शुरू करने से भी प्रतिबद्ध बाइट्स में 100 एमबी का उपयोग होता है लेकिन निजी बाइट्स में 190 एमबी का उपयोग करता है।

संदर्भ:

टेस Ferrandez: http://blogs.msdn.com/tess/archive/2009/02/27/net-memory-leak-reader-email-are-you-really-leaking-net-memory.aspx

रीको मरिअनी: http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

MSDN

मैं महान साइटों पर इस बारे में बहुत कुछ पढ़ा है दूसरों के बीच में, मैग: http://msdn.microsoft.com/en-us/magazine/cc163528.aspx

Answer 1

Scitech से MemProfiler डाउनलोड करें। इसमें 14 दिन का परीक्षण संस्करण है।

आपके द्वारा रिपोर्ट की जाने वाली समस्या अक्सर विचार/संसाधनों के कारण होती है जिसे ढेर में रूट होने के कारण निपटान नहीं किया जा सकता है। एक आम कारण घटना संचालक अनचाहे नहीं है।

Answer 2

सिर्फ इसलिए कि आपका एप्लिकेशन बहुत मेमोरी का उपयोग करता है, इसका मतलब यह नहीं है कि आपके पास मेमोरी रिसाव है। आपके प्रश्न की जानकारी से यह कहना मुश्किल है कि क्या गलत हो सकता है। - प्रत्येक ढेर एक है

• (!eeheap साथ ढेर उपयोग का अवलोकन करें इस ढेर के उपयोग और ढेर नहीं रिपोर्ट के रूप में आप का उल्लेख:

  जब WinDbg के साथ प्रबंधित मेमोरी लीक समस्या निवारण मैं तो निम्न कार्य करें 1 एमबी का डिफ़ॉल्ट आकार, इसलिए जब तक आप इसे बदल नहीं लेते हैं, तो आप स्टैक पर 100 एमबी का उपयोग नहीं कर सकते हैं)

• ढेर पर क्या है यह जानने के लिए !dumpheap -stat करें। संभावना है कि अगर आपके पास स्मृति रिसाव है तो दोषी उपभोक्ता शीर्ष उपभोक्ताओं में से एक होंगे।ढेर उपयोग कैसे विकसित होता है इसका एक अनुमान प्राप्त करने के लिए आप अपने आवेदन को फिर से शुरू कर सकते हैं, इसे थोड़ी देर बाद तोड़ दें और फिर !dumpheap -stat कमांड दोहराएं।

• यदि आपको छोड़कर उससे अधिक उदाहरणों के साथ कोई भी प्रकार मिलता है, तो !dumpheap -mt <MT of type> का उपयोग करने वाले लोगों को सूचीबद्ध करें। यह विशेष प्रकार के सभी उदाहरणों को सूचीबद्ध करेगा। !gcroot कमांड का उपयोग करके यादृच्छिक उदाहरण चुनें और जड़ों की जांच करें। यह आपको बताएगा कि मामलों में जिंदा सवाल क्या रहता है। यदि कोई जड़ नहीं है तो इन मामलों को किसी बिंदु पर एकत्र किया जाएगा।

अद्यतन आपकी टिप्पणियों का जवाब करने के लिए:

प्रबंधित ढेर केवल एक प्रबंधित आवेदन की स्मृति पदचिह्न का एक हिस्सा है। याद रखें, कि एक .NET अनुप्रयोग वास्तव में किसी अन्य एप्लिकेशन के अंदर एक एप्लिकेशन है - मेजबान प्रक्रिया, जो सीएलआर लोड करती है, जो बदले में आपके आवेदन को लोड करती है। इससे पहले कि आपका एप्लिकेशन किसी भी मेमोरी का उपयोग शुरू कर देता है, सीएलआर पहले ही एक उचित हिस्सा ले चुका है। उस .NET अनुप्रयोगों के शीर्ष पर पैर प्रिंट के हिस्से के रूप में एमएसआईएल कोड और जेआईटी संकलित कोड दोनों स्टोर करते हैं। सीएलआर विभिन्न बहीखाता सामानों के लिए भी जगह लेता है (उदाहरण के लिए सीएलआर आंतरिक उपयोग के लिए दो अतिरिक्त एडडोमेन्स बनाता है)।

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

प्रबंधित ढेर पर 100 एमबी ठीक हो सकता है, आपका आवेदन क्या कर रहा है इसके आधार पर ठीक है। क्या आपने ढेर की जांच की? और यदि ऐसा है तो आपको क्या मिला?

Answer 3

आप this article in the latest MSDN magazine पढ़ने का प्रयास करना चाहेंगे। यह प्रक्रिया के स्मृति को समर्पित करने के बारे में और अधिक समझने के लिए VADump का उपयोग करने के तरीके पर विस्तार से बताया जाता है।

आप VADump यहां से डाउनलोड कर सकते हैं: http://go.microsoft.com/fwlink/?LinkId=149683

प्रबंधित ढेर को तोड़ने के लिए, आप एक स्मृति प्रोफाइलर कोशिश कर सकते हैं। मुझे व्यक्तिगत रूप से JetBrains dotTrace पसंद है।

Answer 4

मुझे एक WPF अनुप्रयोग में एक समान समस्या थी, और used UMDH to track जहां मूल स्मृति आवंटित की जा रही थी। (ध्यान दें कि ओएस घटकों से अच्छे स्टैक निशान प्राप्त करने के लिए set _NT_SYMBOL_PATH पर आमतौर पर सहायक होता है।

लॉग दिखाते हैं कि लगभग सभी मेमोरी वीडियो ड्राइवर में आवंटित की जा रही थीं। मैंने पाया कि ड्राइवर एक वर्ष से अधिक था । पुराना हो चुका है, मैं निर्माता की वेबसाइट से नवीनतम संस्करण स्थापित और कहा कि समस्या का समाधान होने

Answer 5

एक जवाब: देखने के लिए सक्षम होना करने के लिए: यह रास्ता भी कई मर्ज किए गए ResourceDictionaries (एक WPF बात)

विवरण को जाता है ब्लेंड और वीएस में डिज़ाइन-टाइम में डिज़ाइन, हम अधिकांश थीम पेजों पर हमारे थीम संसाधन शब्दकोश को मर्ज करते थे। इससे सभी संसाधनों की एक प्रति बन गई प्रत्येक नियंत्रण के लिए लोड किया गया, अधिक जानकारी यहां पढ़ी जा सकती है: [डब्ल्यूपीएफ शिष्य] [1]

तो एकमात्र जगह जो मैं उन्हें विलय करता हूं अब App.xaml है।सीएस:

<Application.Resources> 
    <ResourceDictionary> 
    <ResourceDictionary.MergedDictionaries> 
     <ResourceDictionary 
     Source="pack://application:,,,/Company.Themes;Component/AppTheme.xaml"/> 
    </ResourceDictionary.MergedDictionaries> 
    </ResourceDictionary> 
</Application.Resources> 

परिणाम:

से पहले (एक स्वचालित जीयूआई परीक्षण के साथ कुछ पृष्ठों के माध्यम से एप्लिकेशन चला):

• एप्लिकेशन लोड करने के बाद: 63 एमबी
• एप्लिकेशन उपयोग करने के बाद : 177 एमबी

के बाद:

• एप्लिकेशन लोड करने के बाद: 53 एमबी
• एप्लिकेशन उपयोग करने के बाद: 97 एमबी

के रूप में मैं उन्हें खोजने मैं और अधिक उत्तर पोस्ट करेंगे! (मैंने सोचा कि यह पाठकों अलग के बजाय टिप्पणी करने के लिए replys के जवाब के रूप में मेरी खोज को देखने के लिए के लिए सबसे आसान होगा - अच्छा?)

[1]: रेफरी: http://groups.google.com/group/wpf-disciples/web/wpf-and-xaml-coding-guidelines?pli=1