मेरी याददाश्त कहां जा रही है यह जानने के लिए

Question

मुझे ऐसी स्थिति मिली है जहां लोडिंग का चक्र और फिर दस्तावेज़ बंद करने से कुछ एमबी रैम खा जाता है। इस स्मृति को के रूप में लीक नहीं किया जा रहा है इसका मालिक है और जब ऐप निकलता है (विजुअल लीक डिटेक्टर और मैक लीक टूल इस पर अनुबंध दिखाता है) इसे साफ़ करता है। हालांकि, मैं यह जानना चाहता हूं कि यह कहां जा रहा है। मुझे लगता है कि यह एप्लिकेशन में कुछ प्रकार का कैश है जो दस्तावेज़ लोड होने पर पॉप्युलेट हो जाता है लेकिन दस्तावेज़ बंद होने पर मुक्त नहीं होता है। इन आवंटन कहां किए जा रहे हैं यह जानने के लिए मैं किन विधियों या औजारों का उपयोग कर सकता हूं?

अद्यतन:

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

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

Answer 1

इस धारणा से कार्य करना कि वास्तव में यह रैम है जिसे आपने मापा है: सुनिश्चित करें कि यह पूरी तरह से सामान्य है। आपका प्रोग्राम सक्रिय रूप से दस्तावेज़ लोड करते समय वर्चुअल मेमोरी पेज को संबोधित कर रहा है, वे रैम में मैप किए जाएंगे। वे तब तक वहां रहेंगे जब तक कि किसी अन्य प्रक्रिया को रैम पर मैप किए जाने वाले पृष्ठों की आवश्यकता न हो। कुछ ऑपरेटिंग सिस्टम काम पर सेट को पूर्व-खाली तरीके से ट्रिम करते हैं, उदाहरण के लिए जब ऐप की खिड़कियां कम हो जाती हैं।

यदि यह वास्तव में वर्चुअल मेमोरी पेज है जो आपने मापा है: यह भी सामान्य है। स्मृति को रिलीज़ करने के बाद, ढेर ब्लॉक को फ्री ब्लॉक की सूची में जोड़ा जाता है, जो अगली मेमोरी आवंटन द्वारा उपयोग किए जाने के लिए तैयार होता है। यदि स्मृति जारी करना पृष्ठों की पूरी श्रृंखला को मुक्त करने के लिए होता है तो स्मृति प्रबंधक को उस सीमा को अनैप करने का अवसर होता है। यह अक्सर नहीं होता है और यह आपके मेमोरी मैनेजर का कार्यान्वयन विवरण कितना आक्रामक रूप से ऐसा करता है।

Answer 2

अच्छा, वास्तव में आपके पास रिसाव है। जब एप्लिकेशन ओएस से बाहर निकलता है तो सभी संसाधनों को साफ़ कर दिया जाता है: इस एप्लिकेशन में कोई भी एप्लिकेशन लीक नहीं होता है जो छोड़ने के बाद स्मृति को स्थायी रूप से आवंटित करता है। एक्सकोड में लीक की पहचान करने में आपकी सहायता करने के लिए एक टूल है।

Run->Run with performance Tool->Leaks

के तहत देखें जो आपके आवेदन को कोड के साथ चलाएगा जो आपको लीक खोजने में मदद करेगा।

Answer 3

यदि आप विश्वसनीय रूप से इसे पुन: उत्पन्न कर सकते हैं तो आप इसे समस्या निवारण के लिए एमएस सीआरटी में डीबग ढेर का उपयोग करने में सक्षम होना चाहिए। यहां प्रारंभ करें: Memory Leak Detection and Isolation

Answer 4

किसी के लिए सहायक हो सकता है। मुझे लगा कि ज़ोंबी ऑब्जेक्ट्स डिटेक्शन सक्रिय (सक्रिय रूप से योजना संपादन में एक चेकबॉक्स) के साथ एक्सकोड 4.2 एक पागल की तरह स्मृति खाता है - एक मिनट में ~ 4 जीबी। बस यह सुनिश्चित करना सुनिश्चित करें कि आपका ऐप एक्सकोड के तहत मेमोरी चला रहा है और अन्यथा नहीं। मेमोरी आवंटन और रिसाव उपकरण भी कुछ भी नहीं देता है।