मेरे पास एक प्रोग्राम है जो सॉकेट से डेटा स्वीकार करता है, कुछ गुणवत्ता नियंत्रण और मिश्रित अन्य कंडीशनिंग करता है, फिर इसे नामित पाइप पर लिखता है। मैं उस पर valgrind भाग गया और मूल रूप से अस्तित्व में सभी स्मृति रिसाव तय किया। इसके बाद मैंने एक सिस्टम पर 'डेमो' वातावरण बनाया जहां मेरे पास इस कार्यक्रम के 32 उदाहरण चल रहे थे, प्रत्येक को अद्वितीय डेटा खिलाया गया था और प्रत्येक अपनी पाइप पर आउटपुट कर रहा था। हमने इसका परीक्षण किया और सबकुछ ठीक दिखने लगा। फिर मैंने उस दर को बढ़ाकर तनाव परीक्षण करने की कोशिश की जिस पर डेटा बेतुका दर में भेजा जाता है और चीजें पहले अच्छी लगती थीं ... लेकिन मेरे कार्यक्रमों में अधिक से अधिक स्मृति का उपभोग नहीं किया गया जब तक कि मेरे पास कोई संसाधन नहीं छोड़ा गया।स्मृति रिसाव का शिकार कैसे करें वाल्ग्रिंड कहता है कि अस्तित्व में नहीं है?
मैं valgrind करने लगे थे और रिसाव की जांच का उपयोग कर = पूर्ण valgrind अंदर चल प्रत्येक कार्यक्रम के साथ छोड़कर ठीक उसी सेटअप भाग गया। कुछ अजीब चीजें हुईं। सबसे पहले, स्मृति रिसाव हो गई, लेकिन केवल उस बिंदु पर जहां प्रत्येक कार्यक्रम का उपभोग किया गया था। मेरी स्मृति का 9% (पहले सबसे बड़ी स्मृति हॉग में मेरी स्मृति का पूर्ण 6% था)। प्रोग्राम्स की सीपीयू लागत को चलाने वाले वालग्रिंड के साथ और अब मैं 100% सीपीयू पर भारी भार-औसत के साथ था, इसलिए यह संभव है कि उपलब्ध सीपीयू की कमी ने कार्यक्रमों को धीरे-धीरे चलाने के लिए प्रेरित किया ताकि लीक प्रकट हो सके । जब मैंने इन कार्यक्रमों को रोकने की कोशिश की तो वालग्रिंड ने कोई प्रत्यक्ष स्मृति रिसाव नहीं दिखाया, यह कुछ संभावित स्मृति रिसाव दिखाता है लेकिन मैंने उन्हें चेक किया और मुझे नहीं लगता कि उनमें से कोई भी वास्तविक स्मृति रिसाव का प्रतिनिधित्व करता है; और इसके अलावा संभावित स्मृति रिसाव केवल कुछ किलोबाइट्स के रूप में दिखाया गया था जबकि कार्यक्रम 100 एमबी से अधिक उपभोग कर रहा था। वाल्ग्रिंड द्वारा रिपोर्ट की जाने वाली पहुंच योग्य (गैर-लीक) मेमोरी भी केबी रेंज में थी, इसलिए वाल्ग्रिंड का मानना है कि मेरे प्रोग्राम स्मृति के एक अंश का उपभोग कर रहे हैं जो शीर्ष कहते हैं कि वे उपयोग कर रहे हैं।
मैं कुछ अन्य परीक्षण चलाने के लिए और अजीब परिणाम मिल गया है। एक एकल कार्यक्रम, यहां तक कि ट्रिपल दर पर भी चल रहा है, मेरी मूल मेमोरी-रिसाव का पता चला था, कभी भी 9% से अधिक स्मृति का उपभोग नहीं करता है, दो कार्यक्रम क्रमशः 1.9 और 1.3% मेमोरी तक पहुंचते हैं लेकिन कोई और नहीं, ऐसा लगता है जैसे, स्मृति की मात्रा लीक हो गई है, और जिस दर पर यह लीक है, किसी भी तरह से इस पर निर्भर है कि मेरे कार्यक्रम के कितने उदाहरण एक समय में चल रहे हैं; जो कोई समझ नहीं आता है, प्रत्येक उदाहरण दूसरों से 100% स्वतंत्र होना चाहिए।
मैं भी अगर मैं केवल एक उदाहरण में चल valgrind valgrinded उदाहरण (अगर मैं कहना है कि यह है कि एक शब्द है!) स्मृति लीक के साथ 32 उदाहरणों को चलाने पाया है, लेकिन valgrind के बाहर चल रहा है की तुलना में धीमी दर से। वाल्ग्रिंड इंस्टेंस अभी भी कहेंगे कि मेरे पास कोई प्रत्यक्ष रिसाव नहीं है और शीर्ष मेमोरी खपत रिपोर्ट करता है तो शीर्ष शो।
मैं नहीं बल्कि क्या इस परिणाम कारण हो सकता है के रूप में स्टम्प्ड रहा हूँ, और क्यों valgrind स्मृति रिसाव के बारे में पता होना करने के लिए मना कर दिया। मैंने सोचा कि यह एक बाहरी पुस्तकालय हो सकता है, लेकिन मैं वास्तव में किसी बाहरी पुस्तकालय का उपयोग नहीं करता; बस बुनियादी सी ++ कार्यों/वस्तुओं। मैंने यह भी माना कि यह बफर को अनिश्चित काल तक बढ़ने के लिए आउटपुट पाइप को लिखा गया डेटा हो सकता है, लेकिन 1) एक ऊपरी सीमा होनी चाहिए कि ऐसा बफर बढ़ सकता है और 2) यदि डेटा छोड़ देता है तो स्मृति लीक हो जाने पर इनपुट दर कुछ भी नहीं है जो स्मृति उपभोग करती है बल्कि धीरे-धीरे उचित मात्रा में गिर जाती है।
किसी को भी मुझे जहां मैं यहाँ से दिखना चाहिए के रूप में एक संकेत दे सकते हैं? मैं पूरी तरह से स्टंप हूं कि स्मृति इस तरह से क्यों व्यवहार कर रही है।
धन्यवाद।
क्या आप वाकई इसकी एक रिसाव न सिर्फ आपके प्रोग्रामिंग स्मृति का संग्रह में से कुछ हिस्सा हैं, और? क्या आपने मासफ की कोशिश की है? – PlasmaHH
मैंने खुद को इसी तरह की समस्याओं को मारा है (हालांकि क्विर्की के रूप में नहीं) और मुझे आपकी प्रतिक्रिया में बहुत दिलचस्पी है। एक सुझाव: क्या आप ओएस/संस्करण का उपयोग कर सकते हैं जिसका आप उपयोग कर रहे हैं? मुझे लगता है कि यह एक लिनक्स dist है। –
वालग्रिंड आपके प्रोग्राम को एक सैंडबॉक्स में चलाता है और प्रोसेसिंग की एक बड़ी मात्रा करता है। आपको उम्मीद है कि यह बहुत अधिक CPU उपयोग और वाल्ग्रिंड से चल रहे एक ही एप्लिकेशन की तुलना में बहुत धीमी कार्यक्षमता हो। मैं विचार करेगा कि क्या तनाव कार्यक्रम परीक्षण के दौरान अतिरिक्त बफ़र्स बनाता है डेटा है कि यह पाइप के लिए नहीं बना पाये धारण करने के लिए और यह संख्या बढ़ (लीक नहीं, बस के रूप में आप गति नहीं रख सकते हैं बढ़ रही है) है। –